First things first: A TOGAF certification alone, does NOT make anyone an Enterprise Architect. There you have it.
Inspired by a recent article on linkedIn (which seems to have been removed now) I started to think about how we can get back on track bringing clarity into the language around Architecture roles. At the end of the day, a role title should help you communicate what you do and what your circle of concern is. This in turn brings clarity and value to the organisation you work for.
Clear communications is key in all our relationships. With our family, kids and in business. Ambiguity and confusion makes communications and hence relationships more difficult, can cause stress and waste time and money. In IT we see lots of ambiguity and confusion created – either through marketing material or through people who want fancy job titles. I remember meeting my first ‘Enterprise Architect’ at the W-JAX in Munich in the 90’s. I loved his title, he was absolutely an expert, but at coding in Java 2 Enterprise Edition. His session didn’t talk about business strategy, competitive analysis, market forces, business capability roadmaps or sales & operational planning processes. See where I am coming from?
The ambivalence in IT can be mind numbing – SOA, Cloud, API, Architecture roles are just a few to name. Marketing departments wanting to create a ‘me too’ in a specific field even though they don’t have an offering, which then creates confusion. An example is when back in 2006 AWS started to have ‘Cloud Computing’ conversations, simply utility based pay-per-use computing resource consumption. Then VMWare came along wanting to be a ‘me too’ coining the term ‘Private Cloud’ for something that was merely infrastructure virtualisation. And voila: ambiguity created! The result? Today you need to spend 15 minutes if you talk ‘Cloud Computing’ just to establish the context: IaaS, PaaS, SaaS, Private, Public, Hybrid or do you just mean infrastructure virtualisation really – and there are plenty other examples out there.
The author of above article on linkedIn has done a stellar job, up to the point where he introduces the term ‘Enterprise Solution Architect’ which is exactly the reason why the confusion started in the first place.
‘Enterprise’ Architects, meaning architects with the word ‘Enterprise’ in their title are plentiful, TRUE Enterprise Architects are only few. I meet many so called ‘Enterprise’ Architects throughout the year, unfortunately most of them lack
- Involvement in implementing their companies’ strategy
- Involvement in strategy workshops
- Meetings with executives on a regular basis to discuss strategic initiatives
- A business capability or strategic roadmap
- Involvement in business transformation programmes – neither actively or as a steering committee member
- Rarely understand more than 1 or 2 business and technical concepts on a 101 or 201 level (eg S&OP, Order to Cash, accounting, infrastructure, integration, information modelling, business process modelling or applications) to present the necessary architectural options and ramifications for the business.
Architects who lack above characteristics simple DO NOT make an Enterprise Architect, they are perhaps Technical Architects working in an ‘Enterprise’ instead. Technical Architects look after applications, data stores or infrastructure for example.
Developing into an Enterprise Architect requires multiple years of learning all different aspects of the business and the industry. I don’t see any other way a seasoned EA getting her job without being prepared to be the dumbest person in the room – in many meetings, over many month or even years. The resilience, ability and willingness to learn and doing so is paramount – cost centres, deferred COGS, SOX compliance, consignment notes, recovery, pick release, ship confirm, POD, service route optimisation, freight cost, sales and operational planning – there’s lot to learn.
Here is an attempt to categorise Architecture roles graphically:
In summary, the important points in my view are:
- Solution Architects are allrounders and the vital and necessary glue to deliver successful business outcomes
- Solution Architects overlap with all other architecture roles. The reason is clear: In order to solution the right business outcomes you need to understand the Enterprise Context, strategic roadmaps, industry and technology well enough to have a meaningful conversation with both the business and the technologists in your organisation with the aim to ensure successful delivery
- There can be other Architecture roles focussed on Information, Security, Data or specific Domains
- There is no need to confuse things with the word ‘Enterprise’ such as ‘Enterprise Solutions Architect’. All solutions, projects or capabilities life automatically within the Enterprise Context
- Organisations are different, which means above categorisation is not set in stone but a guide. The scope of each architecture role can be more or less focussed on aspects such as projects, technology, business, strategy etc. There can be many reasons for this, number of architects or the lifecycle stage of an organisation (see STARS Framework ) for example.
Using above categorisation instead of business card titles helps me better understand where architects are sitting within the Enterprise context, their circle of influence / circle of concerns, what topics to prepare for, how to best communicate and the areas I can learn from my interlocutor (I had to Google that word first :)).
Keen to get your view.