The Purpose of an Enterprise Architecture Framework

Can Social Media create new ideas?  Here’s an example where the answer is “yes.” 

I recently blogged about EA models, and what makes them interesting.  I was thinking about providing insight to people who were in the mood to send me updates to the EBMM… a rather tactical post to deal with a rather pedantic an uninspiring issue: logistics of change.  On Twitter, however, a discussion broke out among rather distinguished architects that took the logic of my post to it’s natural resolution, and it was well beyond my limited thinking to have considered it when I wrote the original blog post.  In other words, they read my post, added insight, and create a novel idea, derived from mine, that I had not considered.

It started with consummate twitter user Mark Nielsen (manielse) noticed my blog post and recommended it.  Tom Graves retweeted Mark’s comment and added his own.

@tetradian: MT @manielse: By @nickmalik: What makes models interesting <<blog link>> … #EntArch >important for all EAs

Richard Veryard then added his own interpretation, restating the premise of my last post.

@richardveryard: #entarch @tetradian @manielse  @nickmalik implies purpose of model is to answer specific set of questions - support a given reasoning process

Tom then did something really interesting.  Using a little judicious editing, he create a new conclusion: one that I did not make in my post.

@tetradian: @richardveryard "implies purpose of model is to ... support a given reasoning process" - yes, agreed / @manielse @nickmalik #entarch

And there we go into new territory.  Richard caught an implication from my reasoning that I had simply assumed, without examining or testing.  Tom then took that implication and used it to reach a higher implication, and called it out in the open.  So let’s examine that resulting implication and then apply that logic a bit further to see where it goes.

The purpose of a model is support a given reasoning process

My prior blog post focuses on the questions that you want your model to answer.  You create a model to answer a question.  If you don’t know what the question is, you won’t answer it (or you will bury your answer in details that are not pertinent to the question).  So first ask the question. 

But why are we asking a question?  This is the leap that Richard and Tom took.  Let’s understand that asking questions, for their own sake, is a rather detached activity.  Enterprise Architects tend to live a little closer to the practical world than that, so we are asking questions that are useful, not just interesting.  And what makes a question useful?

We ask a question, and model the answer, for a couple of reasons:

• We want to guide thought in ourselves.
• We want to guide thought in others.
• We want to answer a question asked of us.
• We want to examine the results of asking a question that we find particularly interesting.

 

Note that I did not say that we are guiding action.  We are guiding thought.  In some cases, thought precedes action.  In other cases, not so much.  But the role of the Enterprise Architect may be to suggest action, and it may include overseeing that action to ensure alignment to goals, but Enterprise Architects are rarely the driver of action.  Someone else funds the action and drives for conclusion.  We are the people who guide thought.  If we were living in a feudal society, we are not the King… we are his advisors. 

The idea of “supporting a reasoning process” is clearly the first two bullets.  We want to guide thought.  We are walking through a reasoning process, either for our own decisions or for the decisions we will lead others to (sometimes both at once). 

Tom’s edit takes on new ground because he allows us to draw a meta-conclusion: that ultimately a model may lead us to a reasoning process when we were not actually planning for it to.  This is the fourth bullet above, and one that I wasn’t really considering when I wrote the post.  What if we don’t know where the model will lead, until we create the model?  What if we are simply modeling because doing so is literally a form of reasoning in itself?  What if we can ask questions of the model that we didn’t think were relevant and wouldn’t have bothered asking, but can only ask because we have the model to answer it?

Now, to extend the thinking just a bit.  What is an architectural framework?  While there are many definitions, there is one possible definition I’d like to propose: an architectural framework is composed of a reference model describing the essential elements of a system, and a series of methods for building instance models within that reference model.  In other words, a framework is a model and the tools to use it to build more models.

The Purpose of a Framework

If the purpose of a model is to support a reasoning process, then, by extension, the purpose of a framework is ultimately to support a particular theory of organizational evolution.  

This notion flies in the face of most framework development efforts. 

Taxonomic transformation, like that proposed by Zachman fans, is a model-driven design approach to mostly IT solutions.  The descendants of TAFIM, including TOGAF and DODAF, follow a methodological approach that builds from a solution standpoint, but which supports the core concept of a single-page enterprise architecture.  Service oriented frameworks like MODAF, FEAF and NGOSS are somewhat middle out, with the core concept being composability of services.  Business oriented frameworks tend to focus on classification of motivations, and usually start with some kind of metamodel like the OMG BMM, the BMGen canvas, or my own EBMM.

Under here are the theories of evolution of a successful organization… but it will take a little archeology to figure out what those theories really are.  Just as we can look at the remnants of cultures long passed and deduce elements about the way that those people lived, we can look at frameworks and deduce the ideas that the framers of the framework had about how organizations could, or should, or must develop. 

Frameworks, like models, are designed to answer a specific set of questions.  But more than that, they are designed to support a logical train of thought from understanding of a situation through proposing a pathway through it to meet a vision of success.  If your organization can only really support one fundamental approach, then you must choose the frameworks that can deliver on that approach in an effective way.

Consider these aspects of each framework.   Consider the idea that frameworks are an outward expression of inner assumptions.  Then, go looking for those assumptions.

If this is where we start, with the underlying assumptions, it is fairly easy to see why some frameworks are appealing to specific people and even corporate cultures, where others are not.  If the framework doesn’t support your view of organizational transformation and evolution, it is tougher to understand and apply it.  Your organization’s culture, politics, and history may end up doing more to help you to select an EA framework than you think.  After all, you can always extend a framework to include a method, but it is tough to deal with the problem of a framework that simply doesn't support the way people in an organization think about themselves and their mission.

This is important because EA has been struggling for years to understand what the possible directions are for academic study and scientific examination.  Using this approach, we can refine and develop succinct theories of organizational development, merge similar frameworks, build commonalities among approaches, and even compare results of company development “in the wild” to see where these approaches lead.

And the Credit goes to…

Who authored the new idea?  Who cares.  I won’t take all the credit.  Perhaps it was first Richard Veryard riffing on my post and then Tom Graves creating a new idea by removing words. Perhaps I went to the conclusion after reading that edit.  I don’t know.   Perhaps it was just social.  Perhaps it is an idea that has already been proposed elsewhere.  I respect that possibility as well. 

Regardless, I think there is a real idea under here.  We have artifacts, real artifacts, to take to our original authors as well as social anthropologists and archeologists.  Let’s ask for analysis and intent.  Let’s find out what those underlying assumptions really are.  We may discover that there are underlying theories of organizational evolution upon which we can base the ongoing development of the EA profession.

Comments

• Anonymous
  October 14, 2013
  The comment has been removed
• Anonymous
  October 14, 2013
  Thank you, Tom.  I look forward to that blog post.   Thanks also for the link on the Bohm Dialog.  It was not a term I was familiar with, but I believe it applies rather well (even if it does fly in the face of "Intellectual Property").  It's easy to see why commercial organizations want to encourage a Bohm dialog within their boundaries, but discourage it outside their boundaries... Alas. In some ways, the approach of starting with a seed and using it to facilitate the starting point of "what questions do we want to answer" is also indicative of a theory of organizational evolution.  I would reverse engineer that theory from your method (and probably be wrong).  That said, I'm brave enough to ask... do you see organizations evolve toward greater effectiveness or profitability through the introduction of shared context?   And does that apply to all organizations, or just the ones where you believe the development of that shared context will drive change?