The concept of the Architecture Owner role – to ensure consistency across an organisation’s IT projects – has been around for a while, but Dootrix’s head of DevOps, Mark Vallins, thinks we’re reaching a tipping point. The key question around AOs has already shifted from ‘What’s that?’ to ‘Should we appoint one?’ – and is increasingly becoming ‘Why haven’t we got one already?’
Architectural Owner: core responsibilities
When an organisation has multiple teams working on software projects, and especially when some or all of those teams are external, the Architectural Owner role becomes pivotal. Part of the Disciplined Agile Delivery (DAD) process, its core responsibility is to ensure good architectural, or design, governance, evolution, compliance, mentoring and support for suppliers delivering solutions into a client’s IT estate; in the case of Dootrix clients, their Azure estate.
However the role can, and arguably should, go beyond that and while it’s primarily about bringing governance to a project, it also involves collaborating very closely with a supplier and the technical team to support their efforts.
Architectural Owner: the interface between client and suppliers
The AO role, done right, is an invaluable link between supplier and client. Sometimes there's simply a lack of a shared language or a shared understanding between the two parties, especially from a technical perspective. For instance, a product owner may have a good overview of the business imperatives on the customer side, but they don't necessarily bring technical understanding or knowledge of how their existing systems work. They may not even have the necessary level of access to their own technical resources, because their own dev teams are working flat out on internal products.
For its part, the supplier may, or may not, have experience of the client’s ways of working, or a good understanding of the range of technology within the business, the client’s wider goals or who to approach when client input is needed.
AOs also often provide additional backup to the supplier’s technical team. It's as much about being on hand to answer questions as it is to question the design. When I performed the AO role for Dootrix’s client Heathrow, I found myself spending a lot of time working with both technical leads and suppliers, discussing designs right from day one and being a sounding board and mentor, helping to onboard that team with the client’s way of working.
How supplier experience informs Architectural Ownership delivery
And at Dootrix we’re well placed to do this because we’re also a supplier; we have worked on projects for dozens of clients, across a wide variety of sectors. So I’d like to think we understand how that feels from the inside. Our AOs have hands-on experience of both delivering and ensuring the delivery of solutions, bringing knowledge and shared experience from across Dootrix. Unlike internal appointments, they bring not only their own expertise, but also the support and knowledge of the rest of the Dootrix team.
When we put a team with a customer, it typically consists of technical leadership, developers, delivery and management. And we provide internal support for that team and its technical leadership and give them the ability to talk internally about issues they have.
That very much informs our approach to taking on architectural ownership roles; you also become that support for the supplier team and help guide its technical direction.
Soft landing tech projects
Our goal, whether we are on the receiving end of the AO role or delivering it, is to soft land a project. What suppliers don't want is to be in the position of having merrily gone through the design and construction phases and then crash land the project into some design authority board that rejects your work – and it’s not a good outcome for the client, either.
What you need as a supplier is help and advice right from the start to make sure you're going in the right direction so that you're not running into any issues with the way the client organisation works, and that there are no surprises when you come to delivery. The AO role – by ensuring an agile approach to design and implementation – helps avoid such crash landings by providing a consumable solution which is usable, desirable and functional that meets the needs of all stakeholders. It helps to address direction and governance issues early and what is and what isn't allowed, so that you don't start running into those problems unintentionally.
Bridging gaps and overcoming technical roadblocks
As a supplier, you may have experienced working quite happily with one contact in an organisation and then you run into a wall, perhaps some sort of technical roadblock, that you just weren't aware of. You might have asked questions, but maybe there wasn't someone for those questions to land on. A good Architectural Owner is there to help bridge these gaps. Along with governance, the AO is ideally somebody who's there to ensure everybody wins, who speaks the language of both sides, who understands what it's like to be a supplier, but also someone who has a long enough history with the client that they really understand the client’s IT estate and ways of working.
As an AO, you’re embedded with the client and have a key governance role, meaning you’re generally in a position to know who to call or email to get permissions or answers from within the client organisation – a facility that a supplier who may be working on a project for three, six or 12 months, may not have. And every time a new supplier is engaged, the process starts from scratch again.
I’d argue that the value of appointing someone to the role of AO is quite clear. However there’s a big question mark over whether the AO is better as an in-house appointee, or someone brought in from outside. I’ll address that issue in my next post.
Need consistency across your organisation’s IT projects? Get in touch
