Too many SOA projects focus on assumed – or worse, fictional – business requirements. Such requirements are often not the real organisatioal, technological or availability concerns of the business.
Let me explain; SOA usually comes with pre-determined baggage. IT leaders know the principles and they have a list of expected benefits, such as interoperability and resource re-use.
But be careful not to weigh down your SOA project with your expectations, rather than your users’ requirements. After all, your initiative must map exactly to the goals of the business.
And for that reason, you should forget creating an over-arching aim of developing a system-oriented approach that works to a specific technical flavour.
SOA is much more than standards-based integration and much more than web services, which is in effect another protocol. If you look beyond standards and take an inherently flexible approach, SOA can allow the business to make timely and cost effective changes to business processes.
Rather than working to a pre-determined set of rules, you should have an open approach that relies on your IT people documenting the real requirements of users.
Start small, establish an effective way of working alongside the business and then identify the real requirements for SOA. Not all users will be able to modify processes; not all services will be generic across the business and worthy of a service-oriented approach.
The business will have a series of wider strategic goals that are likely to relate to customer service, efficiency and innovation. SOA can help meet targets in such areas, but only if the flexible processes of service-orientation are tightly co-ordinated with the requirements of the business.
As an IT leader, you must work with the business to identify processes that can be decoupled and easily modified. Think of how SOA’s specific technical approach – such as re-use and integration – can be used to create specific solutions for business problems.
When the business says it wants to innovate quickly, think of how SOA can be used to re-use resources and reduce time delays. When the business says it wants to cut costs and improve operational efficiency, think of how SOA can be used to build a single, integrated platform.
Rather than technical standards, business requirements should be king. Decouple data from underlying applications – and when workflow demands change, users will be able to make simple modifications.
And then your open ear to business requirements will mean SOA can help drive growth.