Enable javascript in your browser for better experience. Need to know to enable it? Go here.
technical-mechanics-modernizing-your-tech-estate

The technical mechanics of modernizing your tech estate

This is the second part of a two-part series exploring the imperative for application modernization. Read Part One here.


Digital transformation has entered a new era where IT evolves from being process-driven to data-driven. How to use data, experimentation, and telemetry to build strategies and drive innovation has become a concern for all companies.


Application modernization is often seen as a critical enabler of becoming a digital business. But getting it right isn’t easy. Mature organizations must consider a large ‘estate’ of interconnected systems, featuring a wide array from old to new, from custom code to shrink-wrapped packages, created in-house or outsourced or acquired from a vendor.


From an IT perspective, legacy burden exerts itself across five horizontal forces:


  • Data. Siloed infrastructure hinders your efforts to view data holistically. Legacy systems will prevent you from becoming a data-driven business and stymie your attempts to get closer to your customers.
  • Architecture and Infrastructure. The world today demands constant availability, turnkey scalability, and quick responsiveness to customer needs. But legacy systems are often the antithesis of these characteristics, compromising customer experience. Legacy systems are often afflicted by escalating costs and long lead times—even for menial tasks—causing business frustration.
  • Legacy Processes and Governance. The organization of tomorrow understands that rapid feedback cycles and the breaking down of siloes are critical to delivering a holistic customer experience at speed. Legacy organizational structures and procedures often work on slow annual cycles and are reactive instead of proactive, forcing a business to guess where the market will be months or even years ahead.
  • Cloud. It’s been clear for a long time that cloud—whether public, private, or hybrid—is the best modern hosting platform. Legacy applications are rarely cloud-ready, and a simplistic “lift and shift” approach can create headaches because cloud typically trades high reliability of individual servers for high reliability of the platform as a whole. To work, legacy applications must be updated using “12-factor” techniques that account for this tradeoff.
  • Security. Every week we read a new story about a breach or data loss, and consumers are ever more heavily attuned to the security stance of companies they buy from. While legacy systems are not inherently less secure, applications that are difficult or costly to administer may fall behind in security fixes and patches and present a large attack surface to the outside world.

But upgrading and replacing systems is not new—why is there such a hyper-focus on application modernization today? We think there are two key reasons:


  • Tech-driven capabilities—especially those driven by Cloud, automation, and -as-a-Service—allow businesses to respond faster to market changes, experiment rapidly and course-correct, and to sense and respond to demand signals faster. Legacy systems often lack these capabilities and cause an organization to lag behind the state of the art.
  • Competition is fierce, and now not just for customers: the technology talent market is white hot, and the best technologists have their pick of where to work. Organizations realize that by modernizing their systems, they can attract top-tier talent as well as realize competitive benefits.


Technology, people and business aren’t separate. Improving a legacy technology situation forces you to re-examine business processes and organizational structures as well as technical systems.

In fact, trying to solve technical problems on their own is one of the main stumbling blocks for organizations that seek to modernize.

While making the journey towards modernization, remember these three critical principles:


  1. Break down silos and barriers and align your organizational structure towards common goals. Every handoff is a potential for miscommunication, slowdown, and frustration, and every misalignment is an opportunity for someone at your organization to ‘win’ while another ‘loses.’ Ensure that your organizational structure sets everyone up to win together, which is a win for you all as a whole.
  2. Shorten feedback cycles, whether they are technical, organizational or business. Developers love to use automated tests to see if their code works and they are making progress—the amount of time from deciding to change something to getting feedback on whether the change was a success is called cycle time. Apply this thinking to your business strategy as well as IT—how soon can we see if our strategy is a success? How can IT systems help us reduce our cycle times?
  3. Empower local decision making by those with the closest connection to customer need. Whether a customer is an internal team using an API or platform, or a consumer choosing your company's products, people who work closest with the customers are best placed to understand and fulfill their needs. Push decision making ‘down’ to those closest to the customer.


A seven-point plan to modernize your tech estate


These principles might remind you a lot of Agile software development, and this is no accident: we’ve found that Agile principles scale ‘upward’ extremely effectively and help significantly at the enterprise systems level. Here’s how to apply the principles to your organization:

 

  1. Approach modernization as a ‘roadmap’ exercise, not as a plan to be cast into stone. As you make progress on the modernization journey, new priorities will emerge. The business landscape will change, competitive threats and opportunities will emerge, and technology will change too. When the next Docker or Machine Learning explosion occurs, your plans will need to shift to accommodate the new advance.
  2. Own the seams between systems and components. Any enterprise estate will contain a variety of technologies, in-house custom developed systems, vendor-maintained systems, and packages. Your enterprise integration strategy must be firm and opinionated as to how these components should talk to each other, share data, and collaborate.
  3. Prioritize action by evaluating each of your systems considering the following characteristics
  4. Actual pace of change of the system, as well as the desired pace of change
  5. Cost of change, as well as time taken
  6. Business impact / importance/ $ opportunity loss of not transforming
  7. Risks of not transforming versus the risks of transforming, along with the dimensions of the severity of the effect on products and processes, occurrence, detection during design and delivery, and operational risks.


Systems that you want to change quickly but cannot and that have high business importance are a good candidate for immediate action. Systems that take a long time to change but actually aren’t touched that much are probably a lower priority. Remember, choosing what not to upgrade or replace is as important as choosing where to make big investments in changes.


  1. Consider downstream impacts and knock-on effects for changes. In recent years, an explosion of ‘digital’ technology has improved customer connectivity and increased touch points. But these enhanced front-ends often put significant stress on downstream systems that can fail under the load. What used to be a simple linear flow has become disrupted by new use cases—for example, “buy online, pick up in store”—and has now become a complex graph with many potential entry and exit points. Your modernization plan must account for likely interactions between systems and not just consider components in isolation.
  2. Apply a legacy modernization pattern for each system. Although there are a large number of techniques at your disposal, modernization patterns fall into three buckets:
  3. Replacement, either by custom code, a new package, or SaaS. We recommend incremental replacement using strategies such as “tearing strips or slices off” an old system and re-implementing (for example by business process or functional area) or using the strangler pattern to overlay and kill an old system, but non-incremental “big bang” migrations can work in some cases.
  4. Augmentation, by adding a new system alongside an old one and mediating requests between the two, adding a service interface that all new integrations should use.
  5. Continuation, where we keep an older system running but make some improvements to make it a bit more modern, for example adding better testing, build automation or APIs. Remediation is not a dirty word; some systems are going to live a long time. Create a baseline of ‘acceptable’ characteristics for a system (automation, deployability, etc.) and improve systems that fail to meet that bar. An important idea to consider is Evolutionary Architecture, which allows us to incrementally improve a system over time. With this approach, we define architectural fitness functions that encapsulate what “good” looks like for the system and then make incremental changes improving the architecture and its adherence to the fitness functions.
  6. Include existing staff in the success of new systems. Any modernization journey will cause major changes in your current people. Many IT staff are fearful of efforts to update legacy systems—after all, a large part of their job is to take care of that older piece of technology, and they may be concerned their skills won’t map to newer systems. Legacy IT staff will continually create political obstacles to the success of a new system and in some cases will outright sabotage your efforts. To get around this, it’s important to include existing staff, making them at least partially responsible for the success of the new system and to engage their expertise in creating a replacement. After all, those staffs have years of knowledge about how your business works: use that to your advantage!
  7. Re-evaluate your plan periodically, taking into account changes in the business and technology landscapes. But remember not to “over plan”—your plan should be a guide rather than a rigid structure. After all, you never know when the next big technology shift will occur, and you will need to adapt to account for it.


Conclusion


By following this flexible planning and road mapping approach, you can create a unique blueprint to modernize your technology estate. Modernization is a continual journey; many organizations fall into the trap of only investing when they reach a critical juncture. Don’t be like them—regularly assess, plan and invest in keeping your technology estate modern and effective. The payoffs in speed, flexibility, and responsiveness to your business will allow your organization to thrive in a time of unprecedented change and disruption.

How can you achieve faster growth?