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 dogsA 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:

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.

Storyteller
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 DoingNot 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.

As technology architecture professionals, we can only be successful and valuable to those who pay us if we frame our work in terms of capabilities at the outset. If we start with details, we'll ultimately fail.

EA, like the business and IT philosophies that underpin it, is constantly changing. If enterprise architecture is an architecture in which the system in question is the whole enterprise (including business processes, technologies, and information systems), then there will always be dynamism to it. These elements and components are under constant change.

I see CFD (compulsive framework disorder) as an accident of history. Zachman’s well meaning and useful efforts to organise a complicated set of practices didn’t require ontological precision. As a result he did not pay undue attention to the formal coherence of concepts and terminology. Conceptual – Logical – Physical – Really?? Those following with stars in their eyes were disturbed by this. Surely the great man must have meant something perfectly rational by his choices.

This acolyte exegesis sub-culture has to some degree insinuated itself into every further attempt to organise knowledge and practice in EA.

Let them have at it I say. What happens in SUFFE™ club stays in SUFFE™ club.

Cynthia Kurtz

Like. Like more than can be signified by clicking on a picture of a hand with a sky-pointing thumb.

For a long time I thought: why should I write, if there are already enough good writers? And then I understood: for every reader there is at least one perfect writer. No one writer can be the perfect writer for the entire species. If only the best writers write, many readers will never find their perfect writers. In an ideal world everyone would write and everyone would read; then we would all find what we need.

The same goes for frameworks. I suggest a framework version of paying it forward. If you use a framework, you are obliged to make up one of your own and pass it on. That way every smoosher can find what they most need to smoosh.

Well said.

Cynthia Kurtz

Yes I am replying to my own comment, if I may be so allowed. Thought after sleep: the pay-it-forward framework rule should include a flip side: anyone who creates and presents a framework is obliged to show the in-context use of at least, say, two or three other frameworks smooshed together with it. That way they will get past the ridiculous idea that they have found the key to all frameworks.

Done commmenting.

https://me.yahoo.com/wikitecture#206f3 wikitect

c

https://me.yahoo.com/wikitecture#206f3 wikitect

Interesting article.

The argument isn’t so much about frameworks as one that is concerned with standardisation. Every framework that is controlled in any form and used by a number of people becomes a form of standard.

The downside of standardisation can indeed be rigidity but the upside is commonality and consistency. Whether this is of value to the user depends on whether they need to share or collaborate. If they don’t they will most likely only see the downside. If they do need to share or to exchange with others or other organisations then there inevitably needs to be standardisation and some degree of rigidity (configuration management) of the definition.

There are of course ways of managing this and possibly a degree of flexibility (although any extension will risk the ability to exchange with someone who doesn’t use the same extensions or who defines them to be different e.g. same name, different semantics).

As someone in the unpaid gang who maintain and publish the definition of the open source TRAK (http://sf.net/p/trak) I can see both sides. For our purposes we’re specifically trying to encourage interoperability hence changes only occur under central configuration management. Users can, however, extend the framework by forming a working group in the same manner as the IETF works. We also have a mechanism to incorporate ‘non conforming’ views or presentations into an architecture description.

The key is providing mechanisms to extend but not letting it descend into local anarchy. In my experience people always fight against any standardisation but you do need consistency if you’re trying to maintain a repository for any length of time (i.e. not a one-off task) if you want to avoid having to employ experts with the experience to know which are the ‘good bits’ to pick out and query and which to avoid.

https://me.yahoo.com/wikitecture#206f3 Wikitect

Spotted an error.

It is possible to derive a set of building blocks (in a metamodel) that covers any conceivable enterprise or company. This doesn’t mean, as stated, that there is only one arrangement for an enterprise – just one set of parts and relationships between them. It’s like saying you can only make one building from a lego set. The lego set of types allows you to have many possible arrangements using that set of types. This is what a framework with a metamodel does and indeed they all allow you to model (describe) many solutions. The error is in confusing the metamodel with the description (model) of a particular enterprise.

Whether the metamodel has the right set of types and relationships between them to allow you to adequately describe an enterprise is another matter. Some are better than others.

http://www.ivpcapital.com/blog Michael Elling

Frameworks lose their value if they simply capture the present and try to extrapolate that or recent datapoints into a future. Few appreciate that history gets created in one second and gets revised the next. Everything is about context and everything is dynamic; past, present, future. Whenever I read history I am as much amazed by what happened, as by what didn’t happen.

A good framework needs to work across all three temporal states, and account for chance, risk and externalities. Few frameworks account for the law of unintended consequences. There are many more failures than successes in life, but we only focus on the successes and then imbue them with some predetermined or preordained order.

For instance, one of the things I tried to get the digital messaging guys to understand in the 1990s (yes, pagers) was that their success was predicated on the ubiquity of touchtone phones. Because of the breakup of AT&T and WAN competition during the 1980s, the US had 95% touchtone penetration while the rest of the monopolistic, analog world stood around 20%. When I approached the paging companies about a universal, send-side, text messaging gateway (poor-man’s blackberry if you will) they didn’t understand the need because they never understood how important an externality like touchtone was. Had they, with 40 million “addresses” that had tremendous value for sender and receiver alike they may well have owned messaging (wired and wireless) into the 2000s and beyond.

Back to frameworks. Modeling something along one vector gets you 20-30% accuracy across all 3 states. Doing so with 2 vectors improves one’s accuracy to 50-60%. Finally, with 3 datapoints/vectors one’s ability to understand, explain and predict what happened, is happening and will happen improves to 95%+. Direct, indirect and non-obvious causal elements are understood, modeled and more easily predicted.

So choose the 3 most important things that drive your product, then your company, then industry, and then economy and you’ve built a pretty good reference model and context map from which to determine both strategy and tactics.

I use a 3 dimensional framework called the Infostack (geographic, service provision and market/application dispersions/gradients) to map the information and communication networks over the past 100 years. It provides a very good understanding of how the telephone, cable, wireless and datanet business models have evolved with converging supply and diverging demand. I’ve also used the approach to develop strategies in the financial information services industry. It can be applied to any industry vertical as long as one knows and can quantify the 3 key drivers or vectors to any particular story.

gctwnl

Good post (just found it via a link from Tom Graves). I’ve observed that enterprise architects are often more busy with frameworks and ‘how to do enterprise architecture’ than with actual architecture itself. This is one of the signs that EA is in trouble.

A framework is like the carpenter’s tool chest. If the carpenter is constantly fussing over that chest, very little will be produced that has any real value.

Apart from the frameworks themselves, there are, I think, also some fundamentals that belong to the basic assumptions of the trade that are suspect, such as architecture principles, ignoring details, and future state architecture with gap analysis.