Enterprise Architects are Salesmen
A few years ago I took an “architectural study” sabbatical. During this sabbatical, on top of reading, I also attended courses, conferences and workshops in the field. One of such conferences was, “The Enterprise Architecture Conference” organised by IRM UK. Everyone and their dog were there—by that I mean speakers like John Zachman, among other celebrities in the field. Could you believe that this was the most disappointing, and depressing event I have ever attended in my life?
I’m writing from memory, but either the title, the content (or at least the preamble) of nearly every session was something along the lines of:
- How to prove the value of enterprise architecture
- Why no one understands what enterprise architects do
- What should be the definition of enterprise architecture
Imagine that you were a cardiologist who attended a conference about cardiology:
- How to prove the value of cardiology
- Why no one understands what cardiologists do
- What should be the definition of cardiology
If such were the state of affairs in cardiology, you would quit and move into any other, more mature discipline, in which their members at least know what their goal is—and most importantly, others alien to the field. Needless to say, you would never let your GP refer you to a cardiologist if you knew these are the calibre of conferences they attend.
Let’s be honest. No one knows what EAs do; we are the worst at articulating whatever value we supposedly bring. We spend years arguing what a proper EA should and should not do. People publish Venn diagrams on Linked-In every now and then to draw the boundaries of the profession but it doesn’t help. By and large, we are jack of all trades, we get our fingers into way too many pies, and we do a lot of low-level IT stuff we are not supposed to do.
The thing that is certain, in my view, is that EAs are not senior engineers. I don’t believe that any kind of architect is a senior engineer (as far as the role is concerned), although he or she might be one in reality, in a given discipline . The reason is that engineering is about applying science. And science is rigorous, methodical, and detailed. You don’t get to a point where you “got the t-shirt”, and that engineering becomes “below your station”. You can only do harder science. At CERN, it takes hundreds of scientists to set up and run an experiment, but it is always science. Not so with enterprise architecture.
If you call yourself an EA, what law can you name right now from the top of your head, which is universally, unequivocally true, that you apply to the formulation of architectures. I’m not talking about something from social sciences like Conway’s Law, or the likes of design patterns that apply to very narrow and specific programming paradigms. There’s nothing in TOGAF or Zachman that is science. Nothing in ITIL is science either. If you go down one step into more of the IT solution space, and in the likes of CQRS, event-driven design, etc, maybe, if you are lucky, you would come across the likes of the CAP theorem. This is just a hint of what science feels like. In real science, everything is built upon previous theorems (like the CAP one), unless you want to win a Nobel Prize by finding a contradiction in existing ones.
Fine, we are not scientists, and we are not engineers either (because that requires applying proper science). What are we then? Jacks of all trades, master of none? Absolutely, but the closest tangible role I can think of is that of a salesman.
“Get lost Ernie, you may call yourself that but I ain’t no salesman”
Why is it that it is impossible to say the word “salesman” without mentally prefixing it with “snake oil”? Exactly. We’ve been conditioned to think that sales people are there to fool you into buying something that you don’t need and that, most certainly, you don’t want. The other myth is that sales people don’t do anything constructive; they take money for something they haven’t made themselves.
But you see, top salesmen actually excel at the opposite of what the myth suggests. Star level salesmen are particularly good at providing exactly what people need and want, not only in terms of the final good or service, but also in the way that said good or service is acquired and delivered. The amount of their commission or whether they drive a Porsche is beside the point.
This is also our goal in enterprise architecture: to provide to our customers exactly what they need and want, and to make the buying experience and delivery process equally important. This seems like a tautology, but let me put the emphasis on need and want.
Need and want are not two similar words to reinforce one another. We can’t deliver upon an objective necessity that is not wanted and neither should we deliver against a want that is not needed. A great share of our efforts goes into balancing needs and wants. Our capability diagrams, AS-IS vs TO-BE comparisons, and so on, they all have the same objective: to ensure that needs and wants are perfectly aligned. This is exactly what a good salesman does. Getting this equation wrong means failing to meet expectations and, thus, no repeat business in the future. We can’t afford that.