I'm sure
many of you are either contemplating joining or actually sitting on the SOA
bandwagon with high hopes of delivering the business benefit that we as IT
professionals promise to our lords and (pay)masters on a regular basis. In case some of you are unsure of the true benefits
or how to quantify them for budgetary purposes, here are some 'home truths'
gleaned from real activity out in the wild.
- SOA can save money. But not
in the beginning. One of the key
benefits promised for SOA is re-use of the assets and services
developed. One obvious consequence
of this is that re-use is a benefit gained from the SECOND project
onwards, but not the first. The
business case for SOA requires a more holistic approach to benefits
realisation over a longer period, e.g. reducing Total Cost of Ownership (TCO) for the key processes delivered using SOA.
- You can't buy SOA. SOA is
not a product; it is a set of architectural concepts to develop a
framework, a set of standards and (hopefully) a governance model. You may buy specific tools and services
that are SOA-enabled, but this should only be when you already have the
Architecture understood and agreed.
- Web Services are not SOA. Most of the hype around SOA has been
geared towards the development of XML and SOAP messages using HTTP. Web Services can be used as part of the
delivery of rich business services with a Service Oriented Architecture,
but SOA can exist and deliver benefit quite happily without Web
Services. Many companies have
managed to use Web Services to create another island of development
standards that are not part of any enterprise architecture - typically
increasing the chaos within IT delivery rather than improving the quality.
We will be
publishing more war stories and examples of good and bad practice in future
blogs.
John Moe
