As you can imagine, I spend a lot of time speaking to people about service oriented architecture (and it’s variants for infrastructure and enterprise) and about how best to create a true implementation (or at least, an effective one).  There is a great deal of detail in creating such an artifact – design yes, but also implementation, operational details, governance and a myriad of other tasks that can easily take up a chief architect’s entire day.  These tasks are all vital to the actual creation of the architecture, but for all that they may seem the fundamental first steps in evolving the IT shop, and yet there are even more necessary first steps – selling the concept in the first place.

SOA in many ways reminds me of relational database technology. At it’s first inception, the concept of an RDBMS must have had a hard sell.  Sure it made perfect sense to arrange the data and ensure that the relationships between the data were enforced but what was the business case that enabled the purchase of this new and expensive technology?  You certainly couldn’t say that by introducing a relation database you were going to make the company twenty million dollars a year annually.  So the RDBMS slowly made it’s way into the IT arsenal a little at a time, with justifications added in a variety of ways. 

SOA is even more complex – it affects almost every aspect of the enterprise if done to the fullest, and yet the basic premise is very similar to the RDBMS – it’s a better way to work.  I imagine the discovery of the wheel engendered similar thought – “Duh, why didn’t I think of that, it’s so simple”.   And yet there’s a mountain of legacy code, fifty years worth in some cases, that prevent a simple rip and replace.  Not to mention the cost problem.

But the real challenge in SOA is finding the ROI in IT.  The logical statement that spending twenty million (I’m just picking a big number here, not stating that an SOA conversion should cost that) on conversion will in the future make all IT projects easier to implement, and thus less costly by some factor is in most cases not a sufficient justification.  And the idea of tacking it on to some in flight project usually creates howls from the business owner who somehow is being asked to pay much more than their base project should cost. 

Really, there’s got to be another way.  And there is – making the business a partner.  SOA is something that enables changes to how the IT organization reacts to business requirements and new functionality requests, making them easier to accomplish, and therefore both faster and cheaper.  Building a case with the business that these changes are important, and justify slightly hire costs for the first few projects is helpful.  Finding a large scale transformation project is even better.

In a large scale transformation, many IT systems are going to be touched, re-aligned or replaced.  New data models will come into being, and new services will be needed.  This is not to say that it’s justification for throwing the kitchen sink into the IT budget during a transformation, but a case can easily be made based on the integration needs that are without a doubt going to be part of the program.  Instead of some cost savings in the future, by going with SOA in a transformation, the cost savings can be realized within the program itself.

This isn’t what the IT world wants to hear – there’s a strong push from vendors and platform providers to go SOA – but it is the reality of software systems.  The concept of a system that constantly requires renewal is foreign for some reason to financial folks, even though there are countless examples of the concept in the world.  Software has a lifecycle, and if you don’t feed your investment, it dies.  Nevertheless, in order to move to an SOA environment, we need to recognize the need to involve the business side of the organization in our activities and make a case in a language they understand in order to be successful.