In an earlier post, “Why Digital Transformations Fail – the Monolith Syndrome”, we highlight that, throughout its growth, a company navigates different maturity stages on the business side, which often require foundational changes in the technology, i.e. digital transformation. Typically, the first type of digital transformation requires addressing the Monolith Syndrome.
Now that CEO and CTO agree that a new software architecture and a new way of developing the product are needed, they kick off a review of the main usage paradigm(s), renew product requirements, design new user experience, build more automation, and better tools. Everything is looking good… but maybe not! The danger of future proofing lurks.
What is future proofing?
Future proofing is to: “make (a product or system) unlikely to become obsolete or fail in the future” – according to Google and Oxford Languages. When a technology company’s CEO asks the CTO to build a future-proof architecture, the emphasis is less on obsolescence – but rather on designing an architecture that will support markets on the product roadmap, as well as others identified in the long-term strategy and the vision for the company. The intent is simple: designing and building a new architecture is a lengthy and costly project, let us avoid doing this in the future by future-proofing the architecture. This seems like a logical and benign request: put in a little more work and make sure the architecture extends another five years.
Unfortunately, it is a mistake. It breaks one of the fundamental principles of Lean Product Principles: “Defer Commitment”, which means:
Not plan (in excessive detail) for months in advance.
Not commit to ideas or projects without a full understanding of the business requirements.
Constantly be collecting and analyzing information regarding any important decisions.
The second point is the most applicable here: designing a new architecture is a complex and challenging effort. By attempting to design for the long-term strategy, beyond what is on the horizon, we are complicating the design with ill-defined and incomplete requirements, for markets that we may end up not pursuing. Worse, by adding these speculative requests, we are delaying and complicating the redesign effort.
This does not mean that strategic aspirations need to be forgotten. This is where the technology roadmap comes in.
MOST digital
transformations fail.
Yours doesn’t have to.
Introducing the technology roadmap
As a CTO, you own the architecture of the software (among other things). One of the traits that characterizes a good architecture is the velocity at which new features can be created, as well as supporting other requirements like scaling and resiliency.
The product roadmap is the main source of information for the features that will need to be built in the short (3 months) and medium term (up to 24 months). Some features are incremental additions to what already exists, others require the addition of new technology – some of it simple (e.g. adding chat to a web site), others more complex (e.g. a recommendation engine for an e-commerce site). CEOs often fail to appreciate that adding new technologies to a product requires a research phase, where different approaches are researched, candidates are prototyped, pricing is analyzed, one option is selected from a reference implementation and is built for developers to use. The more complex the new technology (e.g. recommendation system), the more difficult it is to predict the time and effort needed to complete the research phase. As a corollary, short-changing the research phase leads to gambles that may, or not, pay off. For example, it is very costly (and not accounted for in the product roadmap) to replace a framework three months after deployment because it does not scale.
The technology roadmap is a companion to the product roadmap. It identifies the projects required to deliver new “breakthrough” features: e.g. supporting international operations, migrating to a self-service user model, enhancing the product with artificial intelligence (recommendation system, or even Generative AI), etc.
As the tool that presents the time, effort and money required to add completely new capabilities, it allows the CTO to start the research efforts (which can last months), early enough to be ready when the time comes to attack the new opportunities. Equally important, it guides the effort into making business cases for high-value opportunities (e.g. introducing AI-driven recommendations in an e-commerce site), and whether the new opportunity warrants the costs of developing the new technology.
To highlight the contrast further, “future proofing” locks-in a certain version of the future by building in advance certain capabilities in the architecture. The technology roadmap offers options for the future: it captures the technical and budget information so that the company can capitalize on the new opportunities – when the timing is right . Anyone who has experienced life in a small and growing company knows how impossible it is to predict the future, let alone its timing. Spending money, time, effort, as little as possible now, while having options for the future should be the goal.
Future proofing enough – but not too much
In practice, how does one determine the right amount of future proofing? The guiding principles are:
Only design for capabilities for which both a strong business case and well defined requirements exist.
A new architecture should carry the company for at least 2-3 years.
If the two items above contradict, take the time to talk to customers and build a solid product roadmap.
In summary, the process for a digital transformation should be as follows:
Refresh the product roadmap to a 2-year horizon – led by the CPO, resulting in a formal sign-off by the executive team. Product roadmap must be backed by engineering estimates, realistic schedules and associated budget – at least for the first year.
CEO and CPO extend the product roadmap by 1-2 years with strategic goals and secure agreement from the executive team.
The CTO, with support from the CPO, updates the technology roadmap to support both the product roadmap and strategic goals. As a result, the big ticket items are identified, whether because of schedule, resources or budget constraints.
Iterate the three steps above until the executive team reaches full alignment. This may necessitate fleshing out business cases further, early prototypes of new technology, and deeper consultation with end users.
Get in touch to learn how SVSG assesses digital transformation bottlenecks, designs digital blueprints, and leads transformation efforts.
Bernard Fraenkel
Bernard has over 20 years of experience leading engineering teams that deliver mission-critical software applications for the enterprise. His teams have delivered SaaS and mobile applications in markets as diverse as digital marketing, mobile banking, distributed storage, education, augmented reality, social messaging, email, web hosting, e-commerce, neuroscience and distance learning.
