We have seen many companies undertaking digital transformations that involve moves to product-centric operating models. In some cases, these form part of full business transformations, and in others, the focus is on IT transformation.
Why Follow a Product-Centric Operating Model?
Organisations pursue these models for a variety of reasons, including to:
- Improve agility
- Drive innovation
- Enhance customer value focus
- Federate responsibility for Cost Optimisation
- Explicitly allow for targeted risk tolerance
Well-established EA teams have managed to successfully adapt using frameworks such as SAFe (Scaled Agile Framework), but others struggle due to challenges related to their lack of maturity, credibility, or even visibility beyond their direct contacts.
We have seen several cases where leadership have chosen to embed EAs in Product/Platform teams. The EA team is kept intact but is often perceived as just a loose collection of internal technology-focused consultants, typically in support of solution architecture design.
In others, the EA team is retained, but outside of the Product/Platform teams with, on paper, many of the same responsibilities and objectives but little or no clarity on how they are to be achieved.
For these EA teams, this kind of operating model change may seem to be making the path to improvement even more challenging. However, it can also be seen as an opportunity to apply EA practices in a more focused manner and then, if the right tactics are adopted, act as a springboard for broader recognition of the value of EA.
Devising the right tactics is of course much easier said than done. However, by adopting a targeted, iterative, incremental approach, even when starting from a low base, it is possible to meet the immediate objectives of digital transformation while at the same time developing and establishing EA practices.
Who Do We Need to Impress?
Identify and prioritise key stakeholder roles inside and outside of Product/Platform teams that, if brought onside, would help to improve the visibility and credibility of EA. These roles can come from any area of IT or the business, for example:
- Product/Platform Teams: solution architects, product owners, engineers
- IT Support Services: security, procurement, business continuity planning
- Leadership: Business leadership and IT leadership
- Business Support/Management Teams: audit, data privacy office, business strategy
The prioritisation should be based on several factors such as the potential impact of their advocacy, their current understanding and stance on EA, the opportunities for engagement with them in the new operating model.
What Do They Need?
Identify and prioritise the current front of mind issues for each of these roles regardless of any apparent relevance or not to EA, for example:
- Product solution architects
- Which platforms provide the services that I require?
- How do I communicate my proposed solution architecture to my stakeholders?
- Has any other team used the new technology that I am exploring?
- Platform Owners
- How do I optimise the cost of delivering the platform while maintaining quality of service to my platform consumers?
- IT Procurement managers
- What is the level of demand/usage of the technology or service that is up for renewal?
- Do we have cheaper alternatives that are already being used that satisfy the same requirements?
- What is the current business and IT footprint of products provided by a given supplier?
- CIO/COO
- Is the transformation resulting in the expected improvements?
- Data privacy office
- Where are we applying AI technologies and what is the nature of the data feeding these solutions?
How Can we Help Them to Help Us?
In the context of the responsibilities and objectives assigned to EAs in the new operating model, identify approaches to deliver against the expectations of the product/platform teams while supporting activities that address the other stakeholders’ issues.
With the key drivers for transformation typically being agility and innovation, it is vitally important to ensure that the approaches taken are seen as a help and not a hindrance to the product/platform teams. Therefore, wherever possible, any opportunities for self-service and automation should be taken.
A few examples of activities that can yield broader outcomes include:
- Helping product solution architects to efficiently communicate their designs to both engineers and product owners
- Development of application and technology catalogues for Product/Platform Owners to see portfolio optimisation improvements
- Facilitate knowledge sharing across teams, e.g. design patterns
- Helping product owners to design, capture and communicate product roadmaps
- Expose overlaps across teams that have the potential to increase landscape complexity or increase costs
- Support the evaluation of new technologies that support innovation
- Share positive and negative experiences of new technologies across teams
- Monitor the scope and level of technical risk that exists across the business and IT landscape. Are we taking risks in the right areas?
Review, Rinse and Repeat
Finally, prioritise these approaches with a view to introducing them incrementally over time. It is important to continually iterate over these steps and monitor the efficacy of your activities to ensure that they are delivering the required value across the expected stakeholders making adjustments at the earliest opportunity.