Getting into the SOA Mindset

By Patrick Gray

(Back to article)

SOA, or service oriented architecture offers a promising vision—rather than massively complex, monolithic business applications, SOA consist of a series of small applications that each perform a limited function or “service.” For example, rather than a single application providing online banking services, an SOA version of the same might have an application that manages customer logins, another that pulls account balances, and yet another application that creates funds transfers and so on.

If you have ever taken an introductory programming course, this concept probably sounds familiar. Students are admonished to make their code “modular", with each module performing a single, discrete function so that the module may be used again. Even to the non-programmer, this seems like simply good thinking. Why recreate the same functionality over and over again?

Superficially, SOA seems like modular programming on a larger scale, the big difference with SOA is there is a strong emphasis on modular business process functionality, rather than just isolating repeated technical functions.

At its core, a process is about doing something with data. Forget the technical notion of data as bits and bytes, but think of it as something like an invoice. To create an invoice we need to gather various other pieces of information, like a customer name or account number. We also need to manipulate the data a bit, perhaps calculating a late fee or discount on the invoice. We take the data, manipulate it, and spit out new data, in this case our completed invoice.

SOA, done well, sees these data gathering and manipulation events as a service. You need not worry about the underlying technical aspects of each service, as long as you can reliably send data to a service and get back the data you were expecting. An SOA-based application strings together these services in novel ways, and in theory allows you to create new applications by changing how the different services interact.

Imagine your company acquires another. In theory, you can rearrange each company’s services in the right way, you can easily integrate your accounting and invoicing systems.

Getting On Board

So, why isn’t everyone doing SOA? The simple answer is it's incredibly hard. Think of every employee in your company. Does one single person or group understand exactly what information and materials that person needs, what tasks they perform, and what precisely inputs and outputs are required to do their job? SOA requires similar knowledge. Tens of thousands of services must be thoroughly understood, and furthermore there must be a prevalent understanding of how each of these services interact with and depend on other services.

While wholesale implementation of SOA is likely cost prohibitive, getting into an “SOA mindset” allows for gaining some benefit from SOA without breaking the bank. When implementing new business applications, think of the data manipulation that is required and the associated business processes. Seek to break those processes down into component services that can be reused across applications. Eventually you will have a pool of services that can be rearranged or combined in novel ways; creating entirely new applications without the cost of implementing the associated functionality.

SOA also eases testing of massively complex applications, since a business process is distilled into component parts, and each part can function independently. Rather than sending data into a complex system, getting an incorrect result and being forced to wade through thousands of lines of code, an application built with an SOA philosophy allows rigorous testing of each small service—before they are strung together to complete a more complex transaction.

Gaining the maximum competitive advantage from SOA necessitates that once each service is built a corresponding repository inventories each service—what are its inputs and outputs and how it relates to other services. Building such a repository is as critical and likely as daunting a task as building the services themselves, however the return is immense. Understanding the array of services your company has built provides for easy reuse and when well-executed allows non-technical people to quickly grasp what a technically complex service accomplishes in business terms. Colleagues outside IT can now peruse the company’s inventory of services, and design new business applications without a long and painful formal IT project.

While SOA is deep in the midst of the hype portion of the hype cycle, understanding the fundamentals of designing systems around business processes, and ensuring that you keep a well documented inventory of those services will help your organization leverage SOA in the medium and long term.

Patrick Gray is the founder and president of Prevoyance Group, and author of Breakthrough IT: Supercharging Organizational Value through Technology.  Prevoyance Group provides strategic IT consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com.