13 years, 6 months ago

In the white space between stakeholders

Link: http://blogs.msdn.com/b/nickmalik/archive/2011/01/10/in-the-white-space-between-stakeholders.aspx

The more time I spend as an Enterprise Architect, the more I realize just how important this role is.  Yet, the stories that we tell fail to bring across that value.  Our metaphors (framework, capability, roadmap) are woefully inadequate to communicate the actual problems that are solved when an Enterprise Architect is “in the house.”

The metaphor I’m starting to lean toward is this: Enterprise Architecture is the art of understanding the white space between stakeholders.

Of course, this is not a new metaphor.  BPM folks have been using the concept of “white space” for a while.   BPM professionals usually use the term “white space” to refer to the gap between process steps.  That gap is important to the Enterprise Architect as well, but the EA does not stop with the gap between business processes.  An EA is also interested in the gap between business entities (information), the gap between business functions (business), and the gap between integrated systems (integration).

What do I mean by “the white space between stakeholders?”  It is a combination of many things:

  • White space is the gap in alignment between what one person expects will happen and what another person decides to do. 
  • White space is the gap between the way that information is understood and the way that it is actually collected. 
  • White space is the gap between the business function that is responsible for achieving results and the business function that performs both necessary and unnecessary activities in support of those results. 
  • White space is the gap between the performance characteristics of a system that exists and the changing needs of the people who use it.


Enterprise architecture is not the art of bridging any one of these gaps.  Solving for only one variable is a sure route to suboptimization.  Enterprise Architecture seeks to rebalance the tradeoffs between the various variables, creating a new mix of performance characteristics that is better suited for the evolving needs of the business.  The “old” tradeoffs are not wrong.  The business has simply evolved to need a better mix than exists today.

This is not to say that EA is somehow “better” than the related arts of BPM or System Integration or Information architecture.  EA identifies what variables need to change, and the direction to change them.  The related arts are necessary to get us there.  Enterprise Architects are not the people to actually improve the processes or reconfigure the information or reintegrate the systems.  They are the ones who force us to look at our goals and using analysis methods, pick the variables to change: this goal can be reached through a combination of better processes and improved systems, while that goal can be reached through restructuring the information that we will collect and changing the boundaries of various business functions. 

Enterprise Architecture lives in the white space, pulling and pushing and reconfiguring.  We are the “rack-and-pinion” system in your car.  We don’t decide what direction the car should go, but if you want to change course, it is a lot easier to use an accurate and responsive steering mechanism than to hoist a sail and move the boom.