The Zachman Framework Requires ZERO Documentation

The Framework is the Ontology

I have no idea where people get the idea that the Zachman Framework requires any documentation at all.  The Zachman Framework is an ontology – the theory of the existence of essential components of an enterprise (actually, of anything) that warrant description in order to successfully create it, operate it or change it. Whether any or all of those components are described (documented, made explicit) is a function of a methodology and the choice of the Enterprise… not a requirement of the Framework.

Models give you Power

Somehow or other, people hear me say, “Stop the music for 15 or 20 years until you get all of these models built and then you can start writing code again.” I have NEVER said anything even close to that.

What I have said is, “Some day… SOMEDAY, you are going to wish… forget you… SOMEDAY the ENTERPRISE is going to WISH they had all of these models made explicit, all of them Enterprise-wide, all of them horizontally integrated, all of them vertically integrated, all of them at excruciating level of detail.” Why?  Because, if they had all of those models made explicit, they would have a VERY powerful capability to accommodate extreme complexity and extreme rates of change. I have NEVER said when I thought that would be. I have ALWAYS said that might even be utopia… you might NEVER formalize all of the models. I have said, the 80/20 rule probably is in effect. If you have 80%, you might not need the other 20%. In fact, if you had 20% of the models, you might not need the other 80%. I also have said that in order to achieve the utopian condition of all the models formalized, it likely would require a lot of work and therefore, methodologically, you will probably have to figure out how to achieve that iteratively and incrementally over some longer period of time.

By the way, I ALSO always say, you can deliver substantial, immediate Enterprise value from a relatively small sub-set of Primitive Models. A little order goes a long way!

By the way again, there ARE implications to not producing any one of the Primitive Models identified by the Framework. Any model that you do not make explicit is implicit. By definition, you are making assumptions about any Framework Primitive Model that you have not made explicit and those assumptions may be right… or they may be wrong. Erroneous assumptions in manufacturing are called “defects.” Removing defects from anything is expensive and the closer you get to providing the implementation of the end result into the hands of your customers (“users”) before you discover the defect, the more costly it will be to remove it. (This is statistically provable… see Capers Jones work on “Software Quality”). Therefore, SOMEDAY, it would be in your best interests to have made all of the Framework Primitive Models explicit… however, you may be willing to assume the risk of some defects (the fewer, the better) at any given point in time.

The Framework gives you Power

The Framework is the ontology… NOT a methodology. The Framework implies nothing about which models you might want to produce (make explicit) or whether you want to produce any models at all. It implies nothing about how you might want to produce the models: top-down, bottom-up, left-to-right, right-to-left, where to start, etc. Although these are significant methodology choices, they are not prescriptions of the Framework. The Framework simply identifies the total set of architecture possibilities and therefore, the nature of the risks that may be or may have been assumed.

Author

John A. Zachman

Alignment – Mobility

Positioning one’s own personal brand is something that may not come naturally to some folks. One may think that only applies to marketing types. But it doesn’t. Its important to demonstrate a sense of flexibility and awareness to one’s contirbutions within organizations. Personally, I think a bit of variety in one’s career is beneficial and […]

The Dilemma: Communicating IT Business Value

SCENE 1, MID-AFTERNOON, FADE IN:
IT walks through the door after a checkpoint meeting and sits on the couch.
Doctor: What brings you to my office today?
IT: I think the business might be leaving me for a younger, slimmer, sexier, IT alternative.
Docto…

Categories Uncategorized

Quantitative Semantic Algebra – Dr. Barry Robson (RQSA)

RQSA Theory – Develops algorithm for The QEXL Approach; overcoming limitations in gold standard Bayesian Network; while allowing for creation of generative models. Bayesian as such is an adaptive technique. (March 8 2013, Version March 10 2013) 1. INTRODUCTION 1.1. Purpose and Background. The following document describes principle features of a mathematical system of practical […]

Dotting the joins (the JEA version)

[The new editor of the Journal of Enterprise Architecture, Len Fehskens, asked me to expand my previous post ‘Dotting the joins’ into a formal paper for the Journal. Which I did, and it was duly published in the August 2013

Enterprise Architecture: The Real Game Changer.

In part 14 of “Memoirs of an Enterprise Architect” I discussed 8 steps to make strategic business decisions.  This week marks the last part of this blog series.
Has your viewpoint on Enterprise Architecture changed?
The landscape for business in t…

Categories Uncategorized

Espoused EA and EA-in-use

In their seminal work on human and organizational learning, Chris Argyris and Donald Schön (1974, 1978) make a distinction between espoused theories and theories-in-use. Espoused theories are accounts of a person’s or an organization’s actions given to others, while theories-in-use…

Categories Uncategorized

Business Models in Business Architecture

It still surprises me to see various discussions of business architecture where there is a poor understanding of the relationship between business models and business capabilities.  The vast majority of discussions of business architecture, including books, articles, and blogs, make very little mention of business models, and nearly never discuss their relationship with business capabilities, organizations, stakeholders or resources. 

To me, the concept of a business model is fundamental to using business capabilities.  I cannot imagine attempting to understand a commercial organization without understanding the business models of that organization as a first step. 

In this post, I will discuss the reasons why business architects must consider business models.  I’ll start with some definitions to minimize confusion, given the fact that everyone has different definitions of these concepts.  I’ll then discuss the concerns that I have about the lack of integration of core concepts.  In a future post, I will discuss the various information models for including business models into business architecture as well as needed changes to business architecture methods (including capability analysis) in order to correctly place this role.

Caveat Emptor: The following discussion of business models will focus on commercial systems.  If you are examining this space from the standpoint of a non-profit organization or government agency, your needs may not be well represented.  My apologies.  The reason for this will be immediately apparent when you read the definition of “business model” below.

Definitions

The Business Architecture Society and the Business Architecture Guild have joined forces and created a common definition of a “business capability.”  From the Business Architecture Body of Knowledge Handbook: “A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”  Note that the BIZBOK cites Ulrich Homann as the originator of the definition.  For the sake of this discussion, let’s take this definition as a given.

There are many definitions of a business model.  Perhaps the most popular definition today comes from Alexander Osterwalder, author of the popular business book “Business Model Generation.”  However, his book doesn’t have the same level of discussion of a definition as the Ph.D. thesis that he wrote in which he defines a business model as follows.  “A business model is a conceptual tool that contains a set of elements and their relationships and allows expressing a company’s logic of earning money.  It is a description of the value a company offers to one or several segments of customers and the architecture of the firm and its network of partners for creating, marketing and delivering this value and relationship capital, in order to generate profitable and sustainable revenue streams.” [Osterwalder, 2004]

Osterwalder carefully notes that a business model is not a representation of the business organization itself.  He states, and I concur, that the business organization is the “material form that the conceptual business model takes in the real world”. [Osterwalder, 2004]

I will also take a moment to define business strategy.  This time, from Kaplan and Norton: Business strategy is a description of how an organization intends to create value for its shareholders, customers and citizens.  Note that this is not the same as a business model. Osterwalder addresses this distinction by illustrating that one can view strategy, business model, and process model as a three-tier hierarchy.  The top level, business strategy, describes the conceptual approach to business change.  The business model goes into more detail, describing the relationships between various components.  The third level, process, illustrates the association of activities to the people and business functions that will perform them.  All three are necessary, but all three are different in level of detail and analysis.  The following picture is directly from his Ph.D. thesis (click to enlarge for readability).

Osterwalder

 

Concerns

One of the challenges in bringing together these concepts is the fact that most business architecture references make no mention of business models or describe business models as a “side concern”, and most of the business model literature makes no reference to business capabilities.  I attempted to address this gap in the paper where I introduced the Enterprise Business Motivation Model, back in 2008.  While the model has dramatically improved since then, the core motivation remains the same: to integrate these two concepts into a single coherent approach to understanding and modeling a business.

Business architecture cares about the organization of a company.  It also cares about the resources or tools in a company.  Business architecture cares about the processes, and the information.  These elements are all brought together in the understanding of a business capability.  Business architecture also cares about strategy.  However, as Osterwalder notes, connecting strategy to organization or processes without an understanding of the business models is a partial understanding at best.

Let’s be clear about one thing.  Business strategy is related to business models.  In fact I will go further to say that all effective business strategy applies to one model at a time.  Business strategy that applies to more than one model is not strategy.  It is either a goal, a principle, or a vision of some kind.  A strategy, by definition, has to express “how” the goal will be achieved, and that requires the context of a business in which to achieve it.  I know that this may be controversial, but it is CORE to my understanding and the experience I want to share.

So let’s look at the viewpoints of business model proponents and business architects.

So what if these two viewpoints differ?  What’s the downside?

There are a number of problems within large organizations that cannot be solved by business architects without a consistent and careful understanding of business models.  These problems are tenacious and challenging.

  1. Conflicting strategies: Most large organizations have many business models.  Frequently, there are senior leaders who are focused on making one business model successful without any concern for other business models.  Those leaders will create strategies for improving their model, sometimes to the detriment of other leaders and their models.  This leads to political infighting and friction as teams reporting to different leaders are left to “fight it out” when one strategy directly conflicts with another.
  2. Inconsistent understanding among Leaders: It is common for business leaders to be only vaguely aware of the potential for interaction between their model and the models of other leaders.  Therefore, their words and actions will not reflect a consistent and mature understanding of those other models.  This drives serious inconsistencies into their organizations.  This lack of consistent understanding turns into poor assumptions, simplistic rationalizations, and invalid arguments. 
  3. No prioritization produces confusion among shared services: Without understanding what the models are, it is impossible to rationally prioritize the relative importance of those models to the success of the enterprise.  However, it is quite common that multiple leaders leverage shared services within an enterprise (like human resources, legal and IT).  Without the ability to prioritize and create constructive conversations, these “shared functions” are driven to create complex and conflicting services that are expensive to maintain and resistant to change.

I would like to suggest that three of the key value propositions for business and enterprise architecture lies in addressing these specific challenges.  In other words, Business architecture is only effective if it copes with conflicting strategies, inconsistent understanding, and indecisiveness caused by poor prioritization.

Conclusion: Including business models directly into the business architecture practice is critical to quality.  Failure to include them is a recipe for disaster.

Categories Uncategorized

Three Types of Strategy

The word “strategy” means different things to different people, much of which isn’t really strategy at all (see A Strategy by Any Other Name for more on this topic). But within the domain of well-defined strategy there are uniquely different strategy types. Here are three that come to mind. What strategy types do you see? […]