SOA has become probably one of the most used and abused terms in IT in the last decade from assuming that implementing RPC over HTTP (rather than true REST) to the adoption of SOAP and WSDL equates to SOA, but this has been greatly written about. If you read texts such as the tombs from Thomas Erl & co (they are very substantial books and require a strong book case) then you will appreciate the goal to align services to more business centric thinking.

The point I wanted to really home in on is not the business process thinking but actually the organisational challenges of realising SOA. In software houses or end user businesses design and development is aligned to projects or a proxy to that such as a product release. Understandable given the wealth of experience both technical and non-technical for managing projects. But projects line up behind delivering specific goals. In an organisation that is particularly delivery or time aggressive (some might say entrepreneurial) this project drive can, and istypically at the expensive of the wider software ecosystem. Building proper services requires input beyond the singular goal of a project in most cases.

This organisation and possibly cultural consideration is where most SOA texts don’t go, but probably where most help is needed to effect true SOA.  Why do I say this, well consider statistics around failed projects, the amount of up front investment SOA demands – getting a handle on design patterns and technology is managable, but how do you know that the organisation and non technical aspects are not distorting or undermining your ability to deliver SOA properly.

From my personal experience I can see several things that can help (but not certainty) achieve the goal, namely:

• management at all levels who recognise the benefits of SOA and particularly the upfront investment in time (and delivery impact) and are prepared to allow projects to factor this into their goals
• architects have the authority and tools to design in a style but also the ability to define the potential value of SOA, this has to be tempered with pragmatism  (this means that the architects need to be highly collaborative and cohesive as a function if not a team)
• design governance to support the process – with the teeth to impact a project

But this is an approach is likely to create tensions between the project and its pressures and the desire to achieve a SOA goals. The question is can an alternate organisational model exist which allows for a more effective realisation of SOA ideals without the tensions as the stronger the personalities involved between architecture and project pulling to meet their goal.

It is worth also considering the additional complexity that offshoring the implementation can add in terms of organisational challenge; as an offshore 3rd party’s focus is revenue within in an engagement (offshore vendors aren’t charieties they need to make a profit as well) so they will work to be as efficient as possible; and not likely to be focused on your total SOA ecosystem of services  (they may not even see the big picture you’re seeking to achieve) so building appropriate layers of decoupling and abstraction are not likely to be in their natural interests unless such sensitivities are built into the agreement and backed up by governance with appropriate levels of impact (which could be as extreme as rejecting the solution as it doesn’t match the service designs identified).

Further in some organisations the challenge can run deeper beyond IT and into the sponsoring side of the business. Let me illustrate this, organisations are ultimately broken into functions who can look at systems as belonging to a specific function ie system A is for marketing, that system B for eCommerce and so on. With that kind of system thinking and each department driving against its own goals (sounds like a project again) the overlap of services against software products is going to be challenging. For example services such as a service for ‘Customer’  information is likely to cross software solutions such as CRM (Marketing) and eCommerce can be subject to different demands as the different parts of the organisation pull in their desireddirection resulting in potential clashes (and likely blame IT for the issues that arise).

One of the few diagrams that makes reference to organisation in the context of SOA

So what is the answer? I can only offer up my experiences above, point to the fact that some organisations perhaps just are not ready for realising true SOA. I would certainly love to read a SOA book that approaches the question not from a technology perspective but that of a organisational and process view point.