Sustainable Advantage Impediments – Why Applications Degrade
In my last blog, I discussed the power and characteristics of the Killer Application. Not every application needs to be a Killer App; in fact, most are not designed with that disruption in mind. Nonetheless, applications represent investments that were thought to be worthy of resource commitments at some point. Is it simply time’s passage that degrades applications? The answer is not a simple yes or no. For instance, every company needs a general ledger, and many other functions generally associated with ERP (Enterprise Resource Planning). The functions in these types of applications have been around for decades, are used every day and provide critical support for the organization. There is no question they need investment and support. Even so, these applications often degrade, and are marked for modernization, replacement or just plain retirement. If they were that important, were constantly invested in and were critical to the operations of the business how can they be marked for replacement? This question is so often asked and is so important to understanding sustainable advantage that I decided to take the issue head on.
Application Lifecycle Landscape
The diagram to the left has four quadrants with one value spectrum for each axis. Going from left to right is the perception of increasing Business Value, while going from bottom to top is the scale for increasing IT value. The upper right Strategic Quadrant is where a company would hope to find its killer apps, or at least applications that differentiate that company in the marketplace. The lower left quadrant is where apps that should be retired reside. The path is never straightforward as these next several diagrams will indicate. Finally there are 2 sub regions that are the source of both innovation and accelerated obsolescence, namely the Pilot and Restricted Zones. The bottom right is usually the starting point of Shadow IT generated apps that are often built to explore a new idea or market niche. Minimal investment is devoted to making the application robust and resilient, due to time to market pressures and the simple fact that no one knows if the market will be lucrative enough to justify the considerable investment to make it robust. The top left is often created or purchased by IT to solve specific development or operational problems, but over time is adopted in a viral way, often with mutations from the base tool. This proliferation has significant effects on operational complexity if the tools become embedded in the routine operational processes. It is not unusual for twenty or more simultaneous copies of such a tool to be active in a large organization creating skill, process and technical debt problems.
Application Lifecycle Journeys
All applications have a tendency to follow several potential paths across the quadrants in the application lifecycle landscape. There are several scenarios to this progression and understanding these lifecycle paths is a key to understanding how business and IT managers need to think about their current applications and how they construct or buy new ones. Here are two of the several scenarios to consider:
Overlapping Functionality Scenario
When a company views an application as strategic, efforts will be made to continue investment so that it stays in the top right quadrant. Despite this intent, there are reasons that will cause the application to degrade from that state.
M&A activity can cause functional overlap between several applications because each pre-merger company had the same functionality. This causes confusion or conflict over investment direction, often creating a situation where multiple redundant applications vie for investment attention. Then the application tends to drift toward the limited impact area. Both Business and IT value is lost because it takes more money, effort and complexity to get the same functionality. At this point a decision should be made about what to do because the market is still moving and time will not be kind to either application while management is on the fence. The grey diamond represents a choice; coming out of the right side is movement to add business value, likely by combining the best features of the overlapping applications, which can ultimately lead to resurgence into a strategic mode. Sadly, a more typical choice is to keep both applications and upgrade them technically. Over time their business value degrades as the cost of redundant investments prevent the applications from staying market-relevant. Eventually the technical debt becomes large as well until a final decision to retire the application is enforced.
Functional Additions Consistently Trump Technical Soundness Application Scenario
Business relevance is a two edged sword in an application’s destiny. Remaining market relevant for extended periods of time could cause a relevant application to become unstable, brittle and eventually force it into modernize stage. This happens when changes are made without regard to the application’s architectural underpinnings.
One journey to this dilemma is indicated by the black path on the lower right that emanates from the pilot box. This application was rushed into service to meet a market niche or need, and the design was brittle to begin with. If the application becomes too brittle, the inherent business value can be obscured, relegating it to the retirement quadrant. This is where the grey decision diamond needs to be invoked to see if the application can be salvaged. If not, it will head to the retirement quadrant. The red path depicts a strategic application where additional business value was so heavily emphasized that the application’s design became compromised. This scenario often happens because the first release is rushed and it could take the next several years to get it stabilized, especially if the application is released into a newly emerged market niche. This is particularly true if the application is client facing or revenue generating. The advancing degradation will force a decision point to determine whether the application can be saved from diving into irrelevance due to the burdens of technical debt.
The Technical Lessons Learned
There are several key takeaways to ponder from this analysis:
- An application’s functional and technical architecture are critical to its long term success in being relevant to the business. An application portfolio will undergo all the changes mentioned above and there needs to a conscious effort to manage this investment based upon business value.
- Architecture is often viewed as a long term bet, with payoffs that are hard to quantify. The advent of policy driven provisioning, elastic resources pools and other scaling techniques now associated with a movement to the cloud can change this perspective. Leveraging these capabilities can help an early mover application become more robust without the traditional heavy upfront investment.
- An application’s technical architecture would benefit from investing in a set of holistic virtualization capabilities that does not tie it to hardware, operating systems, data sources, or the mechanisms employed in distributed computing. This would allow the application to flex and change with demand. Early stage applications would benefit from these capabilities.
- An application’s architecture would benefit from collaborations that use self-describing messages, to enable the loosest coupling possible. When those messages can be idempotent (essentially possessing all of the necessary state required in completing a transaction), the application will scale much better, leveraging a wealth of scaling tactics.
- Finally, EMC’s professional services knows how to help any organization get started on evaluating their application portfolio and make recommendations to make an application portfolio more sustainable.