Systems are not Services

In our ongoing discussion about what SOA is and is not, it's time to address another popular misconception -- that everything is a service. Nothing could be further from the truth, which is why we also have to follow up with this reality check: SOA is hard.

Too often when working with customers, I hear the common misconception that they are already doing SOA. After all, they have a claims service, a billing service, and an order management service that have all been "web-enabled" therefore they are completely buzzword compliant! This is where we need to be able to address some terminology:

-- Service: A concrete, decomposed, independent functional offering.
-- Application: An aggregation of related services
-- System: An aggregation of related applications.

Now time for an example:

-- Service: User login, Change customer address.
-- Application: User account management
-- System: Revenue Management (encompassing applications like user account management, bill pay, and product ordering)


Thus, having two or more monolithic systems or applications now speaking http does not constitute SOA.

Now, on that note about SOA being hard. The reality is, while SOA makes a lot of sense on greenfield development or in times of major IT overhauls, it's a challenge to decompose a system or application into independent, reusable services and to carry through on their implementation. It will take aggressive sheparding by technical architects to both lay out such a vision and to keep services in their appropriate scope. For many organizations, SOA is enticing but will ultimately prove too overwhelming in the face of declining budgets and more pressing priorities. And, as long as vendors benefit from system lock-in, the likelihood of SOA adoption through vendor selection is unclear.