How is behavior altered? In his book “The Social Animal”, David Brooks notes that some experts have said people just need to be taught the long-term risks of bad behavior. Unfortunately, in the world of applications, this hasn’t been enough to transform behavior.
The understanding of the current state portfolio is much more important than any transformational strategy. Why? How can you begin to determine where you need to be (future state) if you don’t understand where you are (current state)? In addition, a sound knowledge of the complexity and gaps in support of the business will go a long way in determining what the strategy should be and where it should take you.
This is an extremely difficult task: “Telling people, who truly believe (and in many cases helped build it) in the portfolio and what it provides, that it will literally destroy their company if they don’t (immediately) begin transforming it?” Difficult indeed…
I’m NOT talking about the infrastructure (e.g. the ‘machines’, or whether they reside in the cloud or not. Nor the data, nor the connectivity, etc.). I’m talking about the applications themselves – those systems and pieces of software that your employees use to access knowledge and information that keeps your company alive and competitive.
Why is defining what an “application is” so difficult?
Today’s heterogeneous application environments defy simple definition. Applications tend to lack any truly useful or standard unit of measure. Today’s applications are a mix of massive, client / server, packaged, service-oriented architecture (SOA) services / web applications, etc. – no one definition seems to apply. For example, how do stored procedures and / or reusable components change a definition? Will SOA services erode the definition entirely by replacing silos with loosely coupled shared services? How should open-source be counted — as custom code, a partial-packaged application, or a service?
Firms that have spent excessive time debating the term “application” have likely lost track of their context or never properly defined it to begin with. Context – arguably an ugly word. Context depends on what you are doing — your objectives, goals, and perspectives.
Some contexts require a high degree of technical precision. Operations and change management that run / migrate applications to / from production require precise inventories of components making up each application. On the other hand, a developer may define an application by its source code, shared components, data, and /or integration.
Other contexts define applications by the technology base. Enterprise architects (EAs) may assemble a view of applications based on the technology used — database management systems, OS, and programming languages, for example. These usage-based views enable EAs to monitor the cumulative technology in use, ensure adherence to technical policies and standards, and making recommendations to retire obsolescence.
Still other contexts blur or ignore application boundaries. IT and business leaders may group applications together to approximate the resources that the business consume. Business process SMEs may ignore application boundaries entirely to focus on how future-state processes should flow regardless of the current-state applications. EAs may take a similarly intellectual view as they develop capability maps and future-state diagrams.
Where do I start?
Good question. Before we get into the nitty-gritty of defining an application, the basics apply to this endeavor:
- Calculate the investment
- Set priorities
- Determine a course of action and move ahead boldly
Just what is an application?
To start, you don’t need tedious planning sessions, you need one plan that will bring quick action. You simply get the definition right to create transparency and enable transformation. Start with a ‘working’ definition…
This working definition is used to narrow the focus – this first-scrub should significantly reduce the list of application ‘candidates’.
The first step then, is to apply a general application definition to these ‘candidates’. Ask, does it:
- Accomplish a specific task(s)?
- Aid the firm in performing business?
- Create, edit and/or store data?
- Require support and maintenance?
- Can upgrades be deployed separately?
If the answer is “yes” to all of the above questions, the definition moves to the second level of analysis. Step two refines the definition:
- Does it communicate with other systems?
- Does it have licensing, maintenance and / or support costs?
- Is it a system of record?
- Does it create, edit and / or store ‘enterprise’ data?
- Does it require manual process(es) to engage / interact with?
If the answer is “yes” to any of the above questions, the definition moves to level 3 of the analysis. The third, and final, step involves identifying application ‘buckets’:
- Does it ONLY support out-of-scope functional (OOS) areas? Yes, you determine what OOS is / isn’t
- Is it a non-business application? (IT & system apps for backup, security, help desk, testing, development apps & tools, data subscriptions, services, and unknown apps)
- Has it already been retired or replaced?
Based on your unique context, only the in-scope applications are inventoried and analyzed further. Transformation is not produced by neglect, denial, withdrawal, or bitterness. It only comes from extremely hard work tackling difficult problems.
But wait, how do I identify which of my applications are business applications? It’s called ‘tiering’. Until next time…
See you in the future…