Service orientated architecture (SOA) is all about understanding discrete business functionality and then applying creative technical solutions to support that. It can solve problems in isolation, but still give a holistic view of the enterprise.
SOA promises to unlock the power of legacy systems and lessen the dependency on high-end enterprise applications. This is achieved by encapsulating business functionality in services.
These services will be constructed independently of the enterprise and legacy applications and will string together in loosely coupled late-binding business processes. Once complete, these services will be re-used throughout the enterprise. What does this change mean for the traditional IT project manager?
Traditionally
SOA, as a concept, has been around for eight years, but it has only really been taken up in the last four years. Where companies have taken it up, they have looked at it as a technical paradigm rather than as an architectural paradigm and this is the wrong approach.
Traditional project management and IT delivery methods focus on the products that are to be created, but they need a way of understanding and deconstructing the process at each individual level.
In order to keep things on track the traditional project manager uses a set of tolerances based on three factors; time, cost and scope / quality:
And, with traditional IT single customer delivery projects (i.e. delivering product) this simple trade-off, more often than not, worked.
New concepts
With SOA, concepts such as re-use, shared components, autonomous service and meta- driving will be at the forefront of IT project delivery. SOA delivery projects will have greater interdependencies and project managers may well find themselves delivering functionality for ‘future customers’. The traditional trade offs of time, cost and scope will no-longer be sufficient.
An example application could be with a supermarket where the retailer has many different streams of products that require different elements to be recorded in its online ordering service; for example, the food sales area will have different requirements to the electrical.
The old style approach would have separate applications working on different product streams. With SOA, a joined-up approach can be taken across all the project streams and a break down of what is needed from each area can be provided to better inform the functionality of one big application.
These new concepts have changed the dynamics of project delivery and project control. Time, cost and quality will still factor heavily in decision making, but what of dependencies, complexity and risk?
Decisions consider a much lower level of granularity coupled with a broader view of the project portfolio. A decision to alter the scope of a service may well be acceptable for today’s project, but may adversely affect the critical path of future projects. So how do project dynamics look?
By considering these factors the project manager may be able to reduce scope or risk and free up dependencies by splitting complex service functionality on one service in to two or more services:
Complex service with many dependencies = higher business risk?
Complex service with few dependencies = lower business risk?
SOA project managers will not just be responsible for the success for the project; they will have joint responsibility for the success of the ‘service portfolio’. Project managers and the project management office will need to develop new techniques for scoping, planning and de-risking SOA projects and the delivery of SOA services. Contrary to popular belief, SOA creates independencies and therefore it is important that project managers are more cognisant of the impact of their delivery on other projects.
IT managers need to think about the best way to do SOA in the new world. Lots of organisations need to take a more agile approach and be more able to adapt to change.
Continuous integration is a defined framework for agile development. It is a best practice way of providing the basis of being able to deliver on time and to have clarity during the development phase. Although it is associated with agile development, continuous integration delivers benefits to any development team.
Continuous integration works by frequent code check-in to a source repository, which automatically builds and unit tests the code.
This leads to developers creating modular, less complex code, a greater proportion of test driven development and provides immediate feedback to developers on defects and any system-wide impact or conflicting changes.
Symptoms which can be resolved by continuous integration are:
- Delays in the life-cycle due to builds breaking
- Late warning of conflicting changes
- Release deliver is late / costs more than expected
- High number of system integration test and user acceptance test defects, which impact delivery time and cost
- High number of regression test failures, which impacts on existing live functionality when the release is deployed into production
- No visibility of build process
The continuous integration process lends itself to be developed to use tools that can then be run during the build process to perform static code analysis or identify security vulnerabilities, ensuring the quality of code.
