Thursday 16 October 2008

Service Oriented Architecture the solution for IT agility?


Many IT organizations and consultancy firms claim that service oriented architecture and service oriented computing is the solution for enterprises to enhance the agility of their IT architecture. Service-oriented architecture (SOA) is a method for systems development and integration where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes.

One of the challenges for SOA is posed by the inheritance of old legacy systems. Most companies use SOA as an additional layer of code superimposed on the existing layers of the IT architecture. This means that it is possible that a process will fail at some point due to some fault in the layers below, and in order to understand and fix that problem, software engineers will need to deal with the layers of enterprise applications below the modular business processes enabled by SOA. As with ERP systems, complexity remains a challenge. As software grows more complex, reusability becomes a difficult or impossible task – also for Lego-like pieces of code from enterprise systems.

A service-oriented architecture can also be used to move much of the control of the business process to business managers and engineers (if combined with business process management tools) and empower individuals in the organization (via Web 2.0 tools). Combining these different approaches brings agility to the individual.

Further reading:
Service Oriented Architecture Wikipedia

Some opinions in the market:
Cristopher Koch blog on SOA and IT agility (CIO.COM)
Enterprise 2.0 enables business agility
SOA, Business Rule Management and Business Agility (IBM)

Case Studies:
SOA architecture for ING Card (Open Group)

1 comment:

Hans Moonen said...

One of the big challenges with SOA in my opinion is that one should watch out for the generation of another layer of spaghetti code. Especially with "services" and mash-ups/apps that can be generated relatively quick, one should keep the bigger picture, document code and processes.

Agility of IT services means that the technicians have to be fast to adapt to the changes in the business. Fast is still a relative thing; large enterprise system implementations [take the example of the Dutch ministry of defense] can take very long years...

Perhaps one of the large changes would be that it is not IT following the decisions from above; but a combination of local initiatives from the workfloor [enabled by easier tools and easier technologies to for example create prototype systems], and business process driven reengineering initiatives that drive change, and let companies change from the process perspective, in which IT has a lead. That way it is not IT following a changed process; but IT capabilities driving change into novel and innovative processes.

However, as with most things: easier said than done... Good luck with the challenge of researching this domain; and congratulations on this initiative to interact with a wider public.