Ontology?? Sounds very ‘semantic Web,’ doesn’t it? Just smacks of reasoning engines. What on earth do architects using SOA want with reasoning engines?

Actually, Ontologies are misunderstood — 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.

They don’t HAVE to be used for reasoning… or semantic Web. And they are more than a simple glossary which defines terms, because they also define relationships between them — something important for SOA, we thought. It’s also important to note that they are more formal than Reference Models, usually by providing representations in OWL (just in case you want to use popular tools for Ontology and reasoners).

What would an architect do with THIS ontology?

It can be used simply to read and understand the key concepts of SOA, and more importantly, a set of definitions and UNDERSTANDING of key concepts that you can agree to use with others in your company and between organizations. Making sure you are ‘speaking the same language’ is essential for any architect to be able to communicate effectively with IT, business, and marketing professionals within the enterprise as well as with vendors and suppliers outside the enterprise. This common language can help ensure that you can ask the right questions and interpret the answers you get unambiguously.

It can be used as a basis for the models for the SOA solution as well. In fact, this is happening in the SOA repository standard under development in OASIS, S-RAMP, where they have used the SOA Ontology as the foundational business model for registry/repository integration.

The Ontology can also be augmented with additional related domain-specific ontologies; for example, on Governance or Business Process Management… or even in a vertical industry like retail where ARTS is developing service models. In fact, we, the SOA Ontology project, tried to define the minimum, absolutely core concepts needed for SOA and allow other domain experts to define additional details for Policy, Process, Service Contract, etc.

This Ontology was developed to be consistent with existing and developing SOA standards including OMG’s SOA/ML and BPMN and those in The Open Group SOA Workgroup: SOA Governance Framework, OSIMM, and the SOA Reference Architecture. It seems it would have been good to have developed this standard before now, but the good news is that 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.

Heather Kreger is IBM’s lead architect for Smarter Planet, Policy, and SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Cloud, SOA, Web services, Management and Java in numerous standards organizations, including W3C, OASIS, DMTF, and Open Group.Heather is currently co-chair for The Open Group’s SOA Work Group and liaison for the Open Group SOA and Cloud Work Groups to ISO/IEC JTC1 SC7 SOA SG and INCITS DAPS38 (US TAG to ISO/IEC JTC 1 SC38). Heather is also the author of numerous articles and specifications, as well as the book Java and JMX, Building Manageable Systems, and most recently was co-editor of Navigating the SOA Open Standards Landscape Around Architecture.

I think the creaters of the SOA Ontology have fallen into the trap of over abstraction by inventing concepts like “Element” and “Thing”(!). To be really useful, and not just a study, an ontology should define all concepts within an domain. This might mean that there are e.g. relationsships that could be considered as the same type of relationship, but that is OK as it increases the usefulness of the model.
On the extreme side, we could have just one single class, e.g. named “Thing”, with a bidirectional association to itself, many to many, labeled “have relationsship to”.