The New Management Architecture
A shift in management architecture is challenging enterprise architects. How should they change their approach?
by Vinu Sundaresan

Posted March 15, 2004

Mortgages R Us scheduled an upgrade and launch of a new funding application for internal and partner use. The change had to happen overnight during the cutover hours allowed by its partner service-level agreements. The IT department carefully planned to make the changes across all the application's components.

But the thorough planning and long work-hours did not help during the cutover because dependencies on one networking service were not considered. In fact, the networking service was not even evaluated because no one on the deployment team had visibility into this specific set of interdependencies. The result was that the new application was unavailable after the cutover, forcing an embarrassing rollback of the new online process and a delay in the business campaign, which affected the company's planned revenue targets.

The IT department failed the company and caused a business crisis by not fully understanding the application's dependencies across the network, systems, and application infrastructure tiers. The crisis could have been prevented by a management architecture that provided the foundation to manage applications and services with the information and tools necessary for IT operations to truly understand the complex structure and dependencies inherent in a modern application.

This scenario and others, such as long and complex troubleshooting of application degradations, happen far too often in today's IT environment. Why? Simply put, existing management architectures and approaches do not provide an effective means to manage applications deployed on modern n-tier component architectures such as Java 2 Platform, Enterprise Edition (J2EE) and .NET.

The Changing Nature of Business Applications
To better understand the management challenges associated with component architectures, let's step back and look at the changing nature of business applications and their architectures. Just about every aspect of software applications has changed (see Figure 1). The economics and benefits of new technological innovations—from the hardware and operating systems applications run on to their function in the business—have driven this march.

Everything from cheap microprocessor power and bandwidth to innovations such as reusable software components, Internet standard communications, universal Web clients, and more powerful Integrated Development Environments (IDEs) has created a world where applications can be built, deployed, and altered in a fraction of the time it used to take, yet with far greater impact on the business. Because of this, minimizing IT slowdowns and outages has become imperative.

Managing applications to deliver the availability businesses demand is reaching a crisis stage as enterprises grapple with the thousands of interdependent moving parts that comprise their new applications. Mainframe and client/server architectures have clear relationships between servers and applications, but component architecture is multilevel, multitier, and extremely complex and difficult to understand, let alone manage.

The Need For a New Approach
One CIO who leads a large business services company has been implementing component-based application technology for the past four years and has experienced a dramatic improvement in his ability to deliver business applications rapidly. But he has also seen a hundred-fold increase in the number of components required to deliver a single application.

Typical application architecture can include multiple database servers, clusters of Web servers and application servers, portal servers, client-identity servers, firewalls, load balancers, and of course tens or even hundreds of application software components such as Enterprise JavaBeans (EJBs) and servlets. Quickly, he realized that the design and implementation of a management capability into his enterprise architecture was mandatory, or the delivery of reliable services would be severely jeopardized.

Traditional management architecture and approaches focus on instrumenting, measuring, and monitoring traditional FCAPS (fault, configuration, accounting, performance, security) metrics at the component level. However, as this CIO quickly learned, just because each infrastructure tier and each component team reports three nines or more of availability, this measurement does not tell him anything about the business application's availability to his customers. Managing consistently and reliably available applications requires a new approach that builds on traditional component management architectures, yet provides an understanding of the top-down structure of business applications and their runtime configuration, cross-tier dependencies, and operational status.

This new application-centric management approach, based on a top-down view of applications, builds on current investments, leveraging the enterprise's resources and providing a new framework on which to measure and manage the true delivery of business applications and services (see Figure 2).

Realization that IT has become an integral part of an enterprise's strategy for growth has given rise to utility computing visions from the major datacenter vendors such as IBM (on-demand computing), Sun Microsystems (N1), and Hewlett-Packard (adaptive enterprise). These initiatives primarily address the system architecture aspects, and to some degree, the management instrumentation required for self-healing infrastructures. Unfortunately, these are, to a large extent, only visions and do not yet solve problems of managing the complexity inherent in distributed component-based applications. They do not provide the critical capability of automatically creating and maintaining an accurate and up-to-date view of how today's IT infrastructure delivers business applications.

Use Cross-Tier Topology Maps
Enterprise architecture has traditionally focused on software, process, and systems architecture, leaving management architecture to the operations groups. Today's management architecture must be designed into the enterprise architecture from the start and provide operational staffs with the capabilities they need to manage these new applications.

Such an application-centric configuration management approach results in a cross-tier view of how the infrastructure delivers business applications and services. It should provide operational personnel with cross-tier topology maps that speed troubleshooting, allow proactive change planning that minimizes change-related problems, and provide a framework on which to measure and deliver true application service levels to customers.

This topological approach is familiar in the context of managing telecom services. Network operations center (NOC) personnel managing mission-critical telecom services don't manage the network by technology type or by looking at nodes individually. They use a network topology map as the basis for monitoring, deployment planning, troubleshooting, or any such operations function.

Likewise, applications using component-based architectures form complex and large logical topologies, change frequently, and are much more heterogeneous and less standardized than telecom and IP physical networks. It is truly amazing that IT personnel keep business services and applications running on such complex logical topologies by managing individual technologies and components. This is undeniably nonscalable, inefficient, and error-prone.

An automated configuration management capability should discover all application components used in the enterprise, including Web servers, application servers, databases, process engines, and legacy applications; the hosts they run on, including Unix, Linux, and Windows platforms; and the entire supporting network infrastructure. In addition, the software must capture all the significant configuration attributes of these components; all their cross-tier, runtime dependencies; and a complete change history of these values.

An easy-to-use and sharable view, such as an application topology map (see Figure 3), should display this information. The maps become critical to time- and cost-effective change planning and troubleshooting. The topology maps provide the application context to understand, prioritize, and solve problems rapidly, as well as help you avoid the majority of them in the first place. In addition, other management applications such as IT governance and service-level management can reuse this information.

Because this approach necessitates a fundamental shift in orientation—from bottom-up, component-level management to a top-down, application-centric approach—it requires people, process, and products. This approach must be integrated with the software, process, and system architectures the enterprise uses; it cannot be left as an afterthought by multiple groups multiple times. Therefore, enterprise architects must take a leadership role in driving business excellence by planning and implementing an effective application management architecture integrated with their software, process, and systems.

Once management architecture takes its place in the forefront of enterprise architecture, IT groups—with enterprise architects leading the way—will provide the reliable delivery of business applications critical to business success.

About the Author
Vinu Sundaresan is cofounder and chief technology officer of Collation, a provider of application configuration management software, where he leads the company's technical staff and product strategy. Vinu is a member of the Enterprise Architect Advisory Board. Vinu has a long history of both operations and software development experience in enterprise and telecommunications systems. He welcomes your comments and questions; reach him at vinu@collation.com.