From SOA to the Service-Oriented Enterprise

Introduction
The concepts of Agility and Service-Oriented Architecture are being marketed specifically as a new revolution in the way IT is provided to the Business. Such a view is unnecessarily reductive at best (why only IT?) and self-defeating at worst (is SOA just a marketing fad?).
The benefits of Agility and SOA are not under discussion. But for them to fully succeed, IT can and must support its rationalization efforts by providing the ancillary but necessary tools in order to help the business undergo the associated cultural changes

Beyond Agile IT
The buzz regarding Agility and Service Orientation is about “breaking away from the past”. Old, monolithic, inflexible applications will be supplanted by new, swift, adaptable, communicative and nimble systems. There is however a distinct feeling that it may all be just hype, with interest fuelled mostly by large marketing campaigns.
In a computer-literate society, advertisement can indeed entice people to find more about the latest trend in information management services. Such an interest can then generate revenues for those that somehow manage to be at the forefront of the new technology.
One problem with this: in a computer-literate society, business managers are exposed to a profusion of industry magazines not afraid to deal with IT issues and their history, making increasingly difficult to close down an argument by saying, “So-and-so consultancy firm knows best”. The usual comparison is between the arguments used to promote Web Services and SOA and the 1990’s EDI “revolution-that-never-was”.
There are surely only so many times Clients can repeat the same mistake (spending on some new technology hoping for it to solve all sorts of problems and herald a new, efficient, cost-effective way to do business). In the case of Agile IT, the underlying challenge is to verify that the proposed architecture does really matter to the Business.
Forget technology for a short while then. Let’s concentrate on what the concepts of Agility and SOA mean to what the Business actually cares about, namely their business. Will this make the real difference and make the “it’s just hype” tribe to eat their hats?

Agile Business
Start from Project Finance: when more than a single business unit supports a project, complex approvals involve several senior business people. Those may actually feel encouraged to wait for the one area that will definitely need the new service, to pay for it on its own. The end result is a tardy, corporate sloth.
Just as in Procurement: even if everybody agrees that market data, hardware, software licenses, etc would cost much less if orders were always shared and coordinated, profligate corporations are seldom able to leverage resources they already paying for. Business areas source their requirements independently, fearing the risks and additional costs of “working together”.
Adding control layers in corporate HQ to overcome this situation would only make it worse. The promotion of SOA and Agility has to be based on encouraging the various business areas to finance service-oriented projects.
Additional budget can be rewarded to areas that build and share service-oriented systems and assets, and amortization plans refinanced, with yearly charges shared by all the areas that could benefit from them. In the true spirit of Agility, the entire organisation would push itself towards becoming an Agile, Service-Oriented Enterprise, where sharing encompasses everything, including teams re-shuffled to adapt to changing requirements. With each service and application clearly identifiable, out- and in-sourcing become simpler, at infrastructure and application management level.

IT and the Agile Enterprise
Not-agile and not-service-oriented organizations are resistant to change so IT must help instigate and drive SOA’s extension into the whole business, providing the necessary tools that will support such a change.
First of all, paraphrasing a political question: “who stays up with the sick system?” With services shared among several business areas, will anyone feel responsible for them, or will they all wait for HQ to take care?
IT can help Business Areas clarify ownership, for instance by involving the relevant business managers into all the decisions concerning the implementation of the service.
Collaboration tools can also encourage business areas to cooperate more effectively. These may include information share systems to internally publicize the services that are being built or planned for in the SOA, and that thus could be used by other areas.
The outcome data can then be used at Board level, where careful management will mean setting aside in the budget awards for the business areas more successful in providing services, providing therefore yet an additional incentive for SOA to become the norm. Additional monitoring tools for the Board can include metrics on which services are more shared, and communications channels letting the various business areas ask for financing or other kind of support when embarking in the realization of what can be a service for the entire Company

Conclusions: what IT can and should do to promote SOA
Leaving Agility confined to the IT area will make it just another fad ready to be supplanted by next marketing campaign. The alternative is for Service-Oriented Architecture concepts to be extended outside the IT departments and agility becoming simply the norm in most businesses, where the gains in terms of increased efficiencies and therefore productivity are all too evident.
Expanding SOA into Service-Oriented Enterprise will imply skills of Change Management not easy to be found, with failure beckoning and SOA getting discarded at the first possible occasion. It will be all too easy for IT personnel to behave like enlightened apostles of the new credo of Agility and Service-Oriented Architecture, condescendingly explaining them to the illiterate masses of senior business managers. Such a behaviour will not bring any fruitful results but (perhaps) in the few companies where the CIO/CTO has major decision powers.
Indeed, the cultural changes associated with Agility and Service-Orientation will have to start from IT itself. For once, there is the chance of helping the Business make and support the transition by providing the necessary tools on top of the new technology. If this opportunity will be taken not we will witness not only a major revolution in the way IT is provided, but even more importantly the entire Business-IT relationship finally getting into adulthood