For new age companies born in the cloud era, their development approach has always been in tune with the demands of cloud delivery and their user base. For software product vendors with enterprise-grade solutions, transitioning to the cloud can be quite a challenge. They need to examine the way value is created all the way from portfolio planning to release planning to development, delivery and consumption.
Here are a few imperatives for successful transformation to cloud development & delivery model:
Release-based planning to Continuous planning
Upstream processes in on-prem mindset are very tightly coupled with development and delivery compartments around quarterly or half-yearly releases. It limits the ability of the vendor to respond faster to customer needs and competitive pressures. On the other hand, Continuous Planning supports continuous flow of features to the market. Development and delivery cycles are de-coupled with deliver when ready mindset.
Zero-impact consumption patterns
In the on-prem world, each customer would study the myriad of features in a quarterly/half-yearly release, assess impact to their operating environment, make necessary changes to their own business processes & systems and test the ‘Release’ in their QA environment and then roll it out into production. IT function in the customer organization would plan their effort aligned to these release cycles.
In the cloud world, delivered features should be designed for minimal impact to customer environment. There would be two kinds of features: Ones with zero impact and others where the timing of consumption is left to the customer. Customer has the flexibility to adopt only the features they value and consume only when needed after adapting their operating environment.
CI/CD Enablement
Although there are many standard tools in the market to enable CI/CD pipeline, many vendors with legacy software would struggle to adopt CI/CD pipeline. Typically, the software solution is on a technology platform that makes it difficult to implement standard tool chains. It is also possible that the technical architecture of the product could be an obstacle to continuous development and delivery.
Having said that, it is possible to have a practical combination of standard tools and custom-built solutions to enable CI/CD pipeline. Leadership needs to be aware of the practical challenges and be willing to invest in tools and alleviation of architectural constraints.
Organizational structure for flow
With years of release mindset, internal organizational structures are typically silo-ed and optimized for release-based delivery – central co-ordination function, optimized integration & regression testing teams, centralized test labs and test suites for non-functional requirements, hardening phase, and multiple hand-offs.
It is impossible to deliver continuously without progressively dismantling these structures. Progressive de-centralization supported by automation is the best enabler to empower development teams to own the centralized activities without compromising quality and efficiency.
Engineering excellence and Quality mindset
None of the management changes will work if engineering excellence and quality are not owned by each development team and by each engineer. Solid engineering practices in design and development take time to cultivate and master. Leadership in both engineering and product management functions have a key role to play in equipping and committing time and investment to make this a reality.
Customer engagement for broad-based value creation
On-prem vendors would have built great relationship with many large organizations and the product would have evolved and matured thanks to many co-development initiatives. As part of the move to cloud model, engagement with customers needs to change. Typically, product roadmap would be derived from soft commitments made to leaders in the customer organizations. These become the bane of continuous planning – internal leadership starts driving the teams to meet these commitments at various release dates. Release-based planning for over-committed scope eventually leads to quality issues and substantial number of bug fix updates post a major release.
While a broad roadmap is essential for setting broad expectations in the market, feature-level delivery details should be shared only when features are ready and close to being shipped. Customer expectations should be set accordingly. Product Management would then start working with user groups to determine the features that would be useful for the broader market and innovations that would align with the trends in the customer’s business environment. Continuous feedback at feature level directly to developers would build strong ownership in the minds of development teams to deliver value and not just code. Isn’t that a key to agility?
In conclusion, moving from on-prem to cloud model is a journey and can only be realized by collaborative effort of leaders in the organization. Rewards would predictably follow in terms of renewed subscriptions and growth of market share.
anand
