What other profession gets carried away with a term and a role?
It’s been a great Easter here in the UK, the sun has been out, the gardens have been bought back to life .. and I’ve been spending far too much time scrolling through LinkedIn while sitting in the sunshine.
I’ve seen numerous posts on the EA profession. Some drive an inward, self proclaiming sense of importance and many look to pull holes in the definition and the history of the role.
I’ve commented on a few of the posts and as a result have had a few private messages from others who have seen similiar posts over the years and are too, or have been frustrated by the way the EA profession and those who work in it go into battle.
Rather than arguing about what EA stands for and why, (based mostly on technical capabilities) we should be taken more seriously by other IT professionals and the business – can we start focusing on the “what we do that matters” and “how we go about what we do”
When reviewing Enterprise Architects contribution and the difference the role can make then for me you may want to look for 5 key things.
- To get results an EA has had to have served/worked across the different domains of the business, infrastructure, data and the application aspects of the role and learnt how these areas have to come together to drive good delivery outcomes.
With this experience they are able to explain how any portfolio of chosen tools, database, business processes and set of skills will make the difference in solving a business problem in a sustainable way.
Having worked within programmes or technically supported a live service they have witnessed and heard about the business process/skills, data challenges, application nuances and infrastructure considerations and are able to have these as references to help shape the design and assess the risks of the next iteration of the business and the chosen solutions.
- Having worked for many years across multiple projects and programmes they have formed strong working relationships with domain experts – recognising that as an Enterprise Architect they will never be at the bleeding edge of the domain knowledge – the business, data and tech worlds move on so fast recognising that there are expert domain architects in these areas that can provide the “up to date” detail to enable the shaping and risk assessment of the solution is key.
The domain experts that an EA rely on can be
- those that have been part of the permanent team who know the inside outs of the established estate and may have a better handle on the politics of the business;
- they can be contractor architects who often bring knowledge of other industries and other projects;
- and for many as the world progresses into IT as a service they can be architects from the vendor side who can provide the depths of detail about the technical solution relying on the client side architects to configure the services for the specific business problem.
Working with the knowledge from all the domain architects and across all the different “tenure” enables the Enterprise Architect to consider the “delivery roadmap” recognising what will need to be terminated, tolerated or invested in to get the business results.
- In the 90s and early 2020s point 1-2 above would have ticked 90% of the boxes.
As we progress into the 2020s operating models are not all in-house, tech is not all on premise and data is not all owned and managed by the business.
So points 1-2 are now more 60-70% but this next point is certainly becoming a larger percentage of the role.
An Enterprise Architect has to be able to navigate the in-house, people based, on premise operating model (one that is often in run off) alongside the outsourced, cloud based, API, digital AI/ML operating models (one that is often in ramp up).
They need to be able to pull together EA roadmaps and look to adopt some form of PMOesk tracking criteria to be able to demonstrate progress of the ramp down and ramp up looking to course correct or pivot as new services are released into the market.
This takes structure and programme management and the ability to keep track of risks and issues.
- Maybe inherently in the points above, you are picking up on how the EA has to stay ahead of the game and be constantly able to be up to date with research – pulling on advisory bodies – and industry knowledge to be able to ask the “art of the possible” questions.
They need to be working as a team with others across the business to look at the feasibility and viability of the proposed architectural changes knowing that making too small a step forward could lead to a small but minor impact while making a too big step forward could be taking too many risks in unproven and untested services.
- And finally and most importantly I’m becoming increaingly aware of how the EA needs to be able to embrace what it will take to improve customer and employee experiences – and with that as a mindset being more human centred and appreciating that there maybe key pain points that will drive more value if the more emotive questions are asked about how you want people to think, act and feel when making use of the digital services can unearth some additional needs for the EA to consider in the work that they do and the roadmaps that they oversee.
Now some comments on LinkedIn have pointed to having to be super human or superman (woman) to be able to take on the role of an EA. And maybe the 5 points above suggest that but I’m not so sure …
What you do have to be is a great listener, able to question and gain respect and be able to test theories and ideas with others – you must not work alone but with others and you must spend time with those that are as close to the customer as to the technical coal face.
Having an architecture function in your business that is made up of business, tech and data domain architects that work with EAs on shaping roadmaps for different business units of your business that pull on these domains and business capabilities that they design will lead to a more sustainable operating model.
Let’s not keep arguing about the role of EA – there is enough for us all to occupy our minds with in solving business problems without being so focused on the what’s and wherefore’S of our profession…
This blog originally appeared at https://whatevernext.home.blog/
Lisa Woodall is the Chief Enterprise Architect leading the Business Design Team at Ordnance Survey.
