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

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

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. 

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

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".


  1. katherine.moss@gordon.edu January 13, 2012 at 8:55 pm - Reply

    Nice metaphor there.  It really gets the point across.  

  2. NickMalik January 17, 2012 at 9:36 am - Reply

    I received a response on twitter that is worth mentioning.  From @oddbjorn: Nice blog post on complaint vs. root cause, but didn't Argyris and Schön deserve at least a footnote? (http://t.co/vvx1p3Ej) 🙂

    Answer: yes. they do.  A good introduction to the theory of Open Loop and Closed Loop Learning can be found on Wikipedia: en.wikipedia.org/…/Chris_Argyris

Leave A Comment

twelve − 8 =