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:
|
Methods:
|
| 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.
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.
Unfortunately, sometimes the EA is the elephant, and we all wonder what it is and why it is there 🙂
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…
http://www.nickols.us/differentpointofview.pdf
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."
Nick,
There is much more, with the same level of excellence!
http://www.nickols.us/articles.html
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.
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.