Instead of acting as strict enforcers of architectural rules, good Enterprise Architects should act as trusted advisors to the wider organisation.
The modern Enterprise Architect’s role has changed over time. Early EAs were often considered enforcers of architectural rules and standards, but now the more progressive architects are more likely to be trusted advisors who help teams succeed by consulting, and providing guidelines and tools for the job, rather than enforcing rules.
How to succeed as an Enterprise Architect
Our experience of successful organisations tells us that the more successful Enterprise Architect is one who advises and facilitates, rather than being a strict enforcer of architecture rules.
By becoming a trusted advisor to change teams, it is much easier for the Enterprise Architect to increase their authority and influence over the direction of IT in the organisation.
Rather than dictating what can and cannot be done within an architecture, an EA should provide guidelines for teams so that they can make their own decisions, often with EA input, but within a framework set by the EA. For instance, we want to allow change teams (we’re including project team under the change team banner) to focus on their own priorities while still maintaining consistent standards that align to the wider organisational needs.
Failure in bureaucracy
Stories of failed EA initiatives often include EA teams that tried to implement bureaucratic, box-ticking based EA capabilities that they expected the organisation to engage in, and it’s clear that EA teams who take this approach will not last too long.
Successful EA teams typically take a much more collaborative approach, understanding the needs and concerns of the teams they need to engage. They communicate with the wider organisation to understand the key pain points, they ask what ‘would make your job easier’ and they work with the people with whom mutual success is achievable. Importantly, there is give and take here, ‘if I can provide you with this to do your job better, then you can provide me with that to help the EA initiative’.
A more collaborative approach in action
The key trick is to not dictate what can and cannot be done within the architecture, but instead the EA should provide guidelines for teams so that they can generally make their own decisions, but within the framework set by the EA, and they should be discussing any deltas with the EA team.
By providing guardrails, the EAs can help the change teams focus and accelerate change, while still allowing some latitude for independent decision-making, although over time the EAs usually become much more engaged in this decision process as trust builds.
Example 1: Change team needs
If we consider the change team needs, they want to deliver their change as efficiently as possible, on time or earlier and successfully.
Often, the Change Manager will be less concerned by architectural alignment and more about hitting their target dates. If they see enterprise architecture as a bottleneck then they will either be keen to engage early or, worst case, reluctant to engage at all.
The more bureaucratic the process, the more they will lean to the latter so we as architects need to avoid that.
So, the conversation with the Change Manager should be about how you can help them deliver more effectively, e.g. reference architectures, standards, design options, reuse opportunities, new technology options, etc.
It also covers what EA needs from the change teams to enhance the architecture, e.g. alignment to standards, engagement, new reference pattern, information, etc. This mutual agreement provides a foundation and as the Change Manager starts to see value, a project delivered on time, a key issue resolved, etc though EA support, they, and project team members, will become more willing to engage in future.
Example 2: the Design Authority
The Design Authority is often seen as the gatekeeper to architecture alignment, which is valid, however, if you want to be really progressive then your Design Authority should only engage projects with major deltas or that are critical projects.
The DA shouldn’t engage every change, instead EA should provide people with the tools to self-govern and monitor that – if a few people decide to continually ignore the process (you usually get one or two), then a couple of ‘show trials’ usually bring them into line.
We actually built the Technology Product Selector in Essential to automate the project process for an organisation so projects could self-serve – they are told if they are not aligning to the strategy, i.e. they need to talk to EA, and it reduced the workload for the Design Authority significantly.
It means project teams can validate their designs, ensure they are aligned to the EA standards, and it feels like the are being helped rather than being forced to adhere, so everyone benefits, this is an example where the EAs can define the standards and the teams self-govern.
Be the trusted advisor
The lesson is, the less onerous you can make the process, the better, and the more the EAs consult and provide tools to simplify the process, the more they become the trusted advisors.
If you’d like to hear more about how to implement this approach, contact us to find out more.