It may seem like the odds of successfully navigating the digital transformation journey are stacked against many of our organizations. And why shouldn\u2019t 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\u2019s 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\u2019s digital giants and the disruptions presented by new digital-native players.\nRegardless of the market share they currently possess, younger organizations don\u2019t 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\u2019s competitive environment. Customers expect quick and accurate communication, fast and flawless execution, and they reward the companies that innovate and deliver the fastest.\u00a0 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 \u201cbig technology investment\u201d stove again if they\u2019ve 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 \u201cthe biggest risk is not taking any risk.\u201d What are companies to do when it is risky not to embark on seemingly hazardous strategies, but also equally risky to disrupt one\u2019s 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.\nLeverage, don\u2019t leave, your legacy\nThe 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\u2019s 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.\nI 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 \u201cbones\u201d of the structure are sturdy, useful, and trustworthy. I have seen many organizations get swept away by the allure of an SBS\u2014a silver bullet solution\u2014and leave their faithful, albeit aged and visually unappealing, solutions for newer, more modern, and \u201csexier\u201d 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\u2019s 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\u2019t know that I\u2019ve always liked to have a romantic dinner on the 14th of any month that ends in \u201c-uary,\u201d not just Valentine\u2019s 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\u2019s us and not them\/it?)\nTo strangle, with love\nAs an architect, one of my key focus areas is to insulate and connect the organization\u2019s people, process and technology landscape. I must ensure that solutions and their components remain\u2014or become\u2014loosely 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\u2019s difficult to update just the user interface on the current one, then we have to solve the user experience problem a different way. Let\u2019s explore how we can use our existing applications, expose the business logic, and then provide those business services in a more modern presentation.\nIn 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 \u201cservice vines\u201d around legacy applications helps them and our organizations better survive the digital transformation storm as well!)\nIf 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.\nIf you are not able to address the old system using the strangler pattern, then robotic process automation (RPA) may provide a \u201ctwo birds, one stone\u201d option. Much like the all-too-human Wizard of Oz exclaiming, \u201cpay no attention to that man behind the curtain,\u201d robot workers do not mind invisibly reading, typing and clicking away at legacy applications. Many of today\u2019s 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.\nRegardless of one\u2019s implementation choice(s), the mission for today\u2019s 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\u2014all 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 \u201csizzle\u201d and not enough \u201csteak\u201d 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\u2019t move the needle. Let\u2019s discuss how we can help our organizations keep the corporate vehicle rolling while creating a new engine.\nBimodal for overlapping execution\nCompeting priorities paralyze the workforce; they force employees and teams to ask questions like, \u201cDo I bandage the current system to put out this operational fire or develop this stack of features for the new platform?\u201d 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\u2019s two-speed technology philosophy has received some strong criticisms since they coined the phase \u201cbimodal IT\u201d in 2014. However, I believe that some of the implementations of bimodal may be the issue rather than the practice itself.\nFirst, enterprise architecture is a must for success in bimodal execution. Our organizations need a strong center of gravity to ensure that the \u201cmode one\u201d (careful, more certain, IT or back office-facing, Waterfall-style) efforts don\u2019t run contrary to \u201cmode two\u201d (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.\u00a0\nNext, 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.\nLastly, 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 \u201clegacy\u201d 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.\nAct on your advantage\nMuch 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\u2014and it\u2019s 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\u2019s 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 \u201cpossible acquirer\u201d or \u201coccasional partner.\u201d The thing that incumbent organizations fear most\u2014displacement (or elimination) by a quick, customer-savvy, digitally enabled player\u2014can 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.