For several years, software vendors have been creating development and infrastructure products for the latest IT architecture style - Service Oriented Architecture (SOA). Recognizing the immense value SOA can bring to IT, companies like BEA, IBM, and Microsoft have delivered products to help customers design and build SOA-based applications. These vendor-driven initiatives are beginning to sprout actual customer-developed applications that are built on the promise of SOA, such as better flexibility, agility and reuse.

In fact, enterprises of all sizes are increasingly using SOA concepts and technologies to create a new generation of mission-critical business applications, ranging from "simple" portals to incredibly complex and feature-rich integration applications. They're taking this approach in an effort to improve IT's ability to deliver business applications to the right employees, partners, and customers on-demand.

The reason? SOA applications have the potential to turn around many of the problems plaguing IT organizations today, including lack of interoperability, schedule delays, budget overruns, and an inability to respond quickly to "the business." SOA also provides easy tactical paths to create economies of scale for mergers, acquisitions, spinouts, spin-ins, and other unique organizational relationships.

Chances are you'll eventually be asked about your company's SOA strategy, if you haven't been asked already. The actual types of SOA implementations run the gamut of possibilities and should evolve in line with your organization's unique migration path for SOA. You could be building SOA applications already. Maybe you're in the early stages of selecting the specific applications, third-party service vendors, and/or products you'll need to build your first application. Or, you might already be leveraging a SOA environment and related technologies to create new applications.

Regardless of your particular situation, SOA has matured into more than just an architectural theory. It's a philosophy and an attitude that's revolutionizing the way business and IT work together. No matter where your organization stands today, one thing is for sure: if you're in IT, SOA environments will be part of your life.

SOA's main premise revolves around how application functions are designed, built, and deployed as they relate to the business processes they're supposed to serve. Each business application is broken down into discrete services. Rather than build a single application that contains all the necessary services, each particular service is built and deployed on its own, allowing massive reuse and flexibility as business needs expand and change. This allows the business applications themselves to remain relatively stable, while individual services can (and usually do) change as often as necessary to deal with business problems (such as acquiring a new division), and technology problems like adopting a new Identity Management model. Another benefit of SOA applications is that some of the services can be "bought" from third parties, either for internal deployment or on-demand runtime requests, rather than building each and every piece of the application.

So SOA isn't just vendor-neutral. It's also platform-neutral. To borrow a programming concept, an SOA environment is essentially an object-oriented design for business processes. Each service behaves like a "black box." The platform, technology and programming inside each particular service are hidden from service requesters (i.e., the rest of the application(s)). Black box engineering allows the greatest flexibility when designing large projects across multiple organizations. But black box application development and deployment always come at a price - the inability to monitor and manage application performance easily. Some experts have compared managing black box technologies to seeing inside a black hole.

Like middleware projects a decade ago, application performance management (APM) is a primary factor slowing SOA deployments down. So how can the industry move forward with its management solutions and realize the full potential of SOA?

Application Management History
The biggest problem with any monitoring project, from network or business performance to applications, is determining what to monitor. In application management, the issue of knowing what to monitor is harder because of the multiple levels of measurements. The business processes and transactions are the reason for an application's existence, but knowing them alone isn't enough. To achieve effective application management, it's critical to correlate the internal application components to the overlying processes and transactions. To understand the logistics issues associated with this, a look at APM history is relevant.

As enterprises first used Web technologies to make data and transactions available to end customers (or employees), the applications were fairly simple - accessing a piece of data or requesting approval for a credit card - and then presenting the resulting data to the customer through a browser. A complex process was simply made up of multiple individual Web pages, each one running a back-end application that performed a discrete function.

These applications were easy to monitor simply by exercising each Web page that made up a step with a synthetic user.

As the benefits of Web applications permeated businesses, the application server became the common tool. All the steps of the business logic could now be put into a single application, instead of creating one application for each page request or process step. The applications acted as integration hubs - bringing together the required back-end data and transaction requests into one place - and delivering the consolidated results to the requester.

This is where things got tricky. Java and Java Virtual Machines (JVMs) made it difficult to see what was happening at the point of integration. A set of solutions sprung up reporting on proprietary data inside the JVM, providing detailed information about the point of contact. While the ability to see that data was critical, the data itself proved to be both a commodity and a burden.

Having the data didn't solve the monitoring "problem" of deciding what to monitor. This became a larger issue as enterprises started dealing with more complex applications, quicker turns of application versions and the introduction of new technologies - such as portals - built around a Service Oriented Architecture.

Implementations typically required weeks of reverse engineering and involved professional services consultants, senior developers, and architects. The process du jour was Trial and Error, hoping to determine what application metrics correlated to the overlying processes - while simultaneously deciding on the right trade-off of having the appropriate data for triage versus keeping application overhead low. When another application came along, or a change occurred to the managed app, the exercise was repeated. While not efficient, the process could work for stable hub-like integration applications.

Recently, applications have become even more distributed - first with the introduction of integration platforms and now with increasing rollouts of Service Oriented Architecture application environments. The manual correlation exercise followed for the hub applications is no longer practical. In fact, managing SOA apps this way is literally impossible. There are too many integration points, transaction types, and relationships - the decision points revolve around millions of entities.

Let's look at an example in the service industry. A clearing house application that connects auto insurance companies with service providers (and vice versa) has a complex application running two different access applications on two different application server platforms, all connected by a set of more than 60 individual services. Each service runs as a separate application. While efficient in operational logistics, managing so many moving parts each its own complete system is a difficult proposition.

As a result, application management solutions have to catch up. The fact that they haven't has created a gating factor to widespread rollout of SOA applications. Because manual correlation is no longer possible, the only way to deal effectively with the problem is through automation - and the most effective way to insert automation into technology is through modeling.

Why Automation Through Modeling?
Automation solves several issues associated with SOA performance management, especially the age-old issue of figuring out what to actually monitor. The steps of APM can be described in three stages:

1)  Setup/Installation

• Installation and configuration of monitoring agents
• Creation of meaningful UI visualization

• Correlation of business processes to internal application components
• Root cause analysis

• Configuration of monitoring agents
• Correlation of application details to business processes

Modeling in setup and configuration lets the enterprise deploy managed applications faster and easier. Management tools with modeling have a programmatic representation of the application architecture, allowing the tool to find the correlation between the application components and the business processes. This, in turn, lets the tool intelligently select which pieces of the application to monitor.

Armed with both the correlation to business processes and the architecture, a modeling-based tool can also automatically create useful user interfaces around service level reporting, performance review, and root cause analysis.

The analysis step of APM has also traditionally been a manual exercise, especially in the data-centric tools focused on application servers. The typical steps these tool owners take when a problem occurs involve leveraging an expert (senior developer or architect) to interpret the mass of data the tool provides, hoping that the helpful data is actually available (i.e., it wasn't missed in the manual correlation process).

Modeling helps automate problem triage by starting with the architectural representation or application schematic. This allows quick diagnosis down the architectural path of a business transaction to isolate the root cause. An additional benefit is that once a problematic component is found, the application schematics let the triager determine all the impacted business processes, whether the application owners know about the problems or not.

Change management is an important issue in any application environment. In SOA, it's critical. Take the clearing house application example discussed above. With over 60 discrete applications, even if only one change is allowed per year for each service, that's at least one change a week. That's the minimum change to deal with. In reality, changes could be occurring daily. So manually adjusting to changes is not only inefficient, it's simply not possible in a scaled business environment.

Modeling lets change be dealt with by an APM solution automatically. First, in detecting that a change has occurred. Then in adjusting the correlation between the processes and the application components, deciding what to monitor - and delivering a new application schematic when necessary. Only through automation can APM tools catch up with the rest of SOA technology - and allow for complete use in production environments.

Looking Ahead
Service Oriented Architecture is a powerful concept. It allows IT organizations and their related business organizations to work more efficiently. SOA applications will be more prevalent and managing them will remain critical. There are specific steps organizations can take to make SOA management work for them:

1)  Make management a priority: Management shouldn't be an afterthought. Make sure that it's budgeted for when pulling together SOA projects - both in time and money.
2)  Make a new decision: Managing SOA is a new problem, one that deserves true evaluation. You might decide to use one of your existing APM vendors, but don't just write them in. SOA presents unique challenges that existing tools find difficult to solve.
3)  Start small: SOA is a change in philosophy that creates barriers to success. Don't add more by trying to run multiple applications out of the gate. Like other technology breakthroughs, your chances of success increase when dealing with a single problem.
4)  Assume nothing: Don't assume that what you deploy is architected and coded like you designed it. Get runtime information to help determine what the real architecture looks like.
5)  Communicate, communicate, communicate! Involve all of the key stakeholders and often. It's important for executives to see the value in the project, for line-of-business managers to see that their applications will run better, for IT management to see efficient operations, and for developers to see innovation. Keep them all in the loop from start to finish.

Any new use of technology will hit barriers, and SOA management is no different. But the tools do exist to help. Once the mystique is gone, and you know what to monitor, rolling out managed applications as needed will be much easier. So design away, and see how many different services you will have in your next application.