A Roadmap to Transform Software As You Go, Everyday.
We can talk about software transformation all day, but unless there is a roadmap to connect high level business outcomes with on-the-ground initiatives on a daily basis, nothing will get transformed.
1. The Need
If you have ever asked yourself these questions, this roadmap is for you:
- What’s next for my software engineering team?
- How can I deliver software fast, and safe ’N’ times a day?
- How can we minimise the cost of software ownership?
- How can my organisation stay compliant with all my industry regulations?
- How often should I transform my engineering ecosystem?
- What is the best strategy to attract and keep talent engaged?
These are the questions and challenges that today’s technology leaders are facing and for some of them there doesn’t seem to be a quick and cheap answer.
Specifically for those organisations that haven’t invested in their technology stack for many years, the reality of ‘transformation’ could be quite costly and time consuming.
In our view, there are a few essential elements in every successful transformation, and once we start moving toward our clearly defined objectives, we should stick to those principles to be able to finish those programs.
This post is an introduction to our roadmap, however if you’d like to have a look at it, please feel free to download it from here.
2. Ideal End Result
Software Transformation is not a one-stop-shop, and if we think of it as one, every 10 years we have to pay huge sums of money to catch up with our market. Transformation needs to happen every day, by everyone in the team. This is the aim of this roadmap, and the roadmap will help you find a way to achieve such target for any team, and any size.
We can talk about software transformation all day, but unless there is a roadmap to connect high level business outcomes with on-the-ground initiatives on a daily basis with a doable and clearly defined execution plan agreed by the people who are going to do it, nothing will get transformed!
Clear Actionable Plan vs Vague High Level Jargon
If the desired outcome is to transform software, and not sit in four-hour meeting rooms arguing on the semantics, we need to have a guide that is actionable, concise and with realistic time-based milestones. In this roadmap, we have divided that guide into the below themes and for each theme, we have defined achievable goals in the form of specific paths by teams on the ground. We have four paths to:
- Fast Software Delivery
- Safe and Secure Software Delivery
- Affordable, Scalable and Maintainable Software Delivery
- Governance at Scale, and Compliant Software Delivery
As an example, here is what we propose to be implemented to have a fast software delivery ecosystem:
3. Necessities
To successfully execute such as a roadmap, we strongly urge to have the below elements agreed and clarified at the organisation level:
- an overall end to end vision and expected outcomes,
- a product strategy supported by the organisation,
- a holistic understanding of the entire ecosystem and individual components
- and how they fit into the broader picture
without these, the program will go back and forth all the time, as there is simply too much resistance and friction in the system for such a program to succeed.
4. Purpose of Roadmap
This roadmap can be used to build an entirely new software engineering ecosystem from scratch, or to transform an existing one to a modern cloud-native one, with the below outcomes in mind:
- achieve certain outcomes at organisation and team levels,
- promote engineering excellence,
- elevate productivity,
- and transform the experience of people on the ground through software technology, engineering tools, patterns and practices.
5. Approach
As each organisation comes with a unique enterprise and system architecture, design and set of requirements, we have tried to separate the outcomes (‘the what’) from the specific tooling and implementation (‘the how’).
6. Consistency vs Freedom
The larger the organisation gets, the more important it is to have a balance between authority, freedom and consistency. It is critical to have consistent operating models, tech stacks, and processes, but it is also important for teams to be able to move fast without having to ask for permission at every step of the way.
The model we recommend to organisations with large platforms to adopt, is a model in which engineering platforms are moving toward specific outcomes and targets, while still have the freedom and authority to determine ‘the how’ based on their needs and requirements. This will enable them to achieve consistency at the organisation level while enabling teams to innovate and come up with new ways of working.
Over time, the level of consistency at the implementation layer will also increase with much less effort, compared to a model that teams are forced to remain consistent at implementation layer, which not only is hard to maintain but also slow down teams to achieve an outcome
We have also tried to give engineering teams a high-level vision of the steps ahead, in addition to providing brief visibility over critical technology players in the market in a coherent and orchestrated manner by providing an actionable guide for future to overhaul the underlying teams and tech stack.
7. Build vs Buy
We have no specific preference on build vs. buy as it is entirely a decision which needs to be made by individual organisations based on the competitive advantage they seek to gain in their market.
8. Target Audience
The target audience of this report are engineering leaders and IT executives who need to initiate a transformation program, are going through or have finished a round of transformation and would like to follow the ‘transform as we go’ principle to keep their platform updated and healthy at all times to avoid another large transformation in the new future.
To download the full roadmap:
