Service-oriented architecture promises to integrate disparate applications and promote software reuse. But reaping big benefits requires time, money and people.
"Hodgepodge" is a term that today's midmarket CIO knows all too well. One predecessor after another has left the hapless CIO with something akin to a sick joke: a high-tech jigsaw puzzle of pieces of software that rarely fit together well -- much less form an integrated whole.
Hang on to your hat. There's a technology sweeping the CIO community, one that promises a new way of thinking about software and getting applications to work together. It's called service-oriented architecture, or SOA.
"SOA is really a technology strategy, not something discrete that can be held in a box," says Joe Lindsay, CTO of QS Labs Inc., a provider of compliance applications and services for the life sciences industry. Recently, QS Labs turned to SOA in order to share services among various compliance processes. But what is SOA really, and where did it come from? More importantly, why should midmarket CIOs carefully consider entering its world?
Think of SOA as an overall approach to architectural design -- one that revolves around the concept of loosely coupled business functions or processes, known as services. SOA lets software developers work with existing software and various programming languages, application platforms and server environments. The caveat is that developers must break apart an organization's software into bite-sized pieces and attach special interfaces before the pieces can be plugged into a SOA matrix. Only then can they be put forth as a "service" that can be used by other software.
Just about any piece of transactional software can be a service, such as order entry or invoice generation. A service can even be a snippet of data, such as a customer record inside a customer relationship management system or a price quote that's pushed to a customer's Web-based system. The best part of SOA is that services can be mixed, matched and shared in applications throughout a system.
This was first published in April 2006