Posted by Phil Murphy on April 28, 2010
So you need to formulate an application modernization decision -- what to do with a given application -- how do you begin that decision making process? In the past, modernization decisions were often simply declared -- "We are moving to this technology" -- for a number of reasons, such as, it:
- Keeps us current on technology.
- Provides a more acceptable user-interface or integration capability.
- Increases our exposure to access by external customers.
- Increases the volume of business transaction we can process.
- Trades custom/bespoke applications for standardized application packages such as ERP, payroll, human resources, etc.
Fast-forward to today -- you could simply go with your gut -- declare a solution based on what you currently know (or think you know) about the application in question. But it's a new day baby -- a proposal like that, without proper justification, is likely to be met with one of two responses from management:
- "Sure, go for it!" If this is the response you hear most often, then you have no apparent resource constraints, nothing holding you back and no requirement to justify the consumption of resources. If this sounds like you, you don't need to read any further, you're either living in a world without constraints, or you believe you live in a world without resource constraints and you will soon end up at point #2 when reality sinks its long fangs into your skin.
- "Are you joking?" If this is more like the response you expect to hear to your "declaration," welcome to the world where the rest of us live -- you may read on. Today, applications people hear a lot more pushback than in the earlier days -- management is more technically aware, and peppers us with probing questions. "On what information do you base this proposal? What are our other options? What if we do nothing? What makes this the top priority? Go back and do your homework!" We live in a world bounded by an excess of work, a dearth of resources, and the need to justify even moderate expenditures of resources.
So you now realize you need to assess your applications to build an information base that will both guide your decision and satisfy the probing questions of management. To keep things simple, let's focus on just one application. To answer some of the questions posed by management you'll have to assess the application's current state from many perspectives. In no particular sequence, the perspectives will include questions such as:
- Is the app fully functional or does it lack some fundamental features and capabilities?
- Is the app stable or does it frequently break?
- Why does it break -- is it built on faulty components or obsolete technology?
- Does it fail to perform well in times of peak business volumes?
- Is it built on obsolete technology? What is the net impact of that on the business? Cost? Risk? Complexity?
- What business function does it serve: is it unique to a business unit, or does it serve all / many departments?
- How important is that function to the business: is it core to the business' raison d'etre or is it a commodity function that may be satisfied by a package or even outsourced as a service?
- Business impact: what is the business impact of the outages?
- Approximately how many full time equivalent staff (FTEs) does the application consume over the course of a year?
- What are the processing, storage, and other technical costs?
- What share of level-1, 2, and level-3 support resources does it consume -- is this the most active application for the level-1 help desk?
Staff / Skills Issues
- Is it difficult to hire or retain people with the skills in this technology or business area?
- What's causing the difficulty -- high demand everywhere for the skills or low/waning supply of skills in a waning technology?
- Is the vendor in a financially unstable position?
- Are they squeezing customers with price hikes and inflexible negotiating stances?
- Have they monopolized a market -- are they one of only a few bad choices for support / products?
- Have they stopped investing research and development resources in the product?
While the list above isn't exhaustive, it shows how little most of us know about our applications. We haven't even noted the questions that arise when we begin to consider our modernization options -- questions like:
What are the available options?
- Does it need repair, replacement or something else?
- What are the costs and benefits of each option?
- What other applications have this issue, and should they be addressed as a group for economies of scale?
Going back to the categories of questions we asked to build an information set on which we may base modernization decisions -- what else would you add, subtract, highlight, or diminish in importance? What matters most when you're assessing the fitness and viability of your applications?
Related Forrester Research
- A Workable Application Modernization Framework Is Job No. 1 Now
- Justifying Application Modernization: Industry Analogies Explain Choices In A Business Context
- Application Modernization Taxonomy Clarifies Choices And Paves A Path For Progress
- Develop Metrics Thoughtfully To Streamline Application Portfolios Successfully
- The Application Management Continuum Offers CIOs A Contemporary Approach To Modernization
search forrester's blogs
- Anjali Yakkundi (11)
- Boris Evelson (124)
- China Martens (3)
- Claire Schooley (1)
- Clay Richardson (1)
- David Aponovich (13)
- Diego Lo Giudice (8)
- George Lawrie (10)
- Holger Kisker (36)
- James Staten (5)
- Jeffrey Hammond (22)
- John R. Rymer (43)
- Jost Hoppermann (26)
- Kate Leggett (91)
- Kurt Bittner (3)
- Kyle McNabb (12)
- Manish Bahl (2)
- Margo Visitacion (8)
- Mark Grannan (1)
- Martha Bennett (2)
- Michael Barnes (14)
- Michael Facemire (10)
- Mike Gilpin (39)
- Mike Gualtieri (94)
- Noel Yuhanna (8)
- Paul Hamerman (2)
- Phil Murphy (21)
- Randy Heffner (12)
- Stephen Powers (17)
- Tom Grant (35)
- William Band (53)