Thursday, February 02, 2006

Service Oriented Realisation - how SOA impacts projects

One area that is often overlooked, or (IMO) done badly, is how project management and project structures are able to change in an SOA environment. SOA can be done in a "traditional" way, even a waterfall way, but this doesn't take advantage of the power of SOA.

The key element that SOA enables for projects is that it can turn them into programmes. This means that instead of considering a project as a bunch of people delivering on requirements, its actually a bunch of service delivery teams working within a programme. On large scale projects this sort of thinking is required, but on a larger scale. The advantage of SOA is that it can help to reduce the amount of communication require in a programme, it defines the boundaries outside of which people really shouldn't care, and helps to identify (but as Dan Creswell points out not really define) the dependencies between services.

A key benefit of this is the ability to target your crack teams at the hard work and target the majority of the developers at the simpler elements. It also means that as a project manager (now programme manager) you are able to better identify issues that are going to have wider impacts and gives a structure in which these elements can be spotted earlier on.

As an example, if a project has 100 use cases you start developing and you can say that UC 20 and 40 are going to be late but you tend to split the work up by use case (a functional thread), if those 100 use cases are implemented by 10 services then you can say that Service 2 has two elements that are going to be late. Because you've defined the interfaces to the services upfront you've also mitigated the impact of that delay onto other areas of the programme.

SOA enables Service Oriented Realisation (SOR, because lets face it Service Oriented Delivery of IT is never going to catch on) which is about changing away from delivery of individual requirements to the delivery of multiple projects which each aim to deliver sets of requirements. This is a massive shift for most project managers and its going to be interesting to see how many SOA projects continue to be delivered using waterfall and standard requirements driven iterative approaches.

No comments: