Application Modernization: Business Intelligence from Application Portfolios

posted by Peter Mollins at 1:18 PM Business rule mining is a critical way to capture intellectual property from existing applications. Harvesting business processes can accelerate the path toward reuse of the logic within a service-oriented architecture, in a business rule engine, or as development specifications. The challenge, however, is how to undertake business rule discovery.

Mannes Neuer, senior product manager at Relativity, has started an entry at Wikipedia that discusses the topic of business rule mining. Those in the industry that could contribute to the wiki to enhance the content may be interested in doing so.

A few related blog posts on the topic of business rule mining are here:

• Business context for business rule mining
• Business rules versus technical rules
• Why do business rules matter?

Labels: business rules

posted by Peter Mollins at 11:10 AM Tim Pacileo wrote an engaging piece on how to plan Application Modernization activities. In it he discusses a variety of factors that determine whether your initiative will succeed or not. There are two broad areas that should be emphasized:

• Justifying projects: He rightly cites this as being a key first step. That is, to choose projects that have the highest business impact. This is, of course, the purpose of business-centric Application Portfolio Management. APM collects measurements of the application portfolio in appropriate business contexts and helps managers to prioritize IT activities and investments based on their cost, value, and risk to the organization. This discussion on Application Portfolio Management is carried out in more detail here.

• Incremental approach: He also cites the need to take a step-by-step approach to modernization. That is to target your modernization activities, and use the gains from each activity to finance the next step. The rewards of increased efficiencies, agility, and liberated resources will propel the next phase of modernization. I go into more detail on Application Modernization and the modernization lifecycle here.

Labels: application portfolio management, application understanding

posted by Peter Mollins at 12:20 PM An interesting post on the importance of Portfolio Managementwas placed on ApplicationPortfolioManagement.com. It discusses linkages between Application Portfolio Management and Project Portfolio Management in light of Baseline's selection of Portfolio Management as a top priority for CIOs for 2009.

Labels: application portfolio management

posted by Peter Mollins at 12:06 PM Phil Murphy from Forrester published an interesting piece of research this month. The piece focuses on how to cut maintenance costs via tooling for the development team. Naturally, there is a great incentive to slash maintenance costs -- especially given the oft-sighted figure of 70% of budgets being devoted to maintenance. Obviously, your team will want to redirect these resources toward activities that are contributing to your bottom line -- like adding new functionality or application modernization.

The research piece is very comprehensive, covering many initiatives that IT can act on to save money. One in particular is worth investigating further. The piece discusses how dependency mapping can reduce costs, risks, and increase the responsiveness of the development team.

It is no secret that application portfolios have grown more difficult to manage. Increasing quantities of code, limited time for executing effectively, poorly applied standards and architectures, and diminishing documentation makes complexity a major issue. This complexity leads to slower response times for maintenance activities and a greater risk of disrupting business processes as changes are made to the application portfolio.

One way to confront this challenge is by understanding application dependencies. That is, determining what are the inputs into a given artifact and what are its outputs. So, a change to our identified element could have upstream and downstream repercussions that we must manage for.

Application Analyzer provides an ideal response to this challenge. It includes rich static analysis across diverse environments, allowing users to quickly understand impacts and dependencies between artifacts. But more than that, it allows you to investigate dependencies at different levels of abstraction. What does that mean? To simplify our understanding of application portfolios, it is helpful to understand them from different business perspectives.

For instance, let's say we are interested in simplifying our architecture due to the complexity that stems from our globally distributed development organization. We begin by abstracting our software based on how it is managed. So, artifacts that are managed by the same team are grouped together. This abstraction layer provides a summary of the various interdependencies.



We can then immediately see that there are too many dependencies between the software managed by India and Ireland. From a practical perspective, this means that each time India makes a change it may need to contact Ireland to avoid unexpected impacts. This could lead us to re-architect or modernize our application portfolio or reallocate assets so that we can minimize these cross-geography dependencies.

Labels: analysts, application maintenance

posted by Peter Mollins at 1:22 PM A prior post discussed the importance of placing software into its appropriate business context as an aid for business rule mining activities. But let's look at alternative usages for business contextualization. In this piece, I'll look at contextualization's use for application understanding the reality of complex application portfolios.

As mentioned before, business contextualization is the process of creating abstractions of complex application portfolios. Applications have become so complex (the class "spaghetti code" metaphor goes here) that it is nearly impossible for any human to understand their structure and behavior. To overcome this complexity, we need abstractions.

We can create abstractions of our software assets by overlaying metadata onto software assets. This metadata is typically a hierarchy of descriptions based on perspectives that your business uses to plan and think about itself. Such perspectives could be by business process, development organization, and security area.

So, for instance, an insurance company can think about its organization in terms of how it supports its various processes, like say claims processing. Under claims processing come a variety of sub-processes, like adjudication, provider management, claims routing, etc. Under each of these sub-processes are still more atomic processes. By mapping our preferred hierarchy -- or collection of hierarchies -- onto the software, we can start to understand its structure from a business perspective.

In the illustrations below, we can see how the Modernization Workbench enables this. In the first instance, we see a general diagram of a complex application portfolio. Understanding the dependencies between the various entities is just not possible.


In the second view, we can see how much simpler the view and the various interactions can be grasped. Here we see a business process abstraction has been placed onto the application portfolio. Dependencies between business processes can be immediately seen.


This has many different repercussions on our ability to understand the application portfolio:

• Knowledge Transfer: Helping new team members or outsourced teams to get up to speed is difficult when documentation is out of date and subject matter experts are difficult to access. The visualizations give a mechanism for users to quickly apprehend the application portfolio.

• Focus: Users will want to concentrate effort just on business processes, or projects, or security areas, etc. that are important for a given task. With abstractions, they can quickly identify relevant sources and focus on the right spot.

• Analytics: We often will want to query our application to uncover artifacts of interest with, say, impact analysis. These queries can be constrained to just the context we are interested in. So, a development manager can ask: show me all usages of 'customer ID' in the software that is supposed to be subject to higher security standards.

In coming posts we'll look in more detail at how contextualization can support all ranges of application portfolio management, application modernization, and application maintenance activities.

Labels: application understanding, contextualization

posted by Peter Mollins at 11:12 AM A very interesting piece on Application Portfolio Management was just published by Jim Duggan from Gartner. There is a more detailed post on the topic on the Application Portfolio Management resource site.

To summarize, it is imperative that you conduct APM from multiple business perspectives. That is, you should determine the bases on which you manage your business and hence your application portfolio. Is it by cost, business value, risk, business process, organization, or some combination? This will determine the kinds of information you need to collect for successful APM. More on providing perspectives on your application portfolio.

Labels: analysts, apm, application portfolio management

posted by Peter Mollins at 2:21 PM Discovering and managing the business logic that controls your core operations has clear business value. But a key question remains: how can I speed the process of uncovering and documenting business rules that are buried within millions of lines of code?

The key to effective business rule discovery is the concept of contextualization. By overlaying business-level groupings and related metadata onto your source code, you can dramatically accelerate business rule mining activities. And perhaps more importantly, doing so also leads to true business rules and not simply a collection of technical and system rules that have no meaning outside of the application portfolio.

Paths to overlaying context are discussed elsewhere. For the purpose of this discussion, let's look at the practical impact it has on business rule mining activities:

• Narrowing scope: Grouping your applications into abstractions provides a useful filter to focus business rule mining activities. You may wish to concentrate rules mining only on a business process that is targeted for modernization. Or, you may want to mine rules for documentation only for applications that are managed by a new service provider. Or, perhaps you want to mine rules to demonstrate compliance within a certain portion of your application that is subject to a certain set of regulations. Business Rule Manager can focus its discovery activities just on the relevant scope, eliminating irrelevant rules from your analysis.

• Enriching metadata: As you overlay contexts and business descriptors onto your applications, you are providing a common lexicon for developers and business analysts. So, technical names for variables take on real business meaning. This information can be readily transposed onto discovered rules, allowing analysts to quickly understand the discovered logic and document and validate true business rules more quickly.

Labels: business intelligence for applications, business rules