It is nice to point out, on occasion, when two different leaders in the architecture community are saying things that, when added together, become greater than the sum of their parts.
First off, my friend and colleague Gabriel Morgan recently described the business value of creating a single underlying model to connect all aspects of a particular software project (from requirements through code). He calls the model a Solution Model, and rests that model firmly on a metamodel that allows these underlying elements to be related to one another in a useful way.
His blog post, which is long and richly detailed, is not about modeling. It is about value. I recommend it highly.
"this blog is about understanding the value of modeling to a project team and is focused on helping Solution Architects gain a practical understanding of the value of modeling to, in turn, help explain its value to the project team for adoption." (Gabriel Morgan, from his blog)
The other contributor is Jean-Jacques Dubray. He recently posted a very interesting article on "Model Driven Engineering" where he discusses many things, including the value of a metamodel.
"My recommendation to developers and architect is: metamodel (as a verb), metamodel completely and thoroughly and even if you don't create a [Platform Independent] model of your solution and a compiler (based on this metamodel), write code with the metamodel in mind (this will end up looking like a framework of course). For instance, define precisely what a business entity is, an association, a business process, a task... Remember, you are NOT creating an OO model, you are creating a metamodel. Every solution domain has a metamodel. There is nothing absolute about it, the metamodel of an information system is different from the metamodel of an industrial process control system, and what works for a travel company may not work for an insurance company." (Jean-Jacques Dubray, from his blog)
What makes these blogs interesting is not that they are about the same thing. They are quite different from one another. What makes them interesting, together, is the deep and fundamental support that each provides to the practice of "using the metamodel." This is a term that is not discussed much, but it should be.
The metamodel is the conceptual information architecture that classifies the information that we can use to construct solutions, understand problem domains, and create practices that insure that we build the system that we should build. As JJ points out, the terms matter. As Gabriel demonstrates, those connections are valuable.
The metamodel is key. With it, we can tie the requirements to the design in a way that supports agility. We can say, definitively, what the impact of a change in requirements will have, allowing us to select the requirements that we want to change in order to have a desired effect. This is powerful, and necessary.
And it all starts with the metamodel.