One common argument I’ve heard in the Enterprise Architecture community goes like this: “If you do not have the authority to fix the architecture of an enterprise, you are not an enterprise architect.”
On the surface, this is a silly argument. A simple metaphor illustrates the notion: “If you do not have the authority (ability) to heal yourself, you are not a doctor.” The obvious thing to point out is that doctors don’t heal you. They provide medicine and therapy to allow your body to heal itself.
I think the confusion comes from the term “architect” as though it means “the guy who builds.” But that is wrong for two good reasons. First, an architect doesn’t build a building, so even within the metaphor, it’s silly. And secondly, the metaphor of building architecture is not a reasonable metaphor of EA. We use the word “architect” differently, and that’s okay. There is nothing wrong with two different fields using the same word in different ways. A project manager is a very different role than a general manager.
Looking forward – how to think about an Enterprise Architect
An Enterprise Architect guides and translates strategy in partnership with senior leaders, in much the same way that a physician guides a patient with advice, therapy, and prescriptions. Patients do not have to take a doctor’s advice. Any good doctor knows this. Similarly a senior leader can hear the advice of an enterprise architect and they will filter it. The words of an enterprise architect should always be treated as advice, guidance, and translation, not law and not policy.
As an EA, we rarely get the authority to change things. That does not mean we are without value. The day to day activities and efforts of a senior executive necessarily require a focus on the minutiae of business. The efforts of an EA to help the senior leader to “take an enterprise view” is essential, not because we are smarter or wiser, but because we have developed dedicated skills and practiced them more frequently.
Is the word “architect” a problem, or does it help our case?
Perhaps to help solidify this understanding, we could use the term “enterprise advisor” instead of “enterprise architect.” Unfortunately, that term omits one of the key differentiators for practicing Enterprise Architects: the ability to provide advice anchored in models and drawings.
I am happy with the term Enterprise Architect because it highlights a key facet of my own life. I draw pictures of complex things to highlight one element of that thing that might otherwise be missed. A building architect, but not a doctor, will draw pictures of a building, omitting most of the details, to focus on specific things (like an electrical floorplan). I draw a picture of a system to highlight some aspect of that system while hiding other aspects, to provide clarity.
The word “system” is used broadly here. I’m talking about sociotechnical systems that include more than just people, processes, and technologies. My diagrams also often include motivations, incentives, organizational structures, human relationships, and authority relationships. I draw pictures that include any of these aspects, often more than one at a time, to highlight elements that might otherwise be missed.
Yes, that produces advice. Advice anchored in an approach. Advice anchored in proof.