Service Oriented Architecture Conceptual Model
Almost two years ago, I described some of the key concepts of service oriented architecture, including the distinction between a canonical model and a canonical message schema. Since that time, I worked on a wide array of models, including Microsoft IT’s Common Conceptual Model. That model (CCM for short) is the metamodel for IT concepts in Enterprise Architecture.
I received a note recently about that old post, and how valuable it was to the reader. It occurred to me that those concepts were part of our Common Conceptual Model, and that a “SOA-Specific View” of the metamodel may prove interesting. It was.
I’ve attached the SOA view of our Common Conceptual Model for this post.
A quick set of notes on my conceptual models.
- Two terms separated by a slash (Application / Installable Software) are distinct terms for the same concept.
- The associations are all “arrows with verbs”. Read the associations along the direction of the arrow. (e.g. “Application Component implements a Shared Service”). I intentionally avoided using UML notations like “Composition” and “Aggregation” because they are difficult for non-technical people to read.
- Many verbs on an arrow – The stakeholders couldn’t agree on which verb best described the relationship, so we used multiple distinct verbs.
- In my prior post, I used the term “Canonical Schema.” Our stakeholders preferred “Shared Message Data Contract.”
The key relationships to notice in this model are the ones that may be the least expected ones: the connection between the obvious SOA concepts like “Contract” and “Canonical Entity” and the not-so-obvious SOA concepts, like Business Process and Business Event.
When SOA is done well, it is part of a seamless ecosystem between the processes that people perform and the systems that support them. Being able to see the parts of the system and how they connect is key to understanding how to build a truly effective service oriented architecture.