Why SOA needs an ontology at this stage in the game

Why SOA needs an ontology at this stage in the game

Summary: The Open Group announces the SOA Ontology. What's an ontology and how can it help SOA? And why did they wait until now?

SHARE:

The Open Group has released the Service Oriented Architecture (SOA) Ontology Technical Standard, intended to define the concepts, terms and semantics of SOA in a common language that will allow for more precise and straightforward communications and facilitate SOA adoption without ambiguity.

What's an ontology and how can it help SOA?  And why did they wait until now, when SOA has been on agendas for years?

IBM's Heather Kreger, who contributed to the effort, explains what this all means to SOA practitioners. "Ontologies are misunderstood," she observes. "An ontology is simply the definition of a set of concepts and the relationships between them for a particular domain -- in this case, the domain is SOA."

Don't confuse ontologies in this context with semantic Web, she adds. And, along with being a simple glossary which defines terms, "they also define relationships between them -- something important for SOA."

So why does SOA need an ontology at this stage in the game? As Open Group puts it:

"A lack of mutually agreed-upon SOA terms, definitions and concepts can create interoperability issues that inhibit end-to-end business activities within an organization - as well as between vendor, customer, and partner organizations. By providing common terminology and concept mapping that business and technical people may employ to discuss problems and opportunities, the ontology bridges different architecture, engineering, business and marketing domains. It also creates a foundation for further work in domain-specific areas by supplying a consistent framework that can be reused and revised as SOA projects evolve."

Dr. Chris Harding, the Open Group's SOA Work Group forum director, adds that the SOA Ontology will help proliferate SOA adoption, noting that "the release of the SOA Ontology will significantly benefit the industry considering the increased use of SOA within organizations, especially due to the rise of cloud adoption. It's critical for business and technical executives across disciplines and organizations to have a lingua franca for SOA to ensure the success of their deployments.  As with all of the concepts and models developed through the SOA Work Group, we anticipate the ontology to be a living document that will be updated as the industry evolves and SOA concepts are further refined."

So, SOA has been around for years, why did it take so long to come up with an ontology that's so sorely needed?  As Heather explains it, the ontology is the result of years of implementation work and lessons learned: "It is grounded in extensive real-world experience developing, deploying and communicating about SOA solutions over the past five years. The Ontology reflects the lessons learned about what terms NOT to use to avoid confusion, and how to best distinguish among some common and often overused concepts like service composition, process, service contracts, and policy and their roles in SOA."

The SOA Ontology Technical Standard is available free of charge and may be downloaded from the Open Group website: http://www.opengroup.org/bookstore/catalog/c104.htm.

Topics: Software, Browser, CXO, Enterprise Software, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • RE: Why SOA needs an ontology at this stage in the game

    The Open Group mission of Boundaryless Information Flow

    Think that sums it up. When they can't use real words in their mission statement, then I'm afraid I'm not interested in their ontology.

    Those who can't do work, think that metawork (another new word) suffices. Perhaps we need an ontology of metawork ;-)
    tonymcs1
  • I'm not sure

    Surely having a definition of what SOA is would be a disadvantage?

    At present SOA advocates can claim any successful project as a success for SOA and any failed project as the result of not using SOA (or not using SOA properly).

    Of course no one will admit to not using SOA because saying "we are not service oriented" sounds terrible doesn't it?

    SOA advocates should stand up for their principles: "yes to rhetoric, no to logic!"
    jorwell