As enterprise architects, we are responsible for conducting analysis, design and planning for the successful development and execution of information technology strategies. Our role requires us to be a jack of all trades, guiding our companies – or clients – to ensure that proper technology systems are used across business units to achieve their strategic goals.
Given the complexity of our role, communicating with all levels of an organisation is a given. Be it the with those implementing the change on the ground or the C-level executives driving strategy. We have to be visionaries, who can see the big picture and think strategically – while having a sound understanding of operations and the granular steps required to guide our business through change.
We rely on effective collaboration and communication for our projects to be a success – we need endorsement and support from many (if not all!) areas of the business; otherwise, we’re on track for sure-fire failure.
Ineffective communication of our strategy and the broader vision is where I see the greatest risk for enterprise architects to come unstuck. We may have all the checks and balances in place, but if we’re not communicating efficaciously, and not tailoring our message to the audience we’re speaking to then we risk falling at the final hurdle.
When communicating strategic change to internal stakeholders, we need to be adequately prepared for the questions that may come our way. In my experience, the most common questions I faced are:
- How do we get to where we want to be from where we are now?
- What is the immediate next step?
- What does this mean for me?
- Which technology do we use?
- What will be the impact on the business?
- Should we consider a partnership?
- What are our options?
- How much will it cost to invest in this change?
How to create an effective reference model
There are many examples of reference models available online these days – it just takes a quick Google search, and you have immediate access to pages of templates. However, reference models are not one size fits all, and they only work if they address your businesses’ unique set of circumstances. Beyond tailoring your reference model to the business environment, you must also customise the information provided to different departments within the organisation.
For instance, you’re seeking to implement the migration to a new payroll system to improve security and remove human error. In this case, different departments will need different information to better understand the action required from their end and how the proposed change could impact them. The C suite would only need high-level detail, like the cost of the new system, the assurance that it will function correctly and that there won’t be any adverse financial impact to the business in the transition.
However, when communicating the intended strategic change to those on the ground who would be responsible for implementing the migration, a reference model will provide more granular detail – the impact on the resources, an understanding of the back end technology and how to set each employee up on the new payroll system.
- Technology and business leaders – The reference model for this group, must show how the recommended course of action helps to achieve the business objectives. It should show relationships between functions and with external partners at a high level – the ‘decision point’ for this group is whether or not to endorse the project.
- Solution designers – The reference model for this group, must ‘come down a level’ from what’s presented to the C Suite, and show the relationships between detailed design principles, key decision points, relationship diagrams and models for a particular domain’s infrastructure.
- IT management and program managers – the reference model for this group should show dependencies between IT systems, information, people and process. It should also speak to specific Application Program Interface (API)s.
- Developers and engineers – The reference model for this group should show the project’s implementation plan. For example, if you’re building an app – a reference model outlining an implementation plan should show the relationships between APIs, pattern domains, development principles and standards.
In summary, no matter the audience you’re speaking to – an effective reference model must be customised to fit the company’s business strategy. It should identify potential uses, demonstrate connections and overlapping functionality, manage technical diversity, clarify potential partnerships and determine specific outcomes.
It’s important to note that no matter which audience you’re talking to, a reference model should always serve to demonstrate how everything fits together. Below is an example of how you can tailor a reference model for one project to four different audiences – in this instance, I’ve used technology and business leaders, solution designers, IT management and program managers, and developers and engineers to illustrate:
How to create an effective roadmap
The other important tool that enterprise architects have at our disposal is the roadmap. While reference models show how things fit together, the roadmap is a visual tool used to show the key milestones and deliverables (or actions) required to manage change from the current state of the business to where your strategic plan seeks to take the business.
In essence, the roadmap shows the tasks that need to be completed by who and when. These tasks relate to people, process, technology, risk mitigation and budget. However, a roadmap isn’t just a laundry list of tasks – it needs to show how deliverables work together to ensure alignment and avoid double handling.
Much like a reference model, an effective roadmap needs to be tailored to the audience you’re addressing – whether that be business leaders, technology leaders, program managers or project managers. The roadmap must identify the risks, opportunities and potential impact for each target segment. It also needs to demonstrate how operational tasks serve to meet strategic ends, and clearly show incremental progression (e.g. six months, 12 months, 18 months) from the current state to the end goal.
Here’s what to consider when designing an effective roadmap:
Tailor the roadmap to the audience – the best way to tailor your roadmap to your audience is to consider the team, the person, and the role they play. Try and anticipate questions that they may have and how the proposed change has the potential to impact their department.
Illustrate the direct link between business strategy and proposed changes – A simple way to do this, is to introduce your roadmap by replaying the brief, stating the problem you’re trying to solve and an outline of how you propose to solve it. Ensuring both your problem and solution statements align with the business’ strategy.
Show an awareness of external trends – Remember that businesses don’t operate in isolation, they are a part of a wider economic, technological, social, political and cultural environment. When presenting your roadmap, it’s important to show an awareness of the world around you and the trends that can potentially impact your project. Having said that, your roadmap should still be centred on the future state of your business specifically, not just the industry.
In conclusion, whether developing a reference model or a roadmap, it’s essential to know your audience. I have developed a framework to help tailor your tools to each target group, giving a guide on the level of detail required based on who you’re talking to:
As enterprise architects, if we can determine the challenge or opportunity a stakeholder audience is facing and tailor our message accordingly – and show clear timelines of deliverables that align with the business’ strategy, then we give ourselves the best chance at getting buy-in for proposed strategic change.
