Three Definitions of SOA? How about one?

My good friend (and OMG Board member) Jan Popkin of TeleLogic has a good piece in Software Development Times (SDTimes) entitled "Three Definitions of SOA".  I generally agree with Jan on most issues (probably as he's right so often) so I was surprised at my negative feelings toward the article.

In short, Jan outlines these three definitions:

• SOA as a technology. Focused on the OASIS SOA Reference Model, this definition is essentially "the technology necessary to connect distributed applications."
• SOA as an architectural principle.  Focused on the OMG's concept of SOA as a way for IT to solve business issues and OMG's ongoing standardization work in business modeling, this definition comes down to "an architectural style for a community of providers and consumers of services to achieve mutual value."
• SOA as an enterprise strategy.  Focused on the concepts of Enterprise Architecture, this definition focuses on what we in the SOA Consortium would most recognize as SOA: a business strategy to achieve business agility.

My biggest problem is with the first definition -- SOA as a technology is Yet Another Integration Technology, and as such, we don't need it.  In my career so far, I've seen far too many "integration technologies" (DCE, CORBA, Web Services, COM, DCOM, .NET, JINI all come to mind) and not enough "integration strategies".  If we as an industry allow SOA to mean Yet Another Integration Technology, we doom ourselves to yet another level of integration middleware, and yet more maintenance hassles caused by the brand-new legacy systems we are installing today.  Please don't let it be so!

SOA is an enterprise strategy, certainly.  Here at the SOA Consortium, the story on which we have focused is that while the IT department is listening now to the value proposition of Service Oriented Architecture, we need to leverage their need to impact corporate strategy, revenue and profit to convince the business leaders, business analysts and project managers of the value of designing the business around processes that can be precisely defined, carefully captured, found again and optimized.  And in order to do that, we must organize the supporting IT infrastructure around the SOA architectural principle -- regardless of the specific integration technology (or technologies) that are eventually deployed.

So I'll spring for the latter two definitions, rolled into one -- SOA is an enterprise strategy based on an architectural principle.  But don't sell me another technology, I've already got too many.

Comments

[Victor Harrison]

I would argue that all three are orthoginal and required. As a set of principles SOA represents ways of measuring value and outcomes; as a strategy (yea!) it couples value to business and mission needs, and as a technology it provides a way of confirming that a particular design is good, bad, or inbetween along with providing a communal understanding of how to "do" it.

The general problem I have is that definitions are necessary but not sufficient. And from these three orthoginal contexts for SOA (a) the devil is in the details, (b) what are the feeds and speeds between the three contextful views of SOA, and (c) how are the objectives and outcomes of one contexful view affected by the others? That, I think, is a quest worth pitching after.

[Richard Soley]

While I would love to agree with you Victor, I just can't. There's a big difference between a reference model which can be used to check the particulars of a distributed system infrastructure for compliance with a set of guidelines, and an approach to managing a business (and its accompanying IT infrastructure) based on recognition of processes and services. While I certainly agree that the first is useful, it's not SOA; we already have enough distributed computing infrastructures! I'm with you on an enterprise strategy based on a set of architectural principles however!

As to your general problem: those are precisely the things we learn from experience, and why the SOA Consortium is focused on sharing experiences, at many different levels. Today's new Consortium deliverable from the Executive Suite SOA working group (http://www.soa-consortium.org/case-study.htm) is a great example of the kind of experience our members are sharing!