Today, I gave my talk at the Open Group conference that presents a step-by-step method for creating a core diagram that is useful for agile business. I will blog a series of posts on the topic to share this information to my friends and colleagues on the web.
I will create the following posts. As I do, I will come back and edit this post to provide a link. This post will stand as an introduction and table of contents to the topic.
I will post the following articles:
This will likely take a few days, and I’d like to take a few minutes to describe each of these topics. The talk lasted 45 minutes (at a wildly accelerated pace). I plan to provide a better, albeit slower, set of information for the folks who read this blog.
Nick Malik speaking at the Open Group conference, Jan 31, 2012, San Francisco
If you’d like to see the original presentation, see the following slideshare presentation:
Imagine a future where robots run the hospitals as a way to cut health care costs. A robot ambulance pulls up to the door of the Emergency Room with an unconscious patient. The robot triage nurse connects electrodes to the patient and notices a low heart rate, low blood pressure, and intense pain readings emanating from the abdomen. The diagnosis: blood loss and pain. Prescription: provide blood and pain killers.
Then, in comes a human physician who notices that the patient has a gunshot wound. A surgery team swoops in and removes the bullet and patches the patient up.
OK… time to switch metaphors. Your business is going along, operating normally. A customer comes in the door with a complaint. The product he purchased is broken within a few minutes of getting it.
Enterprise architecture has the same problem in more ways than one.
A word of advice: when a problem erupts: triage is important, but surgery may be necessary. Don’t solve the underlying problem without dealing with the symptoms. Don’t deal with the symptoms without also addressing the underlying problem.
‘twas seven men of Indostan To learning much inclined, Who went to see the Elephant (Though all of them were blind), That each by observation Might satisfy his mind.
The First approach'd the Elephant, And happening to fall Against his broad and sturdy side, At once began to bawl: "God bless me! but the Elephant Is very like a wall!"
The Second, feeling of the tusk, Cried, -"Ho! what have we here So very round and smooth and sharp? To me 'tis mighty clear This wonder of an Elephant Is very like a spear!"
The Third approached the animal, And happening to take The squirming trunk within his hands, Thus boldly up and spake: "I see," quoth he, "the Elephant Is very like a snake!"
The Fourth reached out his eager hand, And felt about the knee. "What most this wondrous beast is like Is mighty plain," quoth he, "'Tis clear enough the Elephant Is very like a tree!"
The Fifth, who chanced to touch the ear, Said: "E'en the blindest man Can tell what this resembles most; Deny the fact who can, This marvel of an Elephant Is very like a fan!"
The Sixth no sooner had begun About the beast to grope, Then, seizing on the swinging tail That fell within his scope, "I see," quoth he, "the Elephant Is very like a rope!"
And so these men of Indostan Disputed loud and long, Each in his own opinion Exceeding stiff and strong, Though each was partly in the right, And all were in the wrong!
Silent was the Seventh man Who heard the heated fray Not touching the amazing beast Upon that fateful day Chose wisely to collect his clues From what each had to say
Concluding from the evidence That no man clearly knew The seventh man did not attempt To posit what was true Instead he sought to ascertain what the beast could do Tried and failed, and tried again This man did ply his art Invented he, a harness great And cried out from his heart “I cannot see the shape of it but it sure can pull a cart!” MORAL
So oft in theologic wars, The disputants, I ween, Rail on in utter ignorance Of what each other mean, And prate about an Elephant Not one of them has seen!
The wise, instead, do not delay to overcome their lack of vision They absorbs, from fellow men, their thoughts and intuition And then they act to journey forth accomplishing their mission
After a rather protracted discussion on LinkedIn about the Wikipedia article on Enterprise Architecture (blogged here), I took another swing at rewriting the EA article’s opening section. It is far from perfect, but I encourage the folks who have been following this discussion to take a look.
The change I made was fairly straight-forward:
- Removed unverifiable definition of EA
- Added three verifiable definitions from three perspectives:
- followed each definition with a layman’s interpretation of that definition.
Normally, I would argue against actually citing a definition in a Wikipedia article. After all, it is an encyclopedia, not a dictionary. That said, after long and protracted debates about the meaning of the word ‘enterprise’ and the meaning of the word ‘architecture’ and the derivation of the term ‘enterprise architecture,’ I decided to break the rules a little and actually quote from the definitions themselves in the Wikipedia article. This is really unusual, and I expect that I may get pilloried for it, but after all the arguments, I didn’t want anyone to tell me that I had interpreted their definitions “incorrectly” by quoting original sources.
The new opening text of the Wikipedia article on EA is:
The term enterprise architecture is used in many complimentary ways. It is used to describe both a unique business practice and the aspects of a business that are being described. The Enterprise Architecture Research Forum defines the practice of enterprise architecture as follows:
In simple terms, Enterprise Architecture is a self-improvement business function that examines the structure and behavior of the various parts of an 'enterprise' and focuses on opportunities to improve it.
The MIT Center for Information Systems Research (CISR) defines enterprise architecture as the specific aspects of a business that are under examination:
Simply put, the enterprise architecture in an intentional vision that defines how business processes should be integrated and where process standardization should be used.
The United States Government describes enterprise architecture as an Information Technology function. Instead of describing enterprise architecture in relation to the practice of examining an enterprise, the U.S. Government defines the term to refer to the documented results of that examination. Specifically, US Code Title 44, Chapter 36, defines enterprise architecture as a 'strategic information base' that defines the mission of an agency and describes the technology and information needed to perform that mission, along with descriptions of how the architecture of the organization should be changed in order to respond to changes in the mission.
Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing the complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.