Enterprise Architects are more than “problem solvers”

One of the most common mistakes that people make about Enterprise Architects is the notion that we are problem solvers.  Yes, EA solves problems, but to frame EA in those terms is like saying that an ER Doctor is a bandage changer. 

To help clarify the distinction between a “problem solver” and an Enterprise Architect, I will illustrate the logical argument for both, and show their differences.

Problem Solver	Enterprise Architect
Task: understand the problems and solve them	Task: understand the opportunities for the enterprise to be better aligned to its vision and focus attention on them.
Methods: Find people who know what the problems are, and ask them. Look for root causes to those specific problems, narrowing focus to the ones that contribute to a desirable outcome. Describe solutions to those problems	Methods: Collect and analyze information to understand the organization. Design the organization to meet the desired level and type of value delivery. Design ways to change the organization and ask why they didn’t already change on their own. Look for root causes and underlying challenges. Focus attention on the obstacles that prevent normal mechanisms from addressing the problem.
Results: well understood problems that are commonly ignored get  solved (without addressing “why they were ignored”).	Results: opportunities that no one wants to see or problems that people are afraid to solve are discussed and addressed.

 

The left column is what business analysis is for.  It is what solution architecture is for.  It is NOT what Enterprise Architecture is for.  I don’t care how good you are at doing the stuff on the left.  I don’t care how well it has worked for you in the past while working as an EA.  The “raison d'être” of EA is not to solve well-understood problems.  It exists to find out why the organization hasn’t seen the obstacles that actually prevent success, hasn’t removed them,  and hasn’t figured out how to cope with them.

Five blind men describe an elephant, each in different ways.  The EA is the sixth blind man.  He listens to the other five and says “the problem is not that an elephant is like a fan or a rope or a wall… the problem is that it is standing in the living room, and dropping large amounts of waste on the floor.  Problem solvers try to find a better way to feed the elephant and remove it’s waste.  Enterprise Architects asks why everyone is standing in the same room as an elephant.

Comments

• Anonymous
  September 04, 2013
  The elephant analogy scared as I read through it... but at the end - it totally makes sense.  Business loves problem solvers but they learn to adore EAs.

• Anonymous
  September 05, 2013
  Unfortunately, sometimes the EA is the elephant, and we all wonder what it is and why it is there :-)

• Anonymous
  October 06, 2013
  Nick, I'm a simple Business Analyst, but even I ascribe to a more expansive view of problem-solving than what you presented on the left... www.nickols.us/differentpointofview.pdf

• Anonymous
  October 06, 2013
  Hello Duane, What an excellent paper.  I like it.  But if you follow that author, you are more than a simple business analyst.  You are between the left and right columns.  If you authored that paper, I would certainly say that you are far more thoughtful about the meta-process of solving problems than a "simple business analyst" would typically be. I especially like the statement, from the paper, that follows: "My answer is that others define a problem in terms of a discrepancy between two states. I am inclined to think that what makes a problem a problem is not knowing what to do about that discrepancy. In short, it is uncertainty regarding action that makes a problem a problem."

• Anonymous
  October 06, 2013
  Nick, There is much more, with the same level of excellence! www.nickols.us/articles.html

• Anonymous
  October 06, 2013
  Re. being between the left and right columns Actually as a BA, I associate myself squarely with the right, just not at the enterprise level. As you know, business analysts are project oriented. That said, understanding context (or what Russ Ackoff would refer to as the "containing whole") is essential for successful business analysis. The BA need not necessarily understand the entire whole of the organization (as does an EA), but just that particular 'whole' (including technical, business, organizational systems) that is impacted by the project, So in my view, the right column illustrates much of what a senior business analyst is meant to address.

• Anonymous
  October 07, 2013
  Hi Duane, I respect your viewpoint.  Note, however, that the column on the right does not have a project container to work in.  There is no "problem" to solve or opportunity or "solution" to engineer.  There is a business.  Can it improve?  If so, how?   There are a small number of business analysts who work outside the rubric of a project who are involved in that space, and those folks are definitely NOT playing the role of a business analyst... they are using their BA skills to play an entirely different role. I do not believe that the role of business analyst is defined by taking a collection of skills and applying it anywhere.  I know that I differ from some others in that aspect, but no other profession or practice is defined that way, so it is not reasonable to define business analysts that way either.  Roles are defined by their purpose. Besides, the point of the article was not to put down analysts.  It was to differentiate enterprise architects away from the notion of being problem solvers.