I’ve been thinking about architecture frameworks lately. Not that I sit around thinking about architecture frameworks for fun or sport. Rather, I’ve caught a rising number of framework-related tweet wars flying by in Tweetdeck as of late. When I see that, I begin to wonder, “Why are other people so interested in debating architecture frameworks?” Next to the perennial favorite “What Enterprise Architecture is and/or is not,” I’m inclined to believe debates over frameworks are the hottest debates going right now. Why is that?
We’ve had architecture frameworks for decades, so this isn’t a new topic. Sure they evolve and morph as the underlying business they seek to describe changes and morphs, but it isn’t as though some evolution in the way the human brain works or some fundamental shift in business (like, say, the industrial revolution) has occurred. We’re still the same people we were 30 years ago, operating in roughly the same era of business and industrial development (at least at the conceptual level). We still seek efficiency of operations, reduction in costs, increase in profit and better operational dialogue between different parts of our organizations. Then why are we still endlessly debating what an architecture framework is and which one is the “best” for us to use?
Dogma is for the dogs
A framework is an ontology. It’s a periodic table. It’s a work plan. It’s a taxonomy. It’s a decision making guide. It’s a methodology. It’s best practices. It’s a process. It’s a model. It’s a reference model. It’s a meta model. It’s a meta-meta model. It’s a poem by Rudyard Kipling (yes, that is an actual argument).
To be honest, this is becoming more like a religious or political debate, and nobody wins those kinds of debates. If your framework is like a religion to you, well, gosh I am sorry. That’s a pretty dumb topic to get all worked up about and you may want to skip the rest of this post. I don’t particularly care what a framework is or is not and don’t fully understand why anyone really would. The better question to ask is, in my opinion, “Do we need comprehensive architecture frameworks at all?”
You might question my audacity to ask that question. I’m okay with that. But this question has been asked before, and, as a simple Google search will reveal, it’s been answered before. I maintain everyone is wrong, at least partly.
I won’t belabor the myriad rationales given by all the excellent and talented folks in the industry for why we need a framework for architecture. I think we can summarize the reasons:
- Frameworks codify collective, historical experience
- Frameworks engender standardization and enable predictability of outcome, reducing risk
- Frameworks promote repeatability, interoperability and reusability of architecture
- Frameworks promote faster and simpler architecture activity
These are all good things. I’m sure there are others. There’s probably something about lowering cost, speeding delivery and spawning rainbows. No one should be disputing that these are good things to have, nor should we endlessly debate that frameworks help us achieve these things. Herein I just concisely rolled up 19.3 million Google search results for you. You’re welcome. No charge.
I would argue, however, that entirely too much time is spent in the pursuit of the defined framework that perfectly encapsulates and defines all Enterprise Architecture. It’s the equivalent of physicists searching for The Grand Theory of Everything. At some point, it becomes merely an intellectual exercise with no practical application.
We Are All Stupid Now
How many times have you seen perfect, complete, holistic adoption of any of the major frameworks? A couple? A dozen? How often is part of a major framework adopted but the other parts left out because, well, they just didn’t fit this particular enterprise? How often have you seen an enterprise cobble together their own mosh of frameworks to form a structure that works for them? I’m guessing here, but I’d wager a bottle of Lagavulin that the last case represents the overwhelming number of enterprises that have a framework adopted at all.
Why do companies partially adopt frameworks or make up their own? Is this because they just didn’t have the right EA consultant advising them? Perhaps they just don’t have a clue what they’re doing? Maybe they just didn’t know that there is that one framework out there that is the perfect skeletal structure, the scaffolding upon which they should model and build their business? Or is it possible that they do know their own business and have adopted what they believe works best for them, discarding that which doesn’t?
It isn’t that businesses are stupid. It isn’t that frameworks are stupid. It isn’t that we don’t need frameworks. It’s that our frameworks should be more like PowerPoint frameworks. Stop laughing, and hear me out…
It’s alive! ALIVE!
There’s an article out there that suggests that all enterprises are the same and therefore there should be the same schema at the core of every enterprise framework. Fine, OK. I’ll agree up to a point. Yes, every enterprise wants to make money, as efficiently as possible, by serving the customer to the best of its ability. Got it.
But if all aspects of all enterprises are exactly same, why isn’t there a Single, Unified Framework For Everything (SUFFE™) when it comes to describing and conveying detailed, often complex and sophisticated concepts to diverse audiences? Probably because there can really be no single framework that accounts for every conceivable message, level of detail, audience, process, maturity level, role, action, task, etc. If there were, there’d be no need at all for consultants. If you had a SUFFE™ you’d be able to solve every problem (hey maybe we should put that in an appliance and sell it as a business accelerator).
Not all enterprises are the same. If they were, the same solutions would work, unaltered, at every company. We know this isn’t true. While physics may ultimately prove a Theory of Everything, I submit there is no Single, Unified Framework For Everything when it comes to our businesses.
My experience tells me that while enterprises and their problems are sometimes similar, there isn’t a single way to describe or deal with them. My experience tells me the best approach is to know of and leverage many frameworks. Sometimes together.
I’ve created thousands of slide decks over the years, as many of you have as well. When attempting to identify a problem, describe that problem, detail an approach to solving that problem and provide the solution to the problem using PowerPoint, frameworks are an indispensable fact of life. It takes structure, or scaffolding, to tell that story. Sometimes the story is complex; other times it isn’t. Regardless of complexity, the logical structure of the story is crucial to getting the message across to an audience that often includes folks with various levels of understanding of the issue along with competing agendas related to that issue.
To achieve this, there are many, many frameworks that can be applied, depending on the situation. There are entire books (such as this one – no endorsement implied as your mileage may vary) dedicated to structuring information for the purpose of describing something to an audience. Whether describing it to the audience or describing the audience itself, there are many frameworks for telling stories and relaying information about the enterprise. Often, various frameworks are used together.
If the successful storyteller can use and reuse, combine and toss out multiple frameworks when structuring and presenting information about a given situation in the enterprise, why wouldn’t the same logic apply to architecture of the enterprise? Many of the same facets are at play. Yes PowerPoint is derided as fluff and nonsense, circles and boxes and arrows. But a well crafted presentation, with logical coherence and the appropriate level of detail for the audience can have a tremendous impact. To me, this is no different than issues we face as architects as we look at situations, attempt to model or visualize the problems and communicate them to interested parties. Why wouldn’t we leverage the storyteller’s PowerPoint approach to frameworks?
Work Smart, Not Hard
Frameworks should be easy to interpret, fast to deploy, amenable to adaptation. They can be picked up and used or tossed aside in favor of something that is a better fit. The framework shouldn’t fall apart if you decide to remove part of it because it doesn’t suit the problem at hand. The framework can be simple or sophisticated, but either way it should be extensible. Multiple frameworks can be put together or merged to become the methodology for a given situation. These frankenframeworks can be reused. I myself have dozens of them that I reuse or partially reuse on every project I’m on. Keeping this mini-library of frameworks enables me to be agile and flexible. In effect, I’ve PowerPoint-ed my approach to architecture.
Working smart and being agile is one key to improving the image of architecture and the architect. The rest of the enterprise doesn’t stare up at our ivory tower, waiting on the latest pronouncement of what is or what is not in the framework before going about the business of business. Frankly, they’d much rather defenestrate us from the top of that tower than listen to us pontificate on why something is much more horizontally and vertically cross-disciplinary and really more of a method than a framework. The business wants architecture to help it deliver value. Responsiveness, clarity and agility are more important to delivering value than spending a year modeling the world alone in a dark closet someplace.
To that end, a focus on applying the right framework to the right problem is pretty critical. And I don’t think there’s a single “right” answer.
If you go back and look at what I said frameworks can do for us, there’s nothing in that list to suggest only a large, holistic, integrated methodology with a training course and a certification can realize those benefits any better than a quick, dirty, informal methodology. Not that there’s anything wrong with large, holistic, integrated methodologies, just that they aren’t the SUFFE™ you’re looking for.
We Learn By Doing
Not every enterprise is the same, not every problem is identical, and therefore, the approaches to describing and solving those problems won’t be identical. Similar? Possibly. But they will certainly vary. So why not have variations on the framework adapted to suit the given situation?
There are many frameworks. Probably thousands! Endless debate about what framework is better or why we need a new framework that supplants all others (no matter how pragmatic it may be) seems like a waste of time and doesn’t at all address the problem of delivering value. I know my clients would think it’s a waste of time. They want answers, not intellectual thought exercises.
This is a call for the navel gazing to subside. We need to do more of more value and do it more quickly. I submit one way to achieve that is to put aside the endless soul-searching over frameworks. Pick one. Pick ten. Pick two and smoosh them together. Keep them and reuse them. But above all, use what works for the problem you have regardless of what the experts say.