Meeting the Modernization Challenge in the Enterprise
Executive Summary
Are you an enterprise that recognizes the business liability inherent in the monolithic or otherwise dated enterprise software applications you have built? Does your technology represent an impediment to the needed agility and flexibility required to meet the needs of today’s business environment? Is your data usable and able to be leveraged to inform actionable intelligence about the needs of your customers?
CIOs, CTOs, and VPs of Engineering can drive the needed modernization and digital transformation with their counterparts in Marketing and the Business to ensure that their organizations remain competitive in today’s customer-driven, data, and technology-led economy.
Successful digital transformations enable organizations to:
Create a competitive advantage by fulfilling unmet needs and accelerating time to value,
Drive onboarding/adoption and engagement of the digital experience platform (DXP),
Deliver quality industry standard data and metrics,
Employ technology upgrades as a continuous and necessary response to industry or digital disruption, and
Reduce the lift on service teams.
Success in digital transformation initiatives lies beyond just installing the right technology. Despite massive investments and multi-year efforts, organizations continue to struggle to derive value from these initiatives and arrive at a transformational business outcome.
Good application design relies on solid technology implementation, but legacy solutions define the efficacy of both the design and the technical solution. Moving forward, experience design becomes constrained by old systems and compromised data quality. These otherwise solvable challenges face an extraordinary additional element when organizations are enmeshed in legacy technology problems, and success demands that legacy debt be resolutely and effectively resolved.
Introduction
For the enterprise, modernization at its most vital can be thought of as the act of updating legacy systems to escape the problems which typically surround them. We can define legacy systems as software or hardware which exhibit some of these challenges:
· They are considered end of life, and have no support
· They are insufficiently documented
· They are difficult to hire for
· They make retention more difficult
· They make functional improvements more complex
A worthwhile observation is that these problems will normally be faced by older, longstanding applications, but similar problems can exist in newer systems where little known or completely bespoke frameworks or approaches have been used. What makes older systems particularly prone to this is that they are often accompanied by accumulated size and complexity, rendering them harder to change. In effect, the greatest challenges and risks of legacy systems come from the combination of obsolescence and systems that have been so successful they have become part of the fabric of the business.
Costs of Inability to Modernize
If an organization is a product company, with end users to keep happy, the impact of unsolved legacy challenges on user experience (UX) can be huge. The technical nuances of adding new features to an old product can shift ROI in hard to predict ways, and engineers can end up with a disproportionate voice in UX design. Product solutions in turn are informed more by what is easy to achieve and less by what the user needs, compromising the currency of the product.
Internal legacy applications present their problems in different ways. When changes are needed, the timeliness of their implementation or the predictability of their success becomes compromised. Workarounds outside the system become the norm, and compound over time. Worse, the complexities of the system, its quirks and the user behaviors that overcome them, make the job of the users more demanding and very difficult for onboarding new resources. As changes happen in the circumstances of the business, processes far removed from the software can be impaired. One unintended consequence is that users find ways to exploit the behaviors of the system and become so entrenched and accustomed to their workarounds that implementing proper and arguably better UX in a new system is met with resistance to change from users.
Maintaining and enhancing a legacy product can feel like rolling a ball uphill, not only because of the ongoing burden of dealing with end of life and vulnerability scenarios. The toll on organizational morale should not be underestimated. A team supporting a lone wolf legacy technology can gain an unfair reputation for unreliable delivery and low velocity. Technical personnel can feel isolated, with only missing or outdated information available compared to the thriving communities that surround current technology. As people leave, institutional domain knowledge leaves with them, putting more burden on those that are left behind to understand and support a collapsing ecosystem. Further, hiring new resources becomes an exercise in looking for anyone with experience in the legacy platform, at the expense of being able to choose team members who align with company culture. For those already on the team, hard decisions will present themselves as people question the career impact of becoming increasingly distant from the state of the industry.
To Replace or Recreate
Technical limitations make us aware of what is wrong with legacy systems, but we can lose sense of what is right about them too. It is possible for legacy systems to simply be leftovers from expedient decisions, and to represent something that could be replaced and possibly improved by buying or perhaps building a better fit. Often however, legacy systems encapsulate something of great benefit to the organization or the customer. Modernizing a large system in place is a complex and costly operation, so the decision of buying or building is something that must be taken very seriously.
Once the decision is made, it should be shared and documented. Modernization is an important part of architecture, and as such the decisions need to be captured to ensure long term follow through and stickiness of choice. It is also useful to have as reference the reasons for decisions in the event that circumstances change that invalidate prior conclusions.
Iterative Mitigation of Risk
We commonly read of large software projects going astray, and often these are large replacements of older systems. The big-bang approach to moving a business function from one system to another is at odds with current agile practices. The modern software development paradigm emphasizes incremental wins versus the risk of older waterfall all-or-nothing deliveries.
Making the shift to agile in modernization takes deliberate steps; code layers must exist to allow users to be passed between new and old in a production situation. The alternative is an immensely risky approach that leaves the real proof of the new until the last minute. This is the classic scenario for unexpected failures. Piecemeal modernization reduces the risk surface of surprises, at least in the number of users affected by changes at one time.
Sometimes this iterative approach can feel like two steps forward and one step backward to the organization. At times, legacy systems must be enhanced to expose interfaces and allow for the passing of data between legacy and newer system components. This can feel like wasted effort and must be articulated to non-technical stakeholders as a viable approach to de-risking the project.
Likewise, deploying new systems alongside legacy system incurs additional operational costs initially until enough of the legacy system is migrated and infrastructure can be decommissioned. It is essential for stakeholders to understand and accept these tradeoffs. Modernization of legacy systems is a challenge at least on par with the development of new holistic systems and should be treated as such.
A Pattern for Success
Step 1: Engage a champion
Modernization needs a champion; someone with enough trust and empowerment to seriously tackle the problem and who knows it cannot be hidden in a few technical debt sprints. The ideal modernization champion knows that addressing the legacy is not an optional exercise for the organization and will support it when the going gets tough. At its most challenging, modernization can resemble the act of driving out of an ill-fated parking spot; a tight maneuver of many points that will necessitate forward and backward steps along the way. The successful champion will anticipate this and be ready to allay doubts.
Step 2: The proving point
The next step is to find a good proving point. Proofs of concept can be useful to test theories, but even a clear plan with low risk can need a successful first application before it passes muster, especially in a culture where theories and temporary directions have been numerous. A working example of modern technology solving a legacy problem can be profoundly helpful. It brings more detail to light, setting the new direction apart from the infinite possible approaches one might propose, and it starts to offer the skeptic a genuine alternative to the false security of the legacy status quo.
Step 3: Persuasion through momentum
From here, people who adopt the direction start to take on the role of champions, widening the brain trust involved in tackling the problems. New patterns and technologies always take longer at first, but as momentum becomes tangible, the modern can and will gain mainstream approval in the organization. More proving points turn the experimental into a force of sanity that people will coalesce around.
Step 4: Involve leadership
Modernization of an extensive system is going to take time and resources, and must be understood by those making the roadmap for the organization. Communication must be effective and understandable in relation to the business. Repeatedly relating technical challenge x to business goals can feel unnecessary or unheard, but it’s a process which strong organizations understand in relation to strategic goals. The key point is that the audience isn’t engineers, but rather the whole business.
Leaders need to familiarize themselves with details that would ordinarily fall rightly under their radar. Engineering departments whose value is solving problems behind the scenes instead must escalate their problems. Although the challenges are by their nature longstanding, there is a critical moment when business risk must be recognized and discussed.
Super-imposing the Modern
As old is migrated to new, there is a transitional period of great significance to the organization. Newer code will be developed which has to make sense in the future while also working with pieces yet to be modernized. Code must be developed purely to enable piecemeal migrations, which in turn are the only way to contain risk. Data schemas morphing from one reality to another will create the need to consider translations, transactions and synchronizations during the transitional process.
Teams and individuals in the organization will likewise have to work through transitional states that require their own attention. New skillsets will be acquired in relation to the new while the existing knowledge will be stretched to meet new challenges. As teams emerge that better reflect the future organization needs, the continuity of the business requires people to also service existing needs.
It is vital to avoid spreading people too thinly. Individuals switching context too often lose their effectiveness on all fronts. Similarly, if an initiative is shared between everyone as a part time focus, it gets the complete mindshare of nobody. The best advice is to focus on the future organizational outcomes; the transitional phase is more taxing than what will follow and is an appropriate time to ramp up resources. If outside parties are involved, make sure the team involvement is right to leverage resources sensibly while also ensuring the organization is left with the right skillsets and knowledge to maintain the future state systems.
Closing Thoughts | Take Aways
Dealing with legacy problems is an inevitable need that is also a test of communications, decision making, and follow through. Once a legacy modernization need is recognized, and assuming the gap cannot be filled with a simple purchase or alternate system, the process must begin in earnest to understand:
· What the system does
· The specific risks that will be encountered in modernization
· The scale of cost to tackle the problem
· How to plan for the change
Unlike the usual turning of the wheels that go into incremental feature design and improvement, these questions can only be answered through involved processes, some of which may take considerable time to work through. So long as the business value of the system's health is established, delaying the process only increases the chances that more organizational knowledge will be lost before it is drawn upon.
In any event, the most serious modernization challenges have one thing in common: they do not go away by themselves.
Authors
Mark Hewitt – President & CEO
Mark is a driven leader that thinks strategically and isn’t afraid to roll up his sleeves and get to work. He believes collaboration, communication, and unwavering ethics are the cornerstones of building and evolving leading teams. Prior to joining EQengineered, Mark worked in various management and sales leadership capacities at companies including Forrester Research, Collaborative Consulting, Cantina Consulting and Molecular | Isobar. Mark is a graduate of the United States Military Academy and served in the US Army.
Julian Flaks – Chief Technology Officer
Julian is a relentless problem solver and hoarder of full stack expertise. Having thrown himself headlong into Internet technology when best practices had barely begun to emerge, Julian is happiest putting his experience to use unlocking business value. Julian holds a Bachelor’s of Laws from The University of Wolverhampton, England and a Master of Science in Software Engineering from The University of Westminster.
Jennifer Parker – Principal Technical Consultant | Architect
Jennifer is an experienced software engineering leader with deep experience in managing personnel, making staffing decisions, driving technical direction across several different projects, and improving software delivery processes within organizations. Jennifer has a passion for architecture, especially distributed systems design. Jennifer has a Bachelor’s degree in Information Technology from UMass Lowell and an Associate of Science degree in Computer Science from New Hampshire Technical College.