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