In the process of evolving a business the question of scope arises in my mind often. If I don’t have a boundary to work within, I can get distracted and the project can go sideways. With business design projects that leverage enterprise architecture (EA) the frameworks often supply a metamodel. I believe it is a key item in scoping and organizing the work.
The metamodel is the model about the model. Said differently, it is the structure I use to categorize and relate the various elements being cataloged and eventually. Capturing the metamodel can take many forms including UML, plain text documents, or more rigorous ontologies leveraging languages like OWL. Regardless of approach this task is less of a technical task and more of an ontological task. Yes, call in the philosophy majors.
Some considerations regarding enterprise metamodels include:
- Establishing common vocabulary. Like common framework, the metamodel can establish common vocabulary for working within the enterprise. If an organization can establish this common vocabulary one can facilitate more rapid discussions across departments and lines of business to identify areas for process improvement and consolidation.
- Defining Scope. What do we really care about and how does it all relate? During my initial framework training years ago, John Zachman contended businesses (and I think government agencies) are much more complex than an aircraft. If we are to “understand and then be understood” regarding a business’ capabilities evolution, we need to have this information cataloged in a tidy-enough way to facilitate planning.
- Aiding Interoperability. We see organizations buy and divest themselves over their lifespan. HP recently announced a split between their consumer and enterprise products & services. I’ve seen retailers buy and then divest their purchases within a 5–7 year period. Having the organization’s elements defined explicitly – even if different – allows the M&A conversation to accelerate. It facilitates identification of common business elements and mapping of differently named items. I would posit an early conversation on M&A activity should include conversations between the respective organization’s enterprise architects to see how their own metamodels align and then begin identification of common capabilities.
- Metamodels are not for stakeholders. Regardless of the metamodel you are leveraging (e.g., Zachman, TOGAF), keep the hairy details yourself. Stakeholders, especially those who are not IT, will not care a bit about the metamodel or the gory details of the semantic relationships between the elements. Since it is part of the EA framework, practitioners should keep it hidden and convey the information in an audience specific manner.
- Metamodel definition is organization-specific. Organizations like The Open Group and The Business Architecture Guild define metamodel for use in enterprise modeling. Users of these models should tailor their models to reflect the needs of their organizations. But only to do so to accelerate learning and evolution of business capabilities. One ontology I’m not willing to suggest tailoring is Zachman’s as he covers the size base interrogatives contained in several modern spoken languages. Yes, I’m afraid of that little pointer he uses during presentations
How is your organization leveraging this portion of an EA framework for evolving a business? Do you explicitly define your organizations metamodel and consistently model the elements? Do you rely on a formal tool? Please let me know in the comments.