The Challenge of Boundary Identification

London is by far the largest city in Western Europe. Although the city’s boundaries can be defined in a number of different ways, the City of London is officially defined as The Square Mile at the heart of the financial district. However, others will define London by governing agencies, postal code, or the outer commuter belt, any of which can significantly expand the city’s boundaries.

There are visible parallels between London’s description and the definition of an application. London’s Square Mile was defined by a set of defensive walls, setting a physical boundary. But as the settlement expanded by growing organically and subsuming surrounding areas, the definition of the city similarly needed to expand and introduced a new kind of boundary: a logical boundary.

London’s logical boundary may be described as the “entities” that share a common local administration. Creating boundaries on a shared set of processes allows management of the city to determine resource requirements for the “entities” within their governance.

Much like the city identifying boundaries to efficiently allocate resources, IT departments must have a clear perspective on the boundaries of an application. This clarity will lead to effective management of the IT portfolio and better alignment between applications and business processes.

The Importance of Boundary Identification

The core business processes of today’s organizations are automated by sophisticated applications. But as these software assets mature, they tend to become increasingly complex. This complexity is compounded by a decline in technical and business understanding of how these assets automate business processes, making it increasingly difficult to adapt software assets to support changing business priorities.

The lack of adaptability leads to a growing misalignment between what an application does, or can do, and what the business requires. Gartner Research has revealed that addressing this misalignment continues to be the top priority of CIOs. Forrester also identified the need to modernize applications as the top software issue for CIOs in 2009.

It is imperative that CIOs can detect where these misalignments exist, measure the degree of misalignment to identify priorities, and execute modernization activities to boost alignment. These activities may involve outsourcing a non-core process to a third party, more efficiently maintaining an application, or perhaps disaggregating systems into a service-oriented architecture.

Understanding the Contents and Edges of Applications

Measurement and realignment activities are complicated by the lack of definition of what constitutes the application. Analysis can correctly identify dependencies between entities and uncover relationships that may be hidden from immediate view.

Without an understanding of the boundaries of an application and context of what business processes it enables, a CIO cannot intelligently measure and act on realignment activities. Measuring the business value of software assets, outsourcing business-critical systems, and initiating modernization activities will be ineffective without understanding the contents and edges of an application.

Amorphous Nature of Applications

Historically, applications were developed and deployed as silos, making the definition of an application’s boundary straightforward. After all, the silo was created to solve a particular business issue; hence, it generally had a defined logical boundary that matched its physical boundary.

Today, it is increasingly difficult to locate the edges of an application. The emergence of service-oriented architectures and large-scale integration between previously disparate silos complicates any effort to determine where one application ends and another begins.

Dependencies within an application further complicate definitions. For example, an insurer’s claims processing system contains a program that administers incoming claims. But the insurer has two different business processes for clearing claims: one for claims originating from large hospitals and institutions and another for claims coming from smaller doctors’ offices. As the dependencies mount, so do the difficulties in assigning boundaries to an application.

Discovering Physical Boundaries

The physical boundary of an application can be defined as a grouping of entities that interact only with each other and with other entities only via certain predefined interaction types (e.g., messaging via MQ or a Web service). Alternatively, a physical boundary can be interpreted by the set of people that maintain an application. This definition can be useful because it isolates what the IT team specifically maintains as well as helps identify where to “break off” the application.

Discovering physical boundaries can be achieved through static analysis of the source code, which can uncover transactions that are made and received. We then add entities from our portfolio into our application definition as we uncover how they interact with other entities already within our defined application. Applications and programs that had been included but are not called would be excluded during this process. Further, we would also exclude entities that interact with our application grouping via transaction types that we have chosen as boundary interactions.

Discovering Logical Boundaries

While the discovery of physical boundaries can be useful, the ultimate goal as a CIO is to increase alignment between IT assets and business processes. As a result, it is powerful to define the edges of applications by logically segmenting them based on their business purpose, geography, or other context that is meaningful. Much like Londoners share a common local government, applications can be defined as having a shared business process.

For instance, the insurer introduced earlier could establish a definition of an application broadly to include all entities that enable claims processing. This would include “adding a claim,” “editing a claim,” “verifying eligibility,” etc. There will be interaction points between our application and other entities. Therefore, there is a need to determine what is tagged as a part of the application, what is not, and what is shared with other application definitions.

For instance, eligibility verification commonly interacts with claims processing as well as the definition of the customer relationship management application. Boundary identification should be flexible enough to permit this sharing of entities. This discovery can allow the IT team to effectively rearrange the code to segment processes so that they are less tightly coupled.

This activity is commonly required when an organization looks to outsource or service enable a business process. By performing this logical segmentation, the IT department can measure the value and risk by associating software entities with the meaningful business processes that they enable and execute the decisions accordingly.
But modernization decisions can also be based on different ideas of an application’s boundaries. For instance, one system may be so dependent on another system that the first step would be to re-architect a system to improve its flexibility. This could also lead to adjustments in the boundaries of the application.

Logical boundary identification can also occur at a more micro-level by uncovering the boundaries of a particular sub-process within a portfolio in order to expose it as a service. Understanding the dependencies and connections of an application’s sub-processes enables the IT team to continue to measure and plan alignment
activities as the application matures.

Facilitation of Application Portfolio Management

Defining application boundaries has clear value for the measurement of cost, risk, and value in an application portfolio. After all, defining the set of sources that are being measured relates to productivity. For measurements like cyclomatic complexity and lines of code, there is an obvious connection much like geographers define London’s borders for the purpose of calculating its population. But for more sophisticated measurements, such as Function Point (FP) counting, defining boundaries and business context becomes essential.

More critically, by defining application boundaries based on logical concepts, managers can associate metrics with concepts that matter to them. For instance, the insurer may consider the uptime of the claims processing system to be a key performance indicator. The CIO could then filter measurements like complexity and architectural quality based on business process. This would allow him to monitor the health of the code that supports the claims processing function. He can then redirect resources to address technical issues before they become business risks.

These filtered measures enable the CIO to prioritize modernization activities. An executive can quickly see which portions of the application portfolio would make the best candidates for re-architecting, outsourcing, proactive maintenance, or other modernization activities.

Summary: London Calling

Application boundaries have grown increasingly difficult to describe as complexity has risen and understanding of these systems has declined. Yet, to measure where to invest resources and to act on needed realignment activities, CIOs must understand what is “within” an application and how it interfaces with other systems. By defining the physical and logical, or “business,” boundaries of an application, the CIO gains a defined grouping of software assets that can be measured and modernized as needed.

Just as a person may be a resident of the London conurbation or the locality of Croydon, the definition of residency matters. Planners for the county and city need to know the demographics and relationships between these citizens and the overarching ontologies in order to best allocate resources. The same need for a definition of boundaries holds true for applications and the CIOs that manage them.

by Peter Mollins, director of product marketing for Micro Focus. In this role, he focuses on the positioning of application understanding and portfolio management solutions. He previously has held numerous marketing roles at Togethersoft, iMediation, and Netscape.