Three Keys to Successful App Transformation

Three Keys to Successful App Transformation

How old are your applications? Your database systems? Is any of your technology nearing (or way past) its end-of-life and no longer supported? Over the past ten years and longer, Enterprise IT shops have traditionally tried to minimize the cost of their existing systems by basically ignoring them. "Don't fix it if it ain't broke," a common theme for traditional IT, has resulted in a new set of problems, including:

  • The inability to change applications fast enough (if at all) to meet new business challenges?
  • Increased risk of significant system failure and emerging security problems due to age and lack of support
  • Increased costs as application and related technology maintenance and operations become more difficult

"Digital Transformation" has become a rallying cry by technology companies and analysts, providing a vague promise of transforming IT and business into a modern, streamlined company using the latest technology. There's no doubt that?transformation?is needed - across people, processes, and technology - for companies to break out of the tangled restraints of their old systems and start realizing the potential of new technology, whether that means just catching up with competitors or completely reinventing the business.

At the core of digital transformation is the transformation of?Applications -?where business people, processes, data, and technology meet, allowing the business to conduct its operations in new and better ways. Applications are where people interact, organize, collaborate, and transact with customers, suppliers, and the larger market. Hence, application transformation is critical if your applications are stuck in the past and holding back the business.

There are many potential ways of transforming applications, including modernizing the underlying technologies, including:

  • Buying package applications?- This can be very useful but may have limited transformational results, as competitors can buy the same capabilities. Application 'packages' (or suites) seldom provide new competitive or strategic gains.
  • Modernizing existing applications?- In some cases, incrementally replacing application components or underlying technology can help start the transformation process. App modernization can be a good choice when you have a large amount of business data that cannot simply be "moved" to new technologies.?
  • Redesign and Build "new" applications -?More often, we find that companies must consider redesigning and rebuilding their applications to provide the capabilities the business requires. This is particularly true for traditional applications fundamentally 'stuck' in obsolete tech and system architectures. Taking advantage of new technologies often requires?reimplementation, including moving towards cloud-native and microservices-based applications.?

Digital Transformation is more complex than transforming a?single?application. Instead, most organizations have to look at changing their portfolio of applications that work together (or should work together). The three approaches above are best when applied to a portfolio of applications. Application Transformation typically requires using a combination of these approaches.

Regardless of how you consider transforming your application, the reality is that any significant App Transformation effort will take time, even if the technology is ready in a few days. At T4S Partners, we work on App Transformation efforts that often span several years for large, global enterprises, where the technology changes are only part of the overall effort. This doesn't mean that App Transformation efforts take years to show any value; successful Application Transformation efforts must deliver ongoing and incremental value - often within weeks or months - to the business regardless of their broad timespan.

And it is this last point that leads to the three keys to successful Application Transformation efforts. The "Success" of an App Transformation effort is not just realizing change at an endpoint in time but also adding value to the business and its stakeholders throughout the journey. Each of these keys applies regardless of what your applications do, what technology you are (or want to) use and the specific business goals you're trying to reach.

Key 1: Minimize Disruption

The corollary to Adding value to the business is: Keep from?lowering the current value to the business. Therefore, during the transformation effort, try not to interrupt, interfere, or otherwise?disrupt?the current business operations. In other words, conduct the transformation to minimize?disruption?to the existing business.

I first heard the phrase "Changing Tires on a Moving Car" from Max Hopper, VP at American Airlines, in the 1980s and co-creator of the SABRE Airline reservation system. This phrase is apt for describing the complexity of changing the core applications of a business?while keeping the company running.?To do this requires that any App Transformation effort consider minimizing disruption throughout the entire endeavor. This means figuring out how the business can continue operating while switching to new or modernized applications.

The specific approaches to minimize disruption to the business can vary widely but almost always involve the following elements, which all need to be explored, planned, and adjusted throughout the effort:

  • Integration Requirements -?Not all applications may need to be transformed (or not simultaneously). This implies that new & old applications (and their data) will likely require additional integration to continue working during the transformation.
  • Coexistence Approach?- New and old applications will operate side-by-side, supporting business processes across multiple overlapping systems. A close understanding is required of who is using which applications and when.?
  • Data Migration Plan -?Existing operational data stored in databases will need to be migrated to the new system over time, often requiring the coexistence of the same data across new and old applications and detailed attention to how data is moved and managed.
  • Cutover Strategy -??Depending on the size and complexity of the business, a cutover strategy is needed that lowers the risk of disruption by finding the proper boundaries to 'switch over' users incrementally. For one firm, we conducted critical cutovers by leveraging side-by-side coexistence with real-time data synchronization, where the team moved users to the new system. Once all the teams had switched over, the old system could be turned off. In another case, we "cutover" a global application on a per-country basis, limiting the impact on the overall global business.?

In all cases, minimizing the disruption of an app transformation effort requires taking an incremental approach. Unfortunately, history is replete with examples of "Big Bang" cutovers between new and old applications that are disastrous. Taking a gradual approach then leads us to the following key.

Key 2: Go Slow

Application Transformation efforts are more likely to succeed if they are methodical, planned, structured, and adaptive over time. Conversely, trying to rush Application Transformation efforts will create more disruption and chaos, usually leading to even less value delivered to the business than had the approach been slower.

This is particularly true early on in the transformation effort. We've seen that when the transformation program tries to do too much too early, the overall attempt is cut short or delayed further, making any transformation in the future even more problematic.

In our experience, "going slow" is best realized through the following actions:

  • Set the expectation that there's some amount of time (potentially months) for the project team to understand what?needs to be changed and establish a strategic and tactical plan to realize those changes. Some of this time is taken simply by building a clear value proposition and support for the effort across a broad set of stakeholders. Nevertheless, this initial phase should always be time-boxed and have clear, actionable outcomes.?
  • Identify and start with small but still value-adding initial outcomes.?We often look for a gap in the existing applications that can be quickly filled ("adding something new") while working on setting the stage for the greater transformation effort. For one company, we did this by adding previously unavailable Management Dashboards.?
  • Prepare to learn from the initial effort,?especially how the business and IT react to even more minor changes. This often demonstrates to the company leadership the gaps in their IT skill sets to handle the upcoming changes. Additionally, this early effort exposes any "Immune system" reactions, where organizational culture and processes present obstacles that must be addressed before more extensive changes are made.?
  • Build and test the architectural foundation early.?Adopting new technologies as part of an application transformation effort usually requires new infrastructure and application design, much of it coming together for the first time within the organization. Architectural and technical assumptions must be tested as early as possible, so they can be changed (if needed) early.

These actions are critical to enabling the following (seemingly conflicting) key to successful transformation efforts.

Key 3: Go Fast

Going slow, at least initially, allows you to put in place those capabilities and competencies that enable you to accelerate the transformation effort over time, leading to faster delivery of new applications and new business value. Not only does the Application Transformation effort need to improve how quickly, efficiently, and effectively digital solutions are delivered to the business, but put in place an organizational and technical foundation that enables a rapid 'speed-to-market' even after the formal transformation effort is over.

So what are these capabilities and competencies that enable faster value delivery? At the core, they combine new solution architectures, better delivery methods, and a matching culture of continuous delivery.

New Solution Architectures

All Application Transformation efforts need an Architectural Foundation - an overall system and technology design that combines patterns, methods, and components - that enables the desired transformation and near-continuous transformation going forward. This means finding the correct architectural elements for building?and changing?the new applications. The specific set will vary depending on needs. Still, as more organizations look for scalable, flexible applications that can be adjusted incrementally without requiring yet another substantial application transformation effort, several 'new' approaches in system architecture have emerged to provide a foundation with better longevity:

  • Microservices architecture
  • Event-driven and Event-sourcing architectures
  • Polyglot data persistence (going beyond only using SQL databases)
  • API-based Loose Coupling methods, such as REST or GraphQL

However, applying these and other latest software architecture approaches has to be done within the context of the business and its goals. Adopting software architectures, like cloud technologies, requires careful analysis and understanding of the tradeoffs (and there are?always?tradeoffs to be made.)

Better Delivery Methods

Only some companies need to be able to release thousands of production application changes a day (like Netflix can do). But all companies can benefit from improving the ability to quickly deliver improvements and additional capabilities to their applications in a controlled manner. The current name given to the most recent generation of this ability is?DevOps,?which combines process, tools, and organizational changes to enable faster delivery of tested software changes from development into production.

There are many views and definitions of DevOps, but most have a few core elements in common:

  • Cross-organizational teams that combine software development with IT operational expertise?
  • Agile development methods (of which there are many)
  • Integrated Tools and Automation that eliminate manual effort to release applications and increase the visibility of software lifecycle, thereby accelerating the ability to track development work and then push thoroughly tested changes into production.
  • Sophisticated monitoring and analysis tools that continually check and report on the operational performance of applications (on many levels)

In addition to the increased popularity of DevOps, companies realize further improvements and acceleration of software delivery through techniques and methods that shorten the gap and cycle between understanding the business changes needed to their realization in production software. Three ways that we have used successfully are:

  • Domain-Driven Design (DDD)
  • Event-Storming?
  • Rapid User Experience (UX)?and?Architecture Prototyping, including Mock-up?and?Functional prototypes

By combining these delivery methods with the right solution architectures, as well as the appropriate modern application platform technologies - such as OutSystems and Microsoft's Azure Platform-as-a-Service offerings - we can reach much higher delivery?velocities, where we can go from business requirement discovery to business testing of deployed end-to-end UI & functionality within a few weeks or shorter.

Culture of Ongoing Continuous Delivery??

But enabling this ongoing?Continuous Delivery?requires more than solid architecture, great tools, and lots of automation. Building cross-functional teams with a shared philosophy and understanding, aiming to deliver better applications faster, is central to making all this work. Additionally, our teams look at the entire 'full stack' - not just the traditional application elements but also everything needed for continuous delivery.

Our view of applications - operating systems that support business processes and provide business value - is much broader now, where DevOps, architecture, infrastructure (now as malleable as software), operations (monitoring, change management), usability, training, and even disaster recovery are all part of the application design effort. Of course, applications' functionality is still critical to the business, but it now plays one piece among many in the broad definition of the "application" we build, maintain, and extend over time.

Our teams now see the business value, speed to value, and ease of ongoing transformation as the primary outcomes of their work. If you focus on those actual goals, along the better delivery methods and solution architectures, your ability to successfully transform applications - and hence the business - will be within reach.

Combining the Keys

By addressing all three keys together: Minimize Disruption, Go Slow,?and?Go Fast, we've been able to take the challenge head-on that most IT organizations fear: Transforming Applications to improve the business now and be able to continue improving the company in the future. Of course, these efforts have been driven by very different factors: desired business growth, "burning platforms" in the form of ancient technologies, changing markets, mergers & acquisitions, and improving employee efficiency. Regardless of what the drivers are, by applying these keys to successful Application Transformation over time, any organization can realize true digital transformation.

Whether your goals involve improving operational efficiency, enabling innovative products & services, or driving market growth, for a single business line or the entire enterprise, Application Transformation is necessary for?all?businesses. Even greenfield initiatives can benefit from understanding the three keys since they all apply once any organization, new or old, starts using applications.

要查看或添加评论,请登录

Rick Munoz的更多文章

  • Why We Need LLM Output Gatekeeping - Policing AI Agents

    Why We Need LLM Output Gatekeeping - Policing AI Agents

    In Computerphile's recent video on "Generative AI's Greatest Flaw," Mike Pound shows how indirect prompt injection…

  • Dividing Event-Sourcing into nanoservices

    Dividing Event-Sourcing into nanoservices

    A few years ago, I led the design of a cloud-native financial management system meant to run globally, with users in…

  • Which Low-code development platform is best?

    Which Low-code development platform is best?

    Are you grappling with deciding which low-code application development platform to use? The landscape of low-code (or…

    2 条评论
  • DeepSeek's AI improves when rewarded

    DeepSeek's AI improves when rewarded

    Reinforcement Learning (RL) has been a popular approach to training and improving AI models. Here's an…

    2 条评论
  • AI can't learn without asking

    AI can't learn without asking

    I ran across this great video from IBM Technology on "Can AI Think? " It points out that LLMs (and neural networks in…

    1 条评论
  • Meta AI's LCM: a good evolutionary step

    Meta AI's LCM: a good evolutionary step

    Meta's recent paper on Large Concept Models (LCMs) is being heralded as the next generation of AI technology. This is…

社区洞察

其他会员也浏览了