Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

January, 2012

Posts
  • Inside Architecture

    Creating a Core Diagram for Agile Business

    • 1 Comments

    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.

    WP_000279

    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:

  • Inside Architecture

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

    • 2 Comments

    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. 

  • Inside Architecture

    A Modern Update to The Blind Men and The Elephant

    • 3 Comments

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

    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

  • Inside Architecture

    Wikipedia’s EA article, second pass

    • 2 Comments

    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]

Page 1 of 1 (4 items)