The IT industry has a magnificent history of appropriating titles and then through the process of demand outstripping supply, diluting the skills and requirements for those roles to a new lowest common denominator based average.
We have seen this across IT specific roles in each of the pre-millennium “revolutions” (think the desktop design revolution of the 80s and the web design phases of the 90s) and you can see it occurring once again today in real-time with the [big] data science and analysis revolution.
IT specific roles aren’t the only ones accumulated in collateral damage bill of the supply-demand friendly fire that is the recruitment battle for talent. Business Analysts were once considered more than junior project management staff who do little more than gather requirements and translate between “the business” and “the technical departments”.
So, it isn’t surprising that the constant debate over what is (and isn’t) an Enterprise Architect is seemingly a never ending storm of opinion that seems to be the perfect storm of those seeking to anchor their experience validation, selective interpretation and bias confirmation.
It’s also not surprising to see senior practitioners and corporations alike starting to distance themselves from title and descriptor to differentiate themselves from the confusion and the noise.
Combining the snippets of conversation I have had over the last year, along with data from research conducted by various bodies, I felt that the definition of EA was still vague — especially when discussing the needs with customers.
Thus, this is the image I now have on my cubicle wall, which is an old-school, unartistic mash-up of ideas that have been shaped by my experiences, the research by ACS as well as many articles and discussions with colleagues and associates alike.
Let me provide the usual disclosure of saying that I am neither trying to capture every nuance, nor claim that this is some form of definitive guide.
It is a simple conceptual model to allow and define the conversation around the engagement to determine which “EA” is being requested by clarifying the mandate of the outcome and thus the capability and competency of the individual (or team) to perform and achieve the results.
What I have not included in the above rendering are numerous, including the changes that design thinking (amongst others) has been bringing to the EA table.
I’m sure there will plenty of voices ready to correct my world view, and am happy to invite you to do so.
For now, this is a useful tool to guide discussions — I expect I may mature it, alter it or discard it over time as I continue the journey