Same Word, Different Meanings: Still Chasing Down a SOA Definition

Sometimes, when my 5-year-old daughter wants attention, she'll start asking me questions. The why questions are actually the easiest because I can always look it up. "Why is the sky blue?" she'll ask. "I dunno," I answer. "Let's look it up on the Internet."

The stinker questions are the "what does X mean" questions. She'll start out with something broad, "What does blue mean?" And if I succeed in answering, she'll become more and more abstract, usually ending with something like, "What does 'is' mean?"

That's how it is with meaning. Sometimes, it's just not enough to define the term. To really understand, you've got to drill down and define the words used in the definition.

Dan Foody, VP of Actional Products at Progress Software, suggested recently this may be the problem with defining SOA.

Writing on Progress' SOA Infrastructure blog, Foody drilled down to examine what people mean by "architecture" when they talk about service-oriented architecture. He was inspired by a recent Sys-Con column by David Linthicum, who defined architecture as "the orderly creation, placement, configuration and management of IT assets."

That's a fine definition for enterprise architecture. But that's not the only way to define "architecture" in IT, Foody argued. Often, when people talk about architecture, they're actually referring to application or software architecture, he wrote. This type of architecture is defined by Wikipedia as "the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them."

The problem is, nothing about "SOA" clarifies which type of architecture you mean. Foody wrote:

"So, maybe we really need two terms: * Service-Oriented Enterprise Architecture (SOEA) * Service-Oriented Application Architecture (SOAA) Once you recognize this, a number of things start to fall in place. Both of these have value... but they are different."

Semantic conversations can get pretty darn tedious, but clearly, SOA still needs some clarification. And this isn't the first time I've heard it suggested that part of the problem may be related to too broadly using "SOA."

During a recent interview with Nick Gall, the Gartner analyst who coined the term Web-oriented architecture, he pointed out that there is a pretty consistent style of architecture that uses Web services and usually some middleware.

Many people call it SOA, but it's actually not technically SOA -- hence, the unending admonishments that "SOA isn't JBOWS" which means SOA isn't just a bunch of Web services. It's tricky, though, because while it isn't technically SOA, it could theoretically be used to build SOA, if it were loosely coupled. But it's usually not and, as it stands, this widely deployed approach has no name. Gartner's actually looking at how to name and classify this it.

My interview with Gall focused on the whole question of whether Web-oriented architecture is a subset of SOA or something altogether different. Gartner and Gall contend WOA is a substyle of SOA, as he explained in the interview.

I think Foody's post also speaks to why so many want to insist WOA is something new:

"Arguably, most enterprise architects think of SOEA and so the term SOA (at least among the purists) has drifted towards meaning SOEA. Unfortunately, this has alienated a lot of people, because a lot of people experience the value of SOAA every day (Web 2.0, SaaS, and cloud computing are great examples of SOAA but have little to do with SOEA) but don't think of it as SOA."

Unfortunately, clarifying definitions in IT circles is a bit like herding cats -- it's just about impossible to get everyone to agree on one direction. It's only slightly easier than defining "is" to a 5-year-old.

IT Solutions Builder
TOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD

Which topic are you interested in?

Mobile

Security

Networks/IoT

Cloud

Data Storage

Applications

Development

IT Management

Other

What is your company size?

What is your job title?

What is your job function?

Searching our resource database to find your matches...

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Loraine:thanks for your post the other day. I am honored to have made it to your column. I just would like to add that even as a reporter you can choose to root your articles in experience or not. A lot of reporters are simply eager to report extremely "forward" thinking thoughts.To answer your question: I think it is important to distinguish between to types of "architecture":a) as you build a system, an architecture is the set of blue prints that facilitate and guide system construction. Some elements of the blue prints are reusable and defined at the enterprise level, hence the concept of enterprise architecture.b) as the system is built, you can talk about the architecture of such system. At this point you are more likely to talk about an architecture style. In that case it describes the common characteristics of a class of systems. The catch with SOA is probably because it is neither... sorry I don't mean to confuse you, but for me the definition that works is a Service Oriented Architecture is a set of assets (the services) that can be reused to construct entire classes of solutions. Please note that an asset is a running agent, it is not a piece of code or a component. Such a solution is called a connected system (which is different from a distributed system).I don't see any analogy in Residential Architecture. It is not a blue print (you can define the blue print of a solution built within a SOA), it is not a style since different architecture styles (including REST) can fit the definition of an SOA. Now should we use the word "architecture" for something tangible, I'll let you decide. Reply

Sep 16, 2008 8:16 AMRob Eamon
says:

Foody's comments about SOA applying to different levels of architecture is something that has been discussed before. Personally, that's a notion I always try to promote--the "SOA" term does not imply enterprise or application or business level. And that's where the disconnect comes in, as Foody notes. Someone *assumes* SOA means enterprise architecture, while someone else *assumes* it means application architecture. But we don't need more terms. We have plenty.Foody's and Linthicum's definitions of architecture do not conflict. They are the same: "the components of a system and the relationships between them." This definition is accurate at the business level, the enterprise/technology level and the application level. The confusion is in the assumption of a level when using the term SOA.As such, SOA needs to fade from the picture, IMO. The architecture of interest is the business architecture, the enterprise architecture, the application architecture, etc. Focus on creating those architectures and apply SO principles, and others, to them. SOA as a term must die. Reply

I first presented at Network/Interop in 1996 entitled "Services Based Architectures" which is still relevent today. A services based architecture is one where the architectural "layers" (Business Architecture, Application Architecture, Information Architecture and Infrastructure Architecture) are designed to be integrated using abstractions. Just as one builds an addition on a home, an architect designs plans for the many components (foundation, roofing, plumbing, electrical), why are software systems any different. As an Electrical Engineer, I was taught to think logically. A Services Based Architecture is a component-based approach to solving a complex problem (note - this is not an object based paradigm) - the integration of the enterprise. Having built over a dozen SOA's (the Gartner term which refers to a specific type of applications architecture within a Services based architecture), many Event Driven Architectures's and a number of Web Services architectures, I can say they all have common threads - architectural integration, layered abstractions, business process decomposition (or alternatively wrapping of systems or data), metadata (web does not use this one), and of coarse governance. Without these basic components, what you probably have are web mashups - or just calling someone elses web service like a google map... The definition from 1996 is still very applicable today - only the vendors products and terms of use have changed! Reply

Like it or not, the DNA of IT is changing. Thanks to economic slowdown and cuts in IT budget, CIOs have to go lean and ensure good returns on IT spending. They have come under pressure to change their traditional approach to IT development and seriously explore technologies and approaches such as Cloud, SaaS, SOA, Lean IT, Green technologies and so on.

Developers, architects and other IT professionals have also come under pressure to adapt to the changing IT landscape. They have to rethink the tools of their trade, the platforms they use, get familiar with emerging approaches and frameworks to stay relevant. There is one conference which offers them a front row seat to the rapidly changing IT world.

The international conference is designed to give progressive executives and developers a ringside view of the current developments in the emerging critical technologies. It will feature technical sessions from leading industry players of the Cloud ecosystem - the infrastructure firms, the platform providers, and application developers.

SOA India 2009 caters to the need of Indian Enterprise IT community of CIOs, CTOs, Management, IT directors, IT managers, IT architects, Network and Infrastructure specialists, Project Managers, Project Leaders, and Software Architects.

If you are responsible for business optimization, designing, developing and/or implementing your organization's IT strategy, join us this year for an unbiased source of insight, and expertise from the top experts to ensure the success of your initiatives.

To avail early bird discounts or for more information Call +91 080 41124392/93 or visit conference website www.soaindia.com.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.