Can EA Data be independent of the Metamodel?

One thing that I’ve come to appreciate is both the importance, and impermanence, of the Enterprise Architecture metamodel. 

If that last sentence didn’t piss you off, you weren’t listening.

I’ve found two common groups of Enterprise Architects:

1. Folks who do not understand, or care, about EA metamodels.  Starting with Zachman aficionados, and working up to some practitioners of Balanced Scorecards, Business Process Management, and Business Strategy development (all fields that benefit from, and are necessary to, metamodels, but which were developed entirely without that concept).  To the credit of many folks who have come up from these fields, they have seen the value of metamodels along the way and moved to the second group.  Others, unfortunately, have not been able to see the holistic value of understanding knowledge using a connected model of well-defined concepts, and remain in the camp of “metamodel doubters.”
2. Folks who believe that there should be a solid, unchanging, metamodel, and that all business and technical metadata should fit within it.  The ranks of this group are growing rapidly, as TOGAF has adopted the concept of metamodels and as groups focused on Business Architecture have brought out research materials and books dedicated to specific metamodels.  Readers of this blog will note that I produced a metamodel of sorts with the EBMM (Enterprise Business Motivation Model) nearly two years ago now, with an update to come soon.

Unfortunately, there are flaws with the thinking of both groups, and I’d like to propose a third way…

I’d like to propose that metamodels should be created as part of the “view", and not part of the “model” itself: That data will exist independently of the metamodel, in a manner that can be formed into a metamodel that is custom-suited to meet a particular need, at the time of that need. 

Kind of hard to imagine, isn’t it?  After all, as Information Scientists, we think in terms of the data structures… how data will be created, stored, manipulated, and consumed.  And ALL databases have a data model.  (the relationship between tables, fields, keys, indices, triggers, and constraints, as concepts, is an underlying RDBMS model).  How, exactly, can we store data in a database without first creating a single model that describes the type of data that we intend to store, how it will be stored, and how it will be related?

Yet, we’ve seen the field of “unstructured data” blossom in the past decade with the emergence of search engines like Google and Bing.  These engines have brought ever-increasing sophistication to the notion of “answering human questions” from data that is not, fundamentally, structured into an information model.  That said, the most useful data in unstructured systems is still classifiable into complex types, and that classification allows the usefulness of that data to come through. 

For example, if I go to Google and search on a local department store, I could type “Kohls in Covington WA”.  I will get the results below.  Note that if I go onto Bing and issue the same search, I will get nearly identical results.  In both cases, model is applied.  The word “Kohl’s” is taken to mean “a department store” and from that, we can add attributes.  After all, department stores have phone numbers, addresses, can appear on a map, can have items on sale, and, almost as an afterthought, can link to a web site.  

The search results illustrate far more than just links to web sites.  The search engines are applying a classification to the otherwise unstructured information.  To add value, the question is understood, and results are produced, based on classification.  This “result” is not just a web site.  It is not just “random unstructured data.”  And the results are more useful as a result of this understanding.

Imagine that we have a search engine that works for business and information systems structural data instead of web sites.  We can “know” a great deal of information about business motivation, strategy, competition, business goals, initiatives, projects, business processes, IT systems, information stores, software instances, etc, all the way down to servers, network infrastructure, and telephone handsets.   But can we “apply the appropriate metamodel” to the data at the time when it is needed?

In other words, can we answer questions like these?

• What systems need to be modified in order to improve competitiveness as expressed through the business goals of the Retail unit? 
• What is the accumulated Return on Investment of the projects that have completed in IT in the past two years?
• What gaps exist in the initiatives chartered to create a strategic response to the competitive threat posed by the Fabrikam corporation’s new product line?

Can we do it without pre-specifying a metamodel?

Folks in the second camp above will ask an obvious question here: why not catalog data according to a single super-dee-duper, one-size-fits-all metamodel?  After all, once you have the right metamodel, every one of these questions can be understood and answered.

Let’s parse that idea a little… What makes a metamodel “right?”  I would venture that a metamodel is not “right” or “wrong.”  It is simply “useful” for the purpose that it is being used for… or not.  For example, sometimes I care about the distinction between a business process and a business capability.  Other times, I do not.  If my metamodel is static, I must always collect business data according to a single unified taxonomy, or I must always have two different taxonomies.  But the world is not so simple.  Sometimes, I need one.  Sometimes, I need two.  The metamodel is dependent upon the question I’m asking and the problem I need to solve.

In other words, the metamodel itself is a dependent variable.  Only the raw data, the business stakeholders, and the business concerns themselves, are independent.  All the rest is self-organizing and, here’s the problem, changes depending on the situation.  The structure, relationships, and important attributes of any one set of elements is particular to the problem that the stakeholder is solving.

So, I will re-ask my question: can we collect information in a manner, and understand it in a mechanism, that allows us to apply different metamodels to the data depending on the need of the stakeholders?

I think we can.  I think we must. 

Technorati Tags: Enterprise Architecture,metamodel