Enterprise Architecture = success?
When asking about the success of Enterprise Architecture at organisations, there seems to be two responses, delight and stories of success, or horror and tales of lots of spend with little value. On the Gartner Hype Cycle for Enterprise Architecture, EA has left the trough of disillusionment and is moving up the slope of enlightenment, which suggests the discipline is maturing from the early 2000s when everyone seemed to be an architect and a lot of people were ‘giving it a go’ – imagine if the pilot of a plane was ‘giving it a go’. However, Bain published an excellent paper on this in July that found that just ‘10% of companies are satisfied with their company’s enterprise architecture capabilities’ which tells us that a lot of organisations are still struggling with implementing EA effectively.
So what is causing this?
Bain suggest that this is partly down to the role of EAs in the organisation and say that successful EA teams have a distributed model – a small, centralised team focused on strategy, supported by architects out with the delivery teams. This model is definitely a model we advocate, but it does need a level of maturity within the EA team to work – if EA has no credibility then the delivery teams won’t be interested – and having it mandated by the CIO/CXO can just make it worse as teams feel imposed upon. If you have well respected EAs and good engagement with the delivery teams then you are OK. If not, then one way to achieve this is to offer to work with the delivery managers to identify existing team members who can play the EA role and educate them in how to approach architecture, basically acting as EA mentors. Our boss has a concept, ‘Everyone’s an Architect’, which means everyone in the organisation should/can act as an architect, if they have the right information and know what they should be looking out for, and mentoring is one way of doing that.
There still seems to be a desire to stick religiously to frameworks; less so than in previous years, but it’s still quite prevalent. The best architects we see use elements of frameworks that are useful to help them when doing their job, and ignore the rest. They aren’t constrained by them, they are guided by the end point, the business outcome and business value they can deliver. They don’t deliver artifacts because some framework says they should do, they deliver them to convey a message to someone that makes the end point easier to achieve. This is key to enterprise architecture success, give people things they can make use of.
Addressing the problem
An inability of enterprise architecture teams to deliver is still a common problem, if 10% of companies are satisfied with the EA capabilities, then 90% aren’t – so they aren’t getting something they want or expect. There’s a good chance a lot of those respondents were never asked by the EA team what success would look like for them – as part of our success pathway we often ask EA what success looks like to them, and then for their boss, quite often they guess what the boss wants because they have never asked. Just ask – it makes things much easier as it gives you focus and a well-defined scope.
The Bain report also found that competing goals for priority was often a barrier to adoption of modern EA, which is something we often see. This is where the EAs are constantly being pulled in different directions, ‘We’ve been dragged onto the Salesforce Project plus they want us to help with an Identity Management Project. The problem is the EAs get spread so thinly that, although they may be delivering value to the projects, little visible progress in the enterprise architecture is made. One common theme we see here is the EAs desire to be the focal point for decisions, to ensure alignment to the EA, however, with limited resources this can be difficult and, when they are overwhelmed by requests, they can end up satisfying nobody as they become either a bottleneck, or begin to miss decisions. The EA teams that handle this better, in our experience, are willing to say no, or push the decision back to the boss, ‘Here are the things you want, we can’t do them all so something has to stop. So, which ones do you want us to focus on?’ and let them decide.
Additionally, when spread thin, the danger is you begin to ignore the strategic EA work, primarily because you are down in the weeds of delivery. The issue is the strategic EA then becomes dated and people begin to question its value. At this point, the EA team have a problem – people begin to push for the EAs to become pure delivery resources as the strategic EA isn’t of any use. To mitigate this, the EAs need to balance some strategic EA with Delivery EA – in the recommended Bain model, you split the resources, however, if you don’t have a split model then you need to make time to do strategic EA. In this latter case, the key thing is to strip back the strategic EA to purely what will add value. Speak to teams about what would help and align that with your key stakeholder needs and define what your strategic EA will manage – don’t be overly ambitious and keep it small initially. Over time you will likely see people engage and, as your credibility increases, you can look to expand the strategic EA scope, and at this point you are on the journey to building an enterprise architecture success story.
You can find the reports referenced in this article below:
Gartner: Hype Cycle for Enterprise Architecture, 2023, 1st June 2023, Saul Brand, Marcus Blosch, https://www.gartner.com/interactive/hc/4400299. ($)
https://www.bain.com/insights/a-modern-enterprise-architecture-is-essential-for-scaling-agile/
See also:
Empowering Enterprise Architects: Trusted Advisors, Not Rule Enforcers
Empowering the Enterprise Architecture Function
Does successful Enterprise Architecture need Business Engagement?