The incumbent’s advantage

It may seem like the odds of successfully navigating the digital transformation journey are stacked against many of our organizations. And why shouldn’t it? Proven, traditional enterprises have an overwhelming number of planned and in-flight efforts in the pipeline just to keep the business running, encounter challenges finding and retaining the right talent, and wonder if their organizational culture is hindering innovation. What’s more, it seems like a particular jungle-named company continues to make big moves month after month, leaving many organizations to wonder if their particular industry, market, product or service is next. Incumbent firms are sandwiched between the pressure coming from today’s digital giants and the disruptions presented by new digital-native players.

Regardless of the market share they currently possess, younger organizations don’t have as much legacy technological, operational and cultural baggage to consider. This allows them to move faster. Speed, not size is the difference in today’s competitive environment. Customers expect quick and accurate communication, fast and flawless execution, and they reward the companies that innovate and deliver the fastest.  Established firms have mature customer relationships, proven capabilities and strong operations, but their lifetime of growth may have them a bit bloated, sluggish and possibly overly risk-averse. Enterprises are unlikely to touch the “big technology investment” stove again if they’ve been burned once, twice or several times before. In their book, Exponential Organizations: Why new organizations are ten times better, faster, and cheaper than yours (and what to do about it), Salim Ismail, Yuri Van Geest and Michael Malone write that “the biggest risk is not taking any risk.” What are companies to do when it is risky not to embark on seemingly hazardous strategies, but also equally risky to disrupt one’s current state operations and short-term performance by re-inventing themselves? I actually see this two-sided challenge as a digital transformation advantage in disguise.

Leverage, don’t leave, your legacy

The pressure to transform can compel senior leaders to question the state of their current technology solutions, and the application landscape is a common key spotlight area. This makes sense, as software is often the primary place where digital experiences occur with and between employees (the workplace and the marketplace) and customers (the marketplace). Evaluating one’s application portfolio is certainly the right thing to do; however, this application review can morph into application replacement as criticisms and recommendations for alternatives increase, or simply get more attention and action from the top.

I have found that much, if not most, of the negative feedback regarding legacy applications centers on the user interface (UI) and user experience (UX) rather than the underlying functionality. Organizations have spent years, if not decades, developing and enhancing these systems, but the user interfaces may have received less treatment than the core functionality during that time. So, like an old but well-built home, the paint has faded and the carpets are worn, but the “bones” of the structure are sturdy, useful, and trustworthy. I have seen many organizations get swept away by the allure of an SBS—a silver bullet solution—and leave their faithful, albeit aged and visually unappealing, solutions for newer, more modern, and “sexier” products. But, as is the case with close human relationships, we may not consider how accustomed we are to the nuances and behavior of our current partner when seeking a new one. This can result in one experiencing severe whiplash once they choose to live with a different companion on an everyday basis. It’s quite the change management challenge when the new partner (system) takes 12-to-24 months to move in (be fully-deployed and operational), always forgets to replace the toilet paper roll, lower the lid, or pick up the clothes (introduces integration pain and errors), and didn’t know that I’ve always liked to have a romantic dinner on the 14th of any month that ends in “-uary,” not just Valentine’s Day (tribal, undocumented business rules are missed). On top of it all, it is quite possible that the same old frustrations eventually reemerge at some point after the new system settles in. (Maybe it’s us and not them/it?)

To strangle, with love

As an architect, one of my key focus areas is to insulate and connect the organization’s people, process and technology landscape. I must ensure that solutions and their components remain—or become—loosely coupled and well-integrated. This can be a challenge with older applications, particularly for custom-developed systems; what should have been UI-specific code became intermingled with business logic and other non-UI-specific functionality. This leaves one in a particular bind: if it will be painful to bring in a new system and it’s difficult to update just the user interface on the current one, then we have to solve the user experience problem a different way. Let’s explore how we can use our existing applications, expose the business logic, and then provide those business services in a more modern presentation.

In 2004, Martin Fowler introduced the pattern of a strangler application. His writings on this evoke the notion of developing new application components around a legacy application, analogous to strangler fig vines dangling from a host tree which eventually fully engulf the host and consume all of the surrounding nutrients, suffocating and killing the original tree (application). This approach can indeed make the original application irrelevant over time and provide a safer way to decommission the legacy system while wrapping it with healthy, new services used by new user interfaces. (There are also studies positing that the strangler fig may actually help host trees better survive tropical storms. Placing newer, stronger “service vines” around legacy applications helps them and our organizations better survive the digital transformation storm as well!)

If the legacy application has existing services/API or direct access to the code or underlying database is available, then software developers can create a parallel, strangler application/solution that only contains the necessary business logic and exposes it as a collection of services (APIs). Executing this initiative could very much follow a service-oriented architecture (SOA) project lifecycle. The requirements (which likely still need to be revisited, analyzed, and/or documented) are conspicuous and largely accurate, since they are in production today. The strangler application is fully complete once one provides a new user interface which uses the new business services and the old application is no longer needed.

If you are not able to address the old system using the strangler pattern, then robotic process automation (RPA) may provide a “two birds, one stone” option. Much like the all-too-human Wizard of Oz exclaiming, “pay no attention to that man behind the curtain,” robot workers do not mind invisibly reading, typing and clicking away at legacy applications. Many of today’s more robust RPA solutions allow calling a SOAP- or REST-based API as part of their automation. While evaluating areas of automation and reducing human interaction with current applications and implementing RPA, you may also be able to open up these systems and implement events to let other experiences get a more real-time peek into what is going on.

Regardless of one’s implementation choice(s), the mission for today’s architecture and business leaders is to engulf and expose their legacy applications, not rip and replace them. One must modernize their legacy technology backbone while developing new digital experiences—all while sustaining day-to-day operations. This is a challenge that requires organizations to do two types of things very well at essentially the same time. Going for too much “sizzle” and not enough “steak” leads to lipstick-on-pig challenges while biasing too much the other way may result in a great engine, but a body, wheels and paintjob that leaves customers unimpressed and doesn’t move the needle. Let’s discuss how we can help our organizations keep the corporate vehicle rolling while creating a new engine.

Bimodal for overlapping execution

Competing priorities paralyze the workforce; they force employees and teams to ask questions like, “Do I bandage the current system to put out this operational fire or develop this stack of features for the new platform?” I think we all know where the bias goes in these types of situations. While the notion of executing technology efforts differently based on the type of work required has been around for a bit, Gartner’s two-speed technology philosophy has received some strong criticisms since they coined the phase “bimodal IT” in 2014. However, I believe that some of the implementations of bimodal may be the issue rather than the practice itself.

First, enterprise architecture is a must for success in bimodal execution. Our organizations need a strong center of gravity to ensure that the “mode one” (careful, more certain, IT or back office-facing, Waterfall-style) efforts don’t run contrary to “mode two” (fast, more unknown, customer facing, Agile-inspired) efforts. Organizations need to ensure that their roadmaps accommodate any mode one work that may be a prerequisite to delivering the mode two efforts and also need to have a plan in place to fully operationalize and mature mode two efforts, possibly sliding some of them into more of a mode one treatment. 

Next, we should align business capabilities, functions and business services into the two modes, not the underlying applications or systems. Systems can align one-to-one with business structural concepts, but as platforms continue to grow in and around our organizations, we will see more areas where the same system facilitates several business capabilities. CRM systems, for example, may handle sales force automation as their core capability, but they can also handle lead qualification, business process management, customer data analytics and others.

Lastly, our thinking needs to evolve from bimodal IT to the bimodal enterprise. Our firms are technology dependent and likely need to run at two speeds to support the current “legacy” business as well as the new digital-native operations. Innovation and keeping the lights on are both priority one items, so we must do them both.

Act on your advantage

Much like the enterprise, the role of the enterprise architect must also transform. We must become ecosystem architects. First, telephones, and now, social media demonstrate the network effect—and it’s only getting faster and occurring in real time on many more channels (IoT, anyone?). Gone are the days of being able to compete while largely remaining in one’s own four organizational walls. In fact, the very definition of competition should become much more conditional in this digital age. You have competitors today, but the path you take at this digital fork in the road can re-define the future relationships with them as either “possible acquirer” or “occasional partner.” The thing that incumbent organizations fear most—displacement (or elimination) by a quick, customer-savvy, digitally enabled player—can be avoided if they leverage their legacy advantage: assess their technology (and skills) inventory, open up and connect existing systems, and launch fresh, customer-centric experiences. It is your advantage to squander or seize.