How Recoverable Is Your EA Practice?
About 6 months ago I was having a conversation with an EA about their journey. They had recently moved into a new role and we were discussing their challenges. The main challenge, that I hadn’t quite anticipated was their ability and time to actually do EA work.
This organisation had previously established EA practices, and like many orgs in NZ they had gone through waves of seeing the value of enterprise architecture. They were at the time in an upswing, where the HoA had managed to sell the vision of an enterprise practice.
However, what transpired is that this org hadn’t accounted for any EA time. The architects in the organisation were meant to be 100% recoverable, regardless of if they were contract or perm. This isn’t itself unusual when discussing an SA practice but when it comes to EA it’s generally understood that you need to spend time thinking about the overall organisation rather than just on projects. This caused me to think about this in a broader sense and to ask the question to my HoA connections:
“how recoverable is your EA practice”
Over the last few months, I have spoken to about a dozen architecture leaders and asked the above question. I have got a variety of responses from 90% all the way down to 0%.
For those leaders who have teams closer to the 90% range there is a general understanding that it should be lower. There's a real danger of the EA practice getting too wrapped up in projects, possibly losing sight of the bigger organisational picture that EA is supposed to cover. It really highlights the need to handle recoverability rates.
领英推荐
Interestingly there has also been a concern from those who have the higher rates to drop down too low, the feeling that if your EA team is 0-20% recoverable they might end up becoming an “ivory tower” practice and be perceived as detached and isolated from the practicalities of the organisation. EA practices with extremely low recoverability rates (0-20%) face the risk of falling into this trap.
As with anything in the architecture space there isn’t a silver bullet, it’s about doing what works for your org. The challenge for most is trying to enact change and move from a higher rate to the lower. To me if the EA practice is getting towards 90% recoverable that can be a real indication that the business doesn’t necessarily understand the value of EA. I think that is probably a conversation for a different day.
I’d be interested to hear what others think is the best % for recoverability for architecture practices.
?
?
Aligning IT investments with business growth through future-proof architectures and empowering CIOs/CTOs to Unlock Agility & Innovation Through Strategic Architecture | Enterprise Architect | IT Strategy
11 个月Thanks for the post Ben Joyce If I put my solution architect hat. The requirements for system recovery boil down to the impact on business. Similarly, if business leaders and organization leaders understand the strategic value of EA practices, that is contributing to the resiliency of the organization at a heartbeat. The recoverability of EA practice will be supported based on that. The EA leaders can influence some of the strategic factors by demonstrating the value of a resilient EA practice.
? Roadmaps that everyone can understand ? Fixing organisations whose growth has outstripped their operating model, process and fragmented applications
11 个月This goes back to the question of the value of architecture. If Enterprise Architecture leaders cannot communicate the value of their practice in a way that makes sense to the stakeholders the greater the expectation that they will be on projects and therefore funded by the business, which means that they are a solution architecture practice. It is not a bad thing, just not I assume they set out to do.
Head of Technology Strategy and Architecture
11 个月Another challenge is that the important architecture work for an initiative is often a dependency for there being a defined scope, cost, and business case. And therefore occurs before any formal project is initiated - i.e. before any formal financial recovery mechanism actually exists... My advice is aim to have a low recovery but know that ivory tower syndrome is a curse for any (serious) architecture practice and watch diligently for signs of that irrespective.
Advisor
11 个月Thanks for your post, Ben.?The right level of recoverabiltiy is hard to say and likely situation-dependent, but what I found is that if you don't have any levers to manage that, your architects are either pulled into projects or, if they are not very good, not in project demand and retreat to the ivory tower. It seems to be a law of nature! The approach I used to solve this before was to introduce a "case management" model for architects that works very much like a lawyer does. An issue comes up, a case is opened, the architect works the case, solves the case, and then moves onto the next one.?This avoids the problem of assigning and architect to project where the PM has an expectation they are just like any other resource and, if they are good, will want MORE of that resource. It also helps keep the "ivory" types more centred and available for cases.?This can all be measured as well, which we used to do.?An architect is evaluated on how many cases s/he resolved, the experience they delivered, etc. and the whole practice can measure case throughput, bottlnecks, satisfaction and so on. Your results may vary, but I used this approach at a couple of banks and found that it worked well for me and the team.??
Program Enterprise Architect | Delivering complex transformation and technology programs | Mergers & Acquisitions | Finance & HR Transformation
11 个月Interesting article. My view is that it depends on the level of EA maturity in the organisation. If the EA team is still developing target states, roadmap and EA principles then you would expect a lower recovery rate. Then, it will go higher once those guardrails are defined and the EA team moves into project governance, innovation and business alignment. In this second phase, you want them more involved in delivery to ensure that the EA artefacts are still relevant and being implemented.