Categories
Insights

The Third Way to Application Modernization

A new modernization approach combines new application development platforms with a fresh take on outsourcing, helping enterprises overcome inertia and finally bring their legacy applications into the modern age.

Application modernization is now a top-of-mind issue for virtually every enterprise IT executive.

However, as I discussed in the first blog of this four-part series, The Problem with Application Modernization, the lack of a reasonable means to execute modernization has led most organizations to put-off their modernization efforts.

The bill for this delay is now coming due.

Enterprise leaders must find a way to respond, or they will find themselves unable to compete as their legacy application architectures tie them down and leave them unresponsive to changing marketplace demands.

The challenges that led to the inertia in the first place, however, remain. The two traditional application modernization approaches still leave enterprise leaders between the proverbial rock and a hard place.

This dilemma has led many organizations to explore a third way of approaching the problem. This new modernization approach combines new application development platforms with a fresh take on outsourcing, which in combination, helps enterprises overcome modernization inertia and finally bring their legacy applications into the modern age.

The Modernization Dilemma

Enterprise executives have to make tough choices as they decide where to apply their stretched budgets and human resources. Every dollar and every hour is precious, and they understand that they must use them strategically or they will put their organization’s future — not to mention their own career — at risk.

When faced with the need to modernize their application stack, the starting point for most enterprise leaders is to have internal teams handle the job. After all, the core application architectures that often require modernization are typically some of the most mission-critical applications in the enterprise.

The fragility and intricacy of the legacy architectures demand in-depth knowledge and awareness of the organization — validating the need for the hands-on involvement of in-house resources. At the same time, however, that same fragility and intricacy results in massively intensive re-platforming and redesign efforts.

As a way to relieve the demand on their internal resources, many IT leaders look to outsourcing vendors to take on this resource-intensive initiative. The ability to hand-off the project and free-up their most valuable team members for other immediate needs is enticing.

The dense development nature of these types of modernization projects, however, often cause these efforts to fail. In some cases, outsourcers attempt to execute the modernization effort without the in-depth knowledge they require, resulting in costly overruns and delays as they go through the inevitable trial-and-error process that ensues.

In other cases, outsourcers will demand a considerable amount of time from internal development resources to get the in-depth knowledge they require to complete the modernization effort successfully. While this generally results in a better outcome, the demand on internal resources largely negates the benefit of outsourcing the project in the first place.

The Third Way to App Modernization

A new development approach is enabling a hybrid method of application modernization that offers IT leaders the best of both worlds and a way out of this dilemma: low-code development platforms.

Low-code development platforms, which we’ll explore in detail in the next blog post, enable development teams to rapidly develop, test, and deploy applications with little-to-no hand-coding. Instead, developers use declarative approaches in which they specify the constructs and actions of the desired application and let the development platform create or render it.

While low-code development platforms offer in-house development teams a way to speed and streamline development activities, they also provide something else: a way to change how they approach modernization.

Using open, standards-based low-code platforms, companies like WaveMaker are bringing the benefits of this new development approach together with teams of skilled developers to offer enterprises a third way to modernize their application stack.

The nature of low-code development platforms enable companies like WaveMaker to develop redesigned legacy applications for their enterprise clients more rapidly, reducing the time and cost typically associated with modernization efforts.

Moreover, because low-code development platforms allow for rapid prototyping and testing, outside developers can work more closely with in-house teams without creating a resource burden.

Also, because this interaction is less technical and focused on functionality rather than coding and interfaces, it can take place with business users or analysts rather than within in-house development teams — helping enterprise IT leaders strike the balance they require.

The Intellyx Take

Application modernization is a now-critical activity for enterprise organizations. Legacy application stacks will only become more fragile as time goes on. At the same time, these legacy applications are rapidly being pulled into modern workflows as enterprises find they must innovate up-and-down the stack.

Still, the combination of resource constraints, increasing demand, and few good options have made the modernization road a difficult one to navigate.

While there is no escaping the fact that enterprise leaders must be intimately involved with any modernization effort, they must also find a way to maximize its benefit while reducing the resource drain that it produces.

Combining low-code development platforms with outside teams of developers who can work with various enterprise teams — and leave in-house development teams unencumbered — may provide enterprise leaders the third option they need to find a pathway to modernization success.


Originally published by Charles Araujo in Intellyx BrainBlog

Copyright © Intellyx LLC. WaveMaker is an Intellyx client. Intellyx retains full editorial control over the content of this paper.

Categories
Enterprise Application Development

Looking at Microservices Through a Macro Lens

Good things come in small packages, and that’s true of microservices. Read on to get a solid overview of the benefits this architectural pattern brings with it.

Traditionally, enterprises relied on a unified model for designing a software application. Here, key capabilities for managing input/output processing, error-handling, and UI are packaged into one monolithic process. In such a structure, all the application components are interconnected and interdependent.

Such a structure, however, limited the scope for an application to expand and scale. This is when microservices came into the picture. Here, a single monolithic system is broken down into a set of smaller services, carrying out a functionality in a distributed manner. Its loosely coupled structure enabled enterprises to add or iterate any component of an application independently. This gave scope for scaling and expansion at a much faster rate.

The Many Benefits of Microservices

  • In this architecture, each service of an application runs in its own process and is independently deployable. If changes need to be made or new functionality needs to be added, a service can be pulled down, tweaked, and redeployed without affecting the application performance.
  • Microservice-based design makes it easier to identify bugs and repair them. The problem can be contained to that particular service and then deployed once fixed.
  • Microservices are language and technology agnostic. Each of the services can be developed using different programming languages and deployed in different environments. This makes the services flexible and can be scaled independently.
  • As small services require smaller codebase, it makes maintenance easier and faster. Developing an application takes weeks not years as the code is organized around business capabilities.
  • Another benefit of using microservices to modernize legacy applications is an increase in productivity for developers. In a modular architecture, small independent teams take ownership of their services and act within a well-defined context. This helps build a responsible and accountable DevOps culture.

Aiding Digital Transformation

Apart from providing agility to enterprises and making the architecture scalable, microservices enable DevOps automation with continuous delivery and deployment. This makes deployment processes swift and improves time to market. With continuous delivery, iterations can be carried out throughout the product lifecycle, resulting in better working software. Such flexibility is difficult to achieve with a monolithic architecture. More precisely, the very problem of cost and time can be overcome with microservices.

Taking a cue from this, Amazon migrated to microservices. In 2001, the Amazon retail website was developed based on a monolithic architecture. This slowed down development cycles and restricted their ability to innovate. Once they adopted the modular design, it dramatically improved their front-end development lifecycle. Thanks to a microservices continuous delivery process, Amazon can now make 50 million deployments a year.

It’s the same story with Walmart, where they could not handle 6 million page views per minute with their aging monolithic architecture. After embracing microservices in 2012, Walmart experienced 20-50% cost savings and conversions went up by 20% overnight.

It Is Not a Silver Bullet

With that said, it is not that microservices are without any drawbacks. Although breaking down an application into smaller components have its advantages, it also distributes the complexity of maintaining them. Things can get more complicated with multiple databases and transactions. To make it uncomplicated, microservices architecture relies on APIs to deliver services. APIs bring in the standardization of interfaces in the development process. Structured APIs behave in a manner that is bound to remain unaffected by the technology used underneath. While developing applications, developers can work on coding the core functionality of the application. Other third-party services provided by the application can be called through APIs, thereby reducing the development time.

In a microservices-based architecture, multiple micro apps interact with each other using APIs. The benefit of such a structure is that, if need be, only a part of the application can be scaled by adding more hardware resources. Unlike in a monolithic app structure, where the entire app has to be scaled.

With the increasing popularity of cloud computing, containerization, and APIs, microservices are becoming more reliable. This trend in code management and deployment is enabling companies to respond to shifting customer demands in a swift and agile manner. But, as with any modern technology, a genuine requirement needs to be identified first to reap its benefits.

Update: This blog post was also published in DZone.com

Categories
Insights

The Problem with Application Modernization

There are many demands and challenges surrounding application modernization, but new developments are opening up a new approach to addressing it, and it may help enterprises finally strike a balance between the need to develop new applications while modernizing their existing application stack.

Application modernization is now a top-of-mind issue for every IT leader — yet most organizations are doing little to actually modernize their application stack. Why?

On the one hand, there is tremendous pressure on IT leaders to move beyond the legacy application architectures of the past and create modern applications that will enable organizational agility, speed, and the ability to create the types of customer and employee experiences that drive competitive value.

Achieving this modernization, however, is more difficult than it sounds.

After years of belt-tightening, the modern enterprise IT organization is already running mean-and-lean and at-capacity, straining its ability to keep up with new demand — let alone modernize the in-production application stack.

These counterforces of increased demand and constrained resources, in combination with the complexity of legacy architectures, have left IT leaders struggling with how to approach application modernization.

In this four-part blog series, we will examine the demands and challenges surrounding application modernization, why new developments are opening up a new approach to addressing it, and how it may help enterprises finally strike the balance they need as they simultaneously develop new applications while modernizing their existing application stack.

The Need to Modernize

The term application modernization flows easily off the tongue. It’s almost fun to talk about. After all, what IT leader wouldn’t want to be seen as a force of modernization?

Because of the conflict between its innate appeal and the complex reality, however, far too many modernization efforts devolve into mere window dressing. An organization creates a snazzy new front-end to an old application or makes some modest changes to a legacy application, and they call it modernization.

But these types of faux modernization efforts belie the real issue that sits just beneath the surface: today’s increasingly fragile legacy application stacks are becoming an existential threat to the enterprise.

Throughout the industrial age, organizations created competitive value by optimizing their operational core — how they produced, delivered, and supported products or services in the market.

Today, however, enterprises must derive competitive value through the creation of exceptional customer and employee experiences. To do so, they must be able to rapidly and continually adapt their business processes and systems. Unfortunately, organizations built their legacy applications for operational optimization — not around creating these types of exceptional experiences and the adaptability they require. Thus, the need to modernize.

These legacy applications, however, have also grown increasingly complex and fragile as organizations have steadily added layers upon layers of additional functionality over time — making the needed modernization more difficult and risky.

The result of this complexity and fragility has been inertia as organizations have opted for inaction rather than choose either of the only apparent options available to them: a high-risk internal modernization effort using their already strapped resources or a high-cost outsourced modernization project.

A Dearth of Options

Inaction in the face of the business case for modernization seems counterintuitive. But enterprise leaders are between the proverbial rock and a hard spot.

They’ve had to choose between two unpleasant alternatives.

The first option has been to launch major modernization efforts using their internal resources. This approach typically involved a significant amount of time selecting new operational platforms for the new application, extensive planning exercises, and the allocation of large numbers of both management and development resources to the effort.

The most significant impact of these types of efforts, however, was the unavailability of internal resources for any other projects. In many cases, the mission-critical nature of the application caused the organization to go into near lock-down mode as they executed the project — creating a backlog of other growth-related initiatives.

As a result, many organizations turned to outsourcing partners to offload the work of modernization. While this approach has the benefit of freeing internal resources to remain focused on future-facing and growth-related projects, it is often a costly proposition.

Even if the cost wasn’t an issue, however, the biggest challenge with these types of outsourced modernization efforts was their high failure rate. By definition, outsourced development teams are unfamiliar with the intricate, inner-workings of an organization. When combined with the business-critical nature of the applications most likely to have their modernization efforts outsourced, the result was often a continuous stream of project delays, cost overruns, and outright failure to deliver a working replacement application.

The Intellyx Take

While some enterprises have been successful using either or both of the traditional modernization options, most have not.

Instead of realizing the benefits of modernizing, many organizations that embarked on these efforts found them to be big, expensive distractions that generated limited business value — at least in the short-term.

The challenge, of course, is that the modernization of the legacy application stack is a foundational activity. The costs of not modernizing — and, likewise, the benefits of doing so — are not always immediately visible to the organization.

The high risks combined with this lack of immediate value recognition have led many IT leaders to put-off their modernization efforts and instead remain focused on meeting new organizational demand. This has been a winning strategy for many IT leaders — at least for now.

The failure to modernize, however, is a bit like a big bill coming due. Organizations must find a way to address it — or find themselves locked-in and unable to compete as their legacy applications hang like an albatross around their necks.

The good news for IT and business leaders is that there is a new wave of modernization approaches that may finally offer organizations something beyond these two options. Rooted in new approaches to application development, this ‘third way’ may offers organizations a way to modernize without the risks and trade-offs of the past. In the remainder of this blog post series, we will explore this new approach, its implications, and how it may help enterprises finally find their balance. Stay tuned.


Originally published by Charles Araujo in Intellyx BrainBlog

Copyright © Intellyx LLC. WaveMaker is an Intellyx client. Intellyx retains full editorial control over the content of this paper.