The Relative Value of EA Frameworks

When it comes to frameworks supporting business planning, software development, or other activities – I’m a fan. I like organization. I regularly use GTD with Omnifocus on three devices to keep my personal chaos in order. I’m a proponent of developing explicitly work breakdown structures (WBS) for any enterprise architecture (EA) work I’m about to undertake. I like things neat and tidy despite the chaos swirling around.

Over the years a few posts have appeared on EA-related sites and social media either praising or lamenting a framework here and there. I thought it would be useful to chime in on the conversation with my semi-original thoughts. I’m using an EA-centric example and I believe the concepts could easily carry over into other process-centric disciplines such as Lean Six Sigma or other SDLCs.

  • Frameworks provide organization. When approaching a task of business improvement, planning, or implementation of a software-based solution, I find it useful to have a framework for organizing the EA “stuff”. One of the questions presented by my first EA manager was around the topic of scope. The question centered around the following: if we were going to be an EA team, what do we need to manage? What artifacts do we need to produce to drive organizational change? What if an auditor wanted to look at what we were doing – what would we hand to them? At the time we were early in our EA practice still fighting about J2EE and .NET when we stumbled upon the Zachman ontology (notice I didn’t say framework). It expanded my understanding of the true nature of EA and what we needed to manage. In his words, we now had the “periodic table of the enterprise”.
  • Frameworks provide process. For me, I need a process to execute a task. A repeatable set of tasks to be executed. Or at least tailored so I can clear a mental path to done and provide a sense of coverage. This repeatability drives an EA effort towards more predictable outcomes and eventually higher value for an organization.
  • Frameworks require tailoring. My TOGAF instructor stressed this, yet I think the community is missing it. One wouldn’t execute all the steps for every architecture engagement per TOGAF 9.1 – the context of the engagement would dictate emphasis/de-emphasis of particular areas. My mechanic wouldn’t use every tool in his/her toolbox to change the oil in my car. Nor should the EA or other practitioner.
  • Frameworks work for you, not the other way around. At the risk of repeating the previous thought, a framework is a tool. The best way to leverage them is to use the elements that provide value. If something doesn’t seem to apply, chuck it. Professional intuition will drive you towards what provides value and doesn’t for your effort.
  • Frameworks provide a common platform for dialog. Per a recent post, I attended the Business Architecture Guild (BAG) with a couple of my work colleagues where we share the same EA framework. A common understanding within the BAG attendees enabled us to quickly work through tutorial sessions with a minimal amount of time spent on defining terms. Most everyone knew what the other person was talking about which led to better learning and productive experience.

What are your thoughts? Do EA (or other frameworks) inhibit creativity or execution of an initiative? Do you leverage a single framework rigidly, loosely, or synthesize a number of framework elements?

twitterlinkedinmailby feather

1 Comment

  1. Keith Williams

    27 October 2014 at 01:34

    A Good Read Eric.

    Frameworks as you rightly say are there to be adjusted to meet your needs, very much the same as other methodologies, for example PRINCE2, in that they need to be tailored.

    In general a framework can be a great way to include checks to determine if you have considered enough to get the job done, for example you could start with a BAIT model, then apply a different viewpoint, for example TOGAF’s content meta-model to test to see if you have done enough to meet the objectives, or go with the full content meta-model to see how your proposed scope may actually be measured.

    In following this approach it is possible to remain focused on what is needed without over designing / planning, yet at the same time have the confidence that you will have covered the various aspects.

    Having seen both sides of the spectrum around attempting to apply everything upfront and a just do it mentality, applying a logical balance is one that leads to far better outcomes and fewer ooops moments.

    Hence my preference is to define and capture just enough then through refinement over time adjust the architecture models and as needed ways of doing things to meet business needs; this also allows for a change in path that is what is needed. In effect changing architecture to use Eric Reis’s approach from The Lean Startup of Build -> Measure -> Learn feedback loop, with the ability to pivot, yet at the same time be underpinned by comprehensive frameworks.



Leave a Reply

Your email address will not be published.


© 2016 Eric Stephens

Theme by Anders NorénUp ↑