Understanding the necessary evil of metamodeling
They constrain an architect’s work like a straightjacket, clipping their more creative wings. Team members are forced to learn and relearn different sets of standards and frameworks, and often find metamodeling the bane of their working life.
So why, no matter how irksome or even painful it can become, must we proceed with precise metamodeling in the world of enterprise architecture?
The Basics of Metamodels
To understand why we use metamodels it’s best to establish what exactly we mean by the phrase. An organization comprises myriad moving parts, including people, processes, applications, tools and many more. Metamodels will classify these different elements conceptually and identify the different types of relationship they are able to have with one another. It serves as a map or a guide to the actual model of the enterprise and enables architects to work to a consistent set of standards, which are readily and easily understood by colleagues and consultants alike.
Why Are Metamodels Important?
The key underlying principle behind metamodeling is the need for successful communication. Without being able to provide coherent definition, architects will begin to create their own language or way of conveying concepts. Whilst they make sense in their own head, someone else looking at the diagrams will not know where to begin. Introducing a standardized set of metamodels into the organization, such as those by promoted by TOGAF, ArchiMate or BPMN, provides a set of consistencies for the architect. Yes, these frameworks may at times have limitations, but they also make it possible to provide insight.
By contrast, without coherent metamodeling and a standardized set of types and relations, it becomes impossible to conduct any meaningful analysis. For example, if you want to run a report along the lines of “show me all the servers that run this application”, or “show me what processes implement this business function”, you explicitly need to be tracking a class of entities called 'server', another class called 'application', and two more – 'process' and 'function'.
Likewise, if, when running reports or analysis, you want to be able to distinguish between: “applications that form part of other applications” on the one hand, and “applications that pass data to applications” on the other, then you need to be able to relate applications in those two different ways.
Metamodels though are not a panacea, and can undoubtedly be constraining in certain circumstances. Indeed, imposing a badly designed or inconsistent metamodeling approach is risky; rather your organizations should utilize a flexible and adaptable framework that suits your specific requirements. So as your organization undergoes enterprise transformation, it is therefore important to use tools that integrate with your chosen metamodels, either out-of-the-box or with bespoke integrations. This helps mitigate the pain of metamodeling, and enables you to harness communication, analysis, reporting and view creation, driving change throughout the business.
While constraining yourself to only using a strict set of types and relations is irritating, the fruits of this effort are born slightly later down the line in the quality of insight we are able to generate. Ultimately, metamodels are the price that you and your team pay to be able to run these reports.