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.