Creating a Core Diagram for Agile Business

By |2012-01-31T16:47:00+00:00January 31st, 2012|Enterprise Architecture|

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:

Do you address the complaint, address the root cause, or both?

By |2012-01-13T14:34:29+00:00January 13th, 2012|Enterprise Architecture|

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. 

  • Do you respond like a robot and give him a new product and a coupon for 10% his next order?
  • Does the physician ever arrive to take a look and decide that the company is manufacturing low quality products?  Is anything ever done about the underlying problem?

Enterprise architecture has the same problem in more ways than one.

  • If someone complains that the EA team is not providing value, do you respond like a robot and send your architects to jump onto a visible and important project and “be useful?”  Do you follow up to diagnose the root cause of the perception?  Do you deal with issues in governance, communication, information accuracy, process integration, and expertise?
  • If you notice a complex area of the business is never actually getting cleaned up, and that complexity is causing business agility problems, do you create an initiative to simplify the complexity and then stop there, or do you follow up with a project to address the institutional decision making, roles and responsibilities, and design principles that led to complexity in the first place?

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. 

A Modern Update to The Blind Men and The Elephant

By |2012-01-11T02:38:01+00:00January 11th, 2012|Enterprise Architecture|

My humble apologies to John Godfrey Saxe, whose poem I have modified to add a seventh man, and to make a point…


‘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!”


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

Wikipedia’s EA article, second pass

By |2012-01-04T02:39:50+00:00January 4th, 2012|Enterprise Architecture|

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:

  • EA as a business practice,
  • EA as the desired level of integration and standardization in an enterprise, and
  • EA as a set of artifacts. 


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

Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.[1]

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:

Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers.[2]

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.[3]

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.[4]