Prerequisites For Effective Agile Platform Implementations and Systems Integrations

Without question, platforms present distinct challenges to applying lean and agile approaches. I often hear people comment that agile is not appropriate for everything and inevitably they bring up platforms as an example, indicating how the vendor only releases new features every six months, or asking how you implement a material planning system incrementally in an ERP solution. My response is always the same: any platform can be delivered more effectively with lean and agile approaches. The question is only how far can you go with an agile approach? The answer will depend on some fundamental prerequisites. If these prerequisites are not dealt with upfront, the constraints on your agile platform implementation and delivery will be significant.

My focus is on incremental delivery to the end users. It is the feedback from a live production environment that is the most valuable; everything else is a poor substitute. This is ultimately what makes an agile delivery approach the most valuable and why agile and DevOps are tied at the hip — you really can’t do one without the other. Even if you’re not able to deliver incrementally to the final production environment, you can still use lean and agile practices to deliver the platform. To be able to do this, you must invest in your DevOps practices. Things like a staging environment that mimics production and has a continuous mirroring process to recreate the live transactions in the staging environment. With this staging environment, you can then create automated validation that compares key outputs of the two environments as you incrementally deploy the new platform to the staging environment.

We are now ready to dive into the prerequisites of agile platform implementations and system integrations.

1. Let’s start with the receptivity of the user base to receive changes continuously. If you are like me, once I get comfortable with an application, I hate it when some brilliant UI expert decides to change the main UI significantly; now I have to relearn the application. Even if it is a far superior interface, I will moan and groan until I overcome the learning curve.Now, consider incremental changes to the business process. These are changes that are often behind the scenes. Unless you make it front and center, your users may not even realize that steps are no longer needed or worse, are redundant. Introducing AI-driven automation components to the platform will significantly impact end users. Without a robust communications strategy, these changes could end up wreaking havoc on the user base.
2. Does the platform have the ability to deliver updates to subsets of the user base? Feature toggles are in this same category. These are standard techniques to enable agile delivery techniques in custom development. Critical to agile delivery is controlling the release audience so you can minimize the risk of significant errors in the release.

   Here again, we see how important DevOps is to agility. But it is more than DevOps; it is also finding a rollout strategy that allows you to pilot to a smaller user base where you can deploy the minimum amount of functionality. Can you use a product line by product line rollout strategy for your new ERP platform? This may require extra work to integrate the old and new ERP solutions to address challenges where the process must merge. The effort is worth it if it enables you to avoid a catastrophic defect in your deployment process.

3. This next prerequisite addresses upgrades to platforms that require significant data migrations and integration rework. To do an incremental delivery, we will need to be able to apply the Strangler pattern to the old platform as we deploy elements of the new. The Strangler pattern allows you to replace subsections of the legacy platform with the new platform equivalents. This will require significant work to build an interface layer that allows you to have the old and new platforms coexist. This is no small effort, and in some cases, not even possible. You will need to assess the risk of an interim mixed platform versus the risk of a big bang delivery.
4. You will only be able to be as agile with your delivery as the platform deployment features allow. If you cannot automate your delivery from one environment to the next, you will have significant struggles to release on demand. You cannot afford to take the risk of a weekly manual release process. The more modern platforms have already addressed this issue, but very often your legacy platforms have not. Compounding this problem will be the monolithic architecture of the legacy platforms. If the platform at least supports the ability to release subsystems, then you will have much more flexibility to do incremental releases.
5. Has the platform been built with self-training in mind and easy-to-use forms and workflows? If not, the cost of training and communication could make incremental deployment too costly. Don’t just count the cost of creating and delivering the training; you must also count the cost of all the end users who must take the time to go to the training and learn the new features.
6. Many platforms have built-in workflows to help automate and ensure the correct steps are followed for a complex business process. This is all well and good until you want to change these processes and you have to handle the process items that are ongoing. One of my first agile transformations involved a platform that had processes that lasted over a year. This would quadruple the time to change a process, as they had to think through every scenario of in-flight processes and where to place them in the new process flow. The best way to minimize this effort is to design workflows to be short-lived. Split a long process into a series of shorter-lived operations. This will allow you to time your upgrades when the least number of processes will be in flight.

I am sure there are more issues to address, legacy data models that must be redesigned to support the new platform, global enterprises that provide very small windows for upgrades, etc. Ultimately, these constraints will impact your agile delivery approach. The good news is that these constraints do not need to force a retreat back to a full waterfall approach. Incremental exploration and integration are still very doable no matter how you can deploy. This still allows you to take advantage of rapid feedback, built-in quality, and course correction based on what you learn. The struggle will be to make that feedback as close to a production environment as possible.