SOA provides an opportunity for ICT to reconnect with the business, but unless it is built and deployed in line with business process requirements, alignment cannot be achieved.
If SOA, as some would have it, stands for 'same old architecture', then it begs the question: what is different this time around? Indeed, the ICT community has sought to build re-usable IT architectures in the past, with only limited success. The fact that today's service oriented architectures are built around a whole raft of commonly agreed standards with significant momentum behind them in most parts of the vendor community is only part of the difference.
The key to today's SOA projects is that they are being built in line with changing business requirements. The ICT community is waking up to the fact that architecture is not something that can be hard coded to meet a particular pain point or built once in isolation from the business problem and deployed many times over - the traditional packaged software model. Instead, SOA as a discipline dictates a particular approach to design, development and deployment, and applied to an organisation's business processes, it brings significant advantages over traditional approaches.
Marco Gerazounis, Tibco country manager – South Africa
The IT/business disconnect
The packaged software model has in the past created a disconnect between IT and the business with IT playing catch-up with business requirements. As a new product offering or business opportunity arises, development teams are deployed to write code or implement packaged systems.
Applications vendors develop new applications that cater to every conceivable niche - just looking at the number of modules in an enterprise application suite from the likes of SAP or Oracle gives you some idea of how complex this kind of approach to development has become.
Connecting together new developments is difficult - and organisations have employed point-to-point connections to pull in data from previous developments, creating a spaghetti code of integrations unable to maximise the benefits of each successive round of effort. The middleware industry has built up around this, designed to bridge the gaps between applications, but has often ended up adding an extra layer of complexity around application-to-application integration, and entrenched the feeling that IT is still playing catch-up.
Analyst group Macehiter Ward-Dutton says the IT/business disconnect manifests itself in four areas - firstly, the high cost and risk of technology integration; secondly, the difficulty of getting access to the right information at the right time; thirdly, the time and effort involved in modifying systems; and fourthly, the uncomfortable truth that IT expenditure is bloated and fixed - leaving organisations bemoaning the fact that they do not gain incremental benefits from successive rounds of IT investment.
The benefits of SOA
The reason so much has been made of the benefits of adopting an SOA approach to systems development is that the argument is appealingly simple: if elements of functionality can be offered as services, then these services can be re-used from one project to the next. However, there are a number of caveats.
Examples such as a credit check illuminate the argument. The check will be used many times over by multiple applications, including customer management and financial management applications. Rewriting the core code that carries out the check is duplicating development effort, so the application interface is made available as a web service, and multiple applications can access it.
If services are developed at the right level of granularity, as part of a broader picture of development, they can in theory be re-used multiple times. But this description is an oversimplification of the architecture - and if enterprises do not enter into development with service quality, lifecycle and most importantly, governance, at the forefront of their minds, then greater chaos will ensue. Too fine-grained a service and consumers will probably be more comfortable writing their own version, too coarse-grained, and it will not be re-usable across different applications.
The wider benefits of SOA come from the flexibility provided to the entire software architecture for future change, and the speed with which these changes can be achieved. Users have documented significant productivity gains from an SOA approach to development, finding developers are not only freed from the grunt work of writing low-level code but also as a consequence of this, have more time to focus on what is really important to the business. They also point out that productivity improvements do not come immediately in an SOA, but incrementally as successive projects are implemented.
The role of process
Macehiter Ward-Dutton says the challenge in designing services to support business process requirements is that services are also unlikely to fit into neat boxes marked 'Web service' (early experiences show only a small percentage of services in an SOA are based on classic SOAP messages). Moreover, they are unlikely to remain static throughout their lifecycle, and most importantly, there will be a complex relationship between providers and consumers.
However, there are some useful guidelines in moving from a 'tightly-coupled', narrow view of business processes, where the user interface, data structure and application code are locked together to a 'loosely-coupled' approach where in the analyst's words, 'resources provide services that are designed to support the interactions that take place within a business process'. In other words, the focus shifts to a higher level of process that manages processes, the complex layer where value is really delivered.
The greater process maturity required by the business is the first challenge for many IT departments, precisely because the disconnect has existed for so long. At a basic level, it seems the tools that IT architects and business users have adopted to do their jobs are incompatible. Ultimately, a new environment for building and modifying business rules, processes and management structures is needed, linking together the technical plumbing and the process modelling environment.
The enterprise architect
Realignment also brings organisational challenges. Within new developments, there are processes that need to be managed - sign-offs on development quality, governance structures and incentives to develop within a service-oriented development framework. But beyond development itself, there is a new role emerging that bridges the IT/business divide, ensuring at a basic level that the two are singing from the same hymn sheet.
When a business thinks about process improvement, it tends to look at areas such as improving customer service efficiency, speeding up customer onboarding and rationalising internal operations. SOA is a key enabler of that strategy as it allows IT to respond more rapidly and with more flexibility. However, the IT department cannot set about service-enabling every IT asset in the organisation - it needs to focus on areas that support business strategy.
Translating complex process needs into service requirements is a new challenge for most organisations, especially as they are invariably hampered by great complexity in the existing application environment.
Systems architects are still in many cases focused on the technical capabilities of the architecture, but a business process or enterprise architect can help the business to interact with IT at a level that was not previously possible.
Building business services and defining them as part of a business process and quickly deploying them within a business context requires an individual who understands both the technical plumbing and the business goals and the key performance indicators that feed out of them.
Empowering an enterprise architect to fulfil this role could be the most important decision an organisation makes.
For more information contact Marco Gerazounis, Tibco country manager, 011 467 3111, firstname.lastname@example.org