The right roadmap answers a key question: What will this tech enable in terms of organisation, people and agility?
The right technology roadmap is more than a route to greater automation or efficiency for businesses: Technology sits at the nexus of so many business and consumer relationships that designing and embracing the right technology strategy can mean the difference between surviving in the marketplace and not.
The context of tech
No enterprise has the luxury of planning their technology strategy from a clean slate. All have existing technologies, whether added organically as needs arose, bought in response to an urgent project, inherited as a legacy system or introduced tactically to align with the preferences of an influential developer.
The result can be a spaghetti junction of unrelated technologies that make your organisation unwieldy and unable to respond quickly to threats and opportunities. Recognising the extent to which your organisation has become mired in its existing technology infrastructure is the first step to freeing it to become more agile and responsive to the needs of customers, employees and suppliers.
Leaders need to be bold and assess the business and its operating models in their entirety. Making minor changes to your existing technology stack often won’t be enough to keep pace with the rate of digital disruption and will fail to deliver the required return on investment in both capital and learning.
Adoption for innovation
Identifying your approach to adopting new technologies is the next step in designing the kind of technology roadmap that will lead to sustained and repeatable business success. The familiar innovation adoption bell curve plots the stages at which various sectors of the market take up a new technology, from the tiny percentage of adopters who are prepared to take on an innovation as soon as it is released to those who adopt a technology long after most people have moved onto its replacement.
People often consider this curve in the context of time periods of about a decade, but the timeframe is compressed for the technology roadmap. The breakneck speed of changes in technology frameworks and approaches means that most CIOs and CTOs tend to speak in terms of three to five years. With such a short window of opportunity, organisations among the “late majority” are at risk for the future, having gained very little over competitors for adopting new technologies.
Another factor to consider is that adopting a new technology involves more than simply taking on a new framework or language: You are also adopting the community of people who use and support it. If the tech you are considering has a solid, growing following, it is more likely to be relevant and supported for at least three to five years.
For these reasons, smarter organisations seek to be among the early majority on the adoption curve. Adopting a new technology when it has become clear that it has good support assures an acceptable level of longevity while still having some power to disrupt competitors.
Evaluating external input
No enterprise operates in a vacuum. It’s important to be aware of which technologies the major players and influencers in your sector are adopting, as well as the community support behind these platforms.
As well as observing industry trends when defining your technology roadmap, it makes sense to speak to partners who have extensive experience in the area. Relying on the expertise of consultants who have implemented a significant number of projects for a large body of clients can give you the confidence to embrace a platform or approach you may not have considered or simply don’t have the resources to research properly yourself.
When seeking the input of others, beware of small yet influential cohorts of developers who will advocate the next big thing. Of course, you want your developers to be engaged and current with their field — after all, they are the people who will be using the technology — but you need to balance enthusiasm with the business impacts these choices can create.
Flutter is a good example of this: Google’s latest offering is an open-source UI software development kit for developing cross-platform applications that is generating a lot of positive buzz, but Google has developed a reputation for abandoning technology (remember Google Plus?). While Flutter may indeed take off as an approach for cross-platform development, it may also die or limp along, meaning you could struggle to find developers to support you over time.
Ultimately, many enterprises may find themselves better off waiting for a brand new or unproven tech to establish itself or trying it out on a small project first before embedding it in the technology roadmap.
A technology roadmap isn’t just about choosing your next language — it’s choosing your next architecture. – Tweet this
Creating a platform for change
If you decide on a technology roadmap simply to speed up or update your existing organisation, you are probably missing an opportunity. The right technology roadmap will enable a modern tech enterprise in which people have ready access to the tools they need to deliver on business impacts and be agile enough to do so on a basis of continuous change.
That is a lot to ask of a roadmap. It means the technology decisions you make now will dictate the future of your organisation. If your organisation cannot free itself from a mindset that dwells in operational silos, you will find it difficult to take the steps necessary for bold action. A technology roadmap isn’t just about choosing your next language — it’s choosing your next architecture.
Focus on characteristics that support the kind of organisation you want to build. For example, microservices create an architecture that structures an application as a collection of services that are lightweight, independent and focused on specific business-focused concerns. This approach supports continuous change and allows people to be agile and deliver the change your business needs without going through massive change or cost. By creating a continuous change engine, you can build teams around business impact rather than technology silos.
When taking this flexible, change-focused approach to your frontend, avoid building for separate platforms (iOS, Android, the web) in siloed teams, and instead align your teams with your business KPIs. You can do this by adopting a multiplatform approach with React/React Native teams who can develop cross-platform from a single codebase and break features and functions into components — thereby focusing not on the technology but on the business objectives.
Look at the overall ecosystem, the talent that you need and the kind of organisation you could achieve with the help of the right technology and the right processes. Ultimately, you need to figure out where you want to go in order to identify the technology to get there.