Business Architects: Do Not Start With Strategy

Frequently, when reading articles or books on business architecture, the following advice emerges:

Business architects start with the strategy of an organization.  They take that strategy and map it to the capabilities of the enterprise to clarif…

Categories Uncategorized

Fragility of Markets and Architecture Failure

As the NASDAQ exchange came to a grinding halt this past week, I, as well as many of you perhaps thought about system failure and what was the series of events and initial conditions that preceded the shutdown. Did a human did something strange that set a series of events in motion that jeopardized the…

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