Aggregated enterprise architecture wisdom
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 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.
John A. Zachman
I’ve written several job descriptions for Business Architect, Business Performance Manager, Business Strategy Manager, Business Planner, etc for the groups I’ve worked in and noticed that I tend to write the same things over and over again so I built a template to help me in the future. I’ve shared this with a few folks…
It is common to describe Enterprise Architecture as a science. Here are a few examples.
A few years ago, I discussed this question with @RSessions
Roger is one of the few people I know who is seriously committed to empirical investigation of EA. I believe he shares my view that much EA falls woefully short of anything like scientific method. To my eye, many knowledge-claims within the EA world look more like religion or mediaeval scholastic philosophy than empirically verifiable science.
But why does it matter anyway? Why would people be so keen to claim EA as a science? Here is what Foucault had to say to those who wished to claim Marxism (or psychoanalysis) as a science.
“When I see you trying to prove that Marxism is a science, to tell the truth, I do not really see you trying to demonstrate once and for all that Marxism has a rational structure and that its propositions are therefore the products of verification procedures. I see you, first and foremost, doing something different. I see you connecting the Marxist discourse, and I see you assigning to those who speak that discourse the power-effects that the West has, ever since the Middle Ages, ascribed to a science and reserved for those who speak a scientific discourse.” Michel Foucault, Society Must be Defended: Lectures at the Collège de France, 1975-76 (English translation by David Macey, 2003)
In other words, claiming EA as a science is not about the rational basis for its knowledge-claims but about its authority, or what Foucault (in David Macey’s translation) calls Power-Effects. Thus instead of claiming EA as a science, one might follow Gartner in claiming EA as a discipline.
Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture. (Gartner website, retrieved 17 August 2013)
Foucault characterizes a discipline in terms of the selection, normalization, hierarchicalization and centralization of knowledge. We can surely recognize these processes in the formation and maintenance of EA frameworks such as TOGAF and PEAF, as well as various attempts to construct Bodies of Knowledge. Foucault notes that “the progress of reason” necessitates “the disciplinarization of polymorphous and heterogeneous knowledge”. This might lead us to expect some institutional resistance to heterodox ideas, as well as the marginalization of “amateur scholars”.
Foucault is interested in ways that people and organizations can respond to disruptive forces large and small, from “great radical ruptures, massive binary divisions” to “mobile and transitory points of resistance, producing cleavages in a society that shift about, fracturing unities and effecting regroupings”.
Just as the network of power relations ends by forming a dense web that passes through apparatuses and institutions, without being exactly localized in them, so too the swarm of points of resistance traverses social stratifications and individual unities. And it is doubtless the strategic codification of these points of resistance that makes a revolution possible. [Michel Foucault, History of Sexuality Vol 1.]
Gartner’s notion of EA-as-discipline seems quite consistent with this. It is focused on mobilizing the response to disruptive forces (for which Gartner uses the rather strange word “nexus”). EA gains its power from a kind of strategic codification (or discursive practice), allowing the enterprise to “harness the nexus”, thereby “revolutionizing business and society, disrupting old business models and creating new leaders”. (Gartner website, retrieved 17 August 2013)
Update
@tetradian commented on the dangers of spurious ‘authority’ – ‘spurious’ in sense of claiming an aura of ‘authority’ when there’s none to be had (b/c it isn’t ‘science’ anyway)
I agree that claims of scientific status or method in the EA world are generally spurious. But there are other ways of asserting authority. For me, the key question is why (and on what grounds) should anyone trust the pronouncements of EA. It is not just about danger versus safety, but about authority versus authenticity.
So, how many times have we heard this, or had the urge to do this – “Lets document every process, every integration, every data element, every server, every patch, every everything – so we have a clear view of the current state. After all, don’t we nee…
I note Microsoft are reorganizing, again. From a products divisional organization to functional. Evidently they want to copy firms like Apple that have been demonstrably successful at delivering integrated products. The problem for Microsoft is that do…
Establishing technology standards is not hard. Pretty much any first year college graduate can develop a list of products, vendors, and industry solutions that will enable the delivery of our business requirements. Although, a first year graduate stude…
As a follow on to my blog post that reflected on year 1 of EA at Bristol (http://enterprisearchitect.blogs.bristol.ac.uk/2012/04/17/looking-back-on-the-first-year-of-my-ea-role-at-bristol/), here’s a summary of the top three key things I covered in year 2: Raising the profile of EA: a two-hour workshop with the Portfolio Executive (http://www.bris.ac.uk/planning/programmesandprojects/portfolioexecutive/). This senior decision-making group within the University were interested to […]
The importance of Enterprise Architecture principles can not be overstated. With the choice of appropriate principles and consensus within your company, these can lead to amazing benefits.Unfortunately, since these principles do not have complex diagra…
Pay an Invoice
If you need to pay an invoice for someone else, you can that here. Most often, this is used by purchasing departments who need to pay an invoice for one of their employees who is registered in one of our courses.
Note: If you have re…
There was a time when having an application at all; the mere presence of an automated solution was a competitive differentiator for a company. I remember when our on-line banking product was considered novel, not so much for unique features, as for its…
I’ve spent a few years designing and facilitating strategy and planning processes (aka business performance management or BPM) and have gained some insight that I thought might be interesting to folks. This article is a work-in-progress set of best practices I feel are worth sharing. Top Business Performance Management Lessons Learned 1. Be clear on…