|
One of the most significant IT initiatives underway is the adoption of service-oriented architecture (SOA), where IT assets are aligned to business services in a standard, flexible and architected fashion. The concept is often discussed in conjunction with Web services, though the two are not synonymous. In fact, SOA predates Web services by many years, but it is only now that SOA has hit the headlines. This is due in part to the fact that Web services have been a useful development that makes it much easier to deploy an SOA.
The promise of SOA is that it can transform the IT assets of a business, making it possible to do more with less, and faster. It is a key development towards the goal of a truly agile business where new business initiatives can be deployed as needed?with th e necessary underlying IT support?with minimal delay. But there is also a concern in many CIOs' minds that SOA is a radical new form of software infrastructure requiring extensive changes across the entire range of IT systems. In today's business climate, getting the investment to fund such an exercise would be hard (if not impossible), even though the attractions from an IT perspective of a clean, component-based architecture are considerable.
So, how to make the business case for SOA?
In fact, the rationalization is not as hard as it might seem. First, because of the software engineering "feel" of SOA, there is a tendency to look at it as delivering purely internal IT savings. Justifying expenditure on this basis alone can be extremely difficult. However, once the more significant returns of business effectiveness and agility are taken into account, the justification looks much more positive.
Secondly, SOA does not need to be fully implemented and deployed before benefits can accrue. In fact, SOA is ideally suited to incremental deployment, where investment can be made on a step-by-step basis tied to individual business projects. Returns also start to be realized on an incremental basis, thereby removing a major element of business risk in any justification process and greatly increasing the likelihood of acceptance of the business case.
By taking these factors into account, it becomes possible to make a strong case for adopting the SOA vision and deploying it in all new projects. However, in order to avoid surprises further down the line, the business case needs to take into consideration the requirement not just to implement SOA concepts, but also to put into place an enterprise-class SOA infrastructure. It is this infrastructure that makes SOA real, makes it useful, and transforms it from being a concept into a true enabler of the agile business.
THE PROMISE OF SOA
The concept of SOA has been around for some time. Although the term first emerged in the 1990's, the spirit of SOA existed long before that. The underlying principles of SOA - componentization, encapsulation, separation of interface from implementation, loose-coupling, etc. - have been promoted since the early days of computing. However, achieving these goals was, in many ways, easier in the days of centralized computing and when the focus was on IT resource optimization.
Then the landscape changed. On the technology side, distributed computing arrived, offering great productivity and price-performance, and the Internet emerged, promising ubiquitous connectivity. On the business side, IT was seen increasingly as something that could be used for business advantage. But these changes introduced considerable challenges in linking different technologies and platforms together and mapping the IT infrastructure more closely to business need. The advent of object-oriented (OO) computing paved the way that eventually led to SOA by introducing the concept of having discrete program components with standard inputs and outputs that could be used as building blocks to assemble applications.
SOA Concepts
In SOA, these application building blocks provide a specific "service", that is, a business process step such as "Create Invoice" or "Customer Lookup". These services are implemented with standard ways to invoke them and are "loosely-coupled" ?tha t is, they can be invoked without the caller needing to understand anything about the technology choice or location of the service provider. Thus, the "Customer Lookup" service can be invoked from any other business application that requires customer information.
|
