In a recent blog post, I gave some insight into some of the fascinating customer-facing work we do inside the Office of the CTO at Citrix and, at the same time, introduced eight of the most commonly observed shifting dynamics that are on the minds of today’s CIOs and CTOs.

As is often the case, these kinds of observations are intended to be conversation starters, but, hopefully, they go on to become great topics of discussion inside our own organization, in subsequent customer meetings, and, of course, on social media.

One of these shifting dynamics drew some attention from my followers on Twitter, where several comments and questions were raised — ultimately ending with a request for some more detail and insight as to my positioning of the journey of “applications.”

I have always maintained that “applications” are not only the lifeblood of every business, but they are the No. 1 thing that CIOs care about. Without applications — however you imagine or classify them — there would be no need for PCs or operating systems, no need for servers, less requirement for complex global networks, and fewer concerns around security.

This might seem obvious, but applications are our customers’ business — regardless of the industry — and now, with digital transformation strategies gathering momentum and delivering tangible benefits, there’s something of a renaissance happening with applications. Whether we’re talking SaaS, web and mobile, or microservices, containers, or functions, applications are cool again.

Cool Doesn’t Always Mean Brand New

But cool doesn’t always mean that everything is brand new. Paradigms, development languages, architectures, and development methodologies have gone through phases of evolution, often leaving legacy and complexity for CIOs to deal with. Managing out is always infinitely more difficult than managing in — especially when it comes to dealing with the line-of-business demand in the fast-paced world of global business.

In my former role, prior to joining Citrix, part of my responsibility was to manage the enterprise application portfolio of a 75,000-person company that had five separate business units, operated in over 100 countries, and executed myriad business models — each with their own unique sets of requirements. I’ve seen this complexity firsthand, and I’ve seen every vintage of software ever invented and every delivery model, whether that was self-developed, commercial off-the-shelf, or SaaS. Whether that was delivered as physical install, virtualized, or consumed in a browser or on a mobile device.

Enterprise applications are hard. Very hard. They also make up a significant percentage of the typical IT budget.

This is why I love talking to CIOs about their application journeys and being able to map their challenges and their strategies to my emerging model: The 7 Rs Of The Application Landscape. The more we learn, the better we can position our overall Citrix products and cloud services to help address the challenges.

Let’s take a closer look — and remember, be open-minded, as the more this serves to generate discussion, the better it is for all of us.

A Closer Look at the 7 Rs

First, let me be clear that the 7 Rs model is not intended to be a continuous cycle, nor is it intended to be a sequential “do loop.” Based on my own experience learning from the many customer interactions I have on a weekly basis, it is feasible that initiatives may be under way and overlap in any of the seven categories, yet it is very common for all initiatives to be executed under the umbrella of some form of modern Application Portfolio Management approach.

Let’s break down the 7 Rs with some key observations for each:

  1. RETIRE — This often consists of a targeted initiative to identify and retire traditional (legacy) applications from the portfolio. For large, enterprise customers, it is not uncommon for there to be multiple versions of the same application running in their environment, along with “orphaned” applications (those that have no clear business owner or sponsor and, in some cases, have no developer resource allocated due to attrition of the original developer or development teams). Most Retire activities are aimed at either reducing operational risk from older systems or reducing cost of running “non-value add” applications (or a combination thereof).
  2. REPLACE — Usually driven by the line-of-business owners, the Replace initiatives are often focused on identifying commercial off-the-shelf or SaaS applications to replace or, in some cases, to augment existing self-developed applications. The commercial off-the-shelf applications are often installed on premises or public IaaS. The primary business drivers of Replace initiatives include overall reduction of technical debt (and associated cost) and work-process optimization using industry standard tools (instead of bespoke.)
  3. RELOCATE — One of the most misunderstood (and possibly over-hyped) reasons for moving to the cloud is migrating applications via lift and shift. Also known as Rehosting, few customers have the enabling technology or the appetite to take on the operational risk of a wholesale lift and shift of existing applications. As most enterprise applications are not atomic units of compute, untangling the application and all its dependencies is almost impossible. Customers who migrate to public cloud often start by rebuilding core components on public IaaS, establishing secure networking and migrating databases as a final step.
  4. RE-PLATFORM — Traditional (legacy) applications are often susceptible to underlying core components being retired by OEMs or ISVs, even if the application has not reached the end of its useful life for the purpose for which it was initially deployed. Re-platform initiatives are often executed “in-situ” (meaning targeting the least possible overall downtime), can vary in scope and complexity, and may also include changes that allow the re-platformed application to be deployed to, and operate on, public cloud — but keeping many of the same vertical and horizontal components from an architectural perspective.
  5. REBUILD — Most examples of Rebuild are concentrated on either replacing existing components, such as a simple user-facing web interface, with newer technologies for a better experience, to modernize unsupported web technologies or to reach a more expansive set of end users or devices.
  6. RE-USE — Primarily used in conjunction with Re-platform approaches, Re-use is a compelling strategy for customers who wish to deliver new user experiences (such as mobile UX or lightweight web UX) by creating an abstraction layer (usually an API construct) between the new UX and the existing system. Not all Re-use requires Re-platform as API shims can be developed as RESTful interfaces to expose subsets of required functionality without changing the underlying platform.
  7. RE-ARCHITECT — Many customers have work processes that are considered to be intellectual property, and existing self-developed applications have supported those work processes over the last few decades. The most common case for Re-architect is to modernize self-developed applications for which there are no commercial off-the-shelf alternatives, often reimagining the entire technology stack (and the associated business logic, rules and workflow) and leveraging microservices or PaaS elements for flexibility.

Investing time with our global customer base helps the members within the Office of the CTO be advocates for CIOs and CTOs who are facing the gamut of challenges within their application portfolios. Our strategies for Intelligent Workspace and hybrid multi-cloud are designed to help deliver flexibility and productivity — across all types of applications — and we’re excited to share more at Citrix Synergy 2019. Stay tuned!