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?