During a recent workshop we ran in London, we were able to capture some insights and thoughts from a packed room of existing HOPEX users, potential HOPEX users, partners, and other interested parties who all got together in the cool surroundings of Sea Containers House (highly recommended) to figure out some ways of driving more value from EA.
After we'd looked at some pretty cool retro movie memorabilia, we discussed how the market perceives EA, and how it can mean all kinds of different things depending on the internal stakeholder in question.
Although the definition can vary, we all agreed that delivering consistent business outcomes and value is vital to support change and transformation programmes across the organisation.
In this first in a series of articles discussing the findings of the session, we explore how to set EA up for success – with a focus of avoiding (or smashing through) the glass ceiling of Application Portfolio Management (APM), and the branding of EA.
Encircling - and advancing - the application portfolio
A common theme we are noticing with our customers and prospects in recent times is the recognition that EA needs to be much more about APM.
While there are point solutions out there that offer that, going above and beyond into data (the new oil), governance, risk, compliance, and process optimisation requires an altogether more holistic approach. As one of the delegates said, “sometimes getting to your target architecture can be like trying to cross a river without being able to see the stepping stones”.
The way that EA practices are setup and even branded internally can play a big role in their success or failure.
Driving successful EA programmes
To set up an effective EA function or team, the group felt it is important to position your function/team carefully. One option could be to consider naming it “Strategy and Architecture” or the like, rather than EA in order to achieve more resonance across the business.
Identifying key sponsors/stakeholders and defining a particular value proposition for each is also important. To do this, identify business functions you must interact with (business planning, business change, IT governance etc).
Establish your architect capability into different specialities also helps focus resources in the most effective ways. For example, EAs who may specialise in one or more of the Best Demonstrated Available Technology (BDAT) domains, and Solution Architects who may specialise in one or more business segments or functional areas.
Are you setup to be proactive or reactive?
Being positioned as leaders and trusted advisors is easy to say – not so easy to achieve in reality. Establishing an effective engagement process enables you to hear of business/IT changes wanted or planned, and be ahead of the game. Building rapport and trust with key stakeholders across the organisation is vital to achieve this.
From this position, EA can define how architects will be assigned to and/or govern change programmes/projects.
EA should be to keep on top of the major changes, goals and objectives wanted by the business, in addition to identifying regulations to which business data and processes must comply.
Establish your operating models
From this position of knowledge, clarify your operating models (capability map + values streams) at a high level, define current/baseline operating models, and define future/target operating models.
You can then direct your EAs to scope the baseline enterprise architecture, including cataloging business apps (e.g. business fitness, technical fitness, and cost of each (H/M/L), kernel data entities (e.g. customer, product, asset, employee) stored, business services/products (and perhaps roles and processes) supported and enabled, and platform technologies that support and enable business applications.
Drivers of change
Initiate change projects is where EA can add true value. To do this, identify pains (including “technical debt”) and opportunities that justify application change, and present your findings to stakeholders with options for application change (giving consideration to business, data and platform changes).
From this basis, agree and document “Requests for Architecture Work” with sponsors, and record stories of success due to architect engagement, and issues due to lack of architect engagement.
Conclusions and key take aways
The group concluded that there is a real need for careful internal marketing of the EA with a tight focus on ensuring the terminology and alignment to real end-benefactor needs.
APM is a great start, but has limited longevity and even APM as a topic in itself can be misunderstood if not carefully marketed.
James Bond will return....
In the next article in this series, we’ll zoom in on the group’s discussion about establishing your EA function, and where to get started with that.
And in case you're wondering, the event finished up in the rooftop bar. Life's not so bad! 🥂🍻
