Wouldn't it be great if enterprise IT systems could integrate as seamlessly as the human body? As we noted in our recent Information Builders Magazine article, SOAs have attracted a lot of attention for their promise to simplify systems integration by replacing proprietary adapters with links that leverage industry standards.

While the emergence of standards-based integration is certainly noteworthy, the fruition of SOAs will occur only if the functionality is designed so highly specialized tasks can be rolled up into services that deliver actual business value.

In our article, we described the human body as a good example for SOA designers to emulate. For instance, while the heart and lungs depend on one another, they do not make any assumptions on how the other operates or integrates. Instead, they are linked via a universal interface – the bloodstream. And they collaborate with other organs performing specialized tasks to make functions such as human thought, physical activity, or movement possible.

So what will it take for IT systems to integrate in such a healthy manner?

In a word: autonomy. As software applications are exposed as services, their services must be exposed so they can interact with any other system that complies with the same standards. The beauty of SOA is that you don't have to change the underlying application as long as you establish consistent service definitions that expose its functionality. However, those service definitions cannot assume anything about, or have any dependency on, other applications or services. For instance, you cannot assume the CRM system's definition of "customer" will match that of the financial system, or that its definition will remain the same as the vendor issues new releases.

In essence, you are exposing items that are, in effect, lowest common denominators that different systems can understand. Instead of exposing items such as "customer" or "order," you may have to get more specific and expose "find name and shipping address" or "get order number." And, instead of building a specialized interface that can only receive EDI or MQSeries messages, your service should make the interface more generic; translation to specific messaging formats can be performed by separate adapters that can easily be replaced.

By making base services so simple and generic, you are insulating your organization from changes in underlying applications. So, if you swap out your CRM system or conduct a major upgrade, the service definitions should remain intact. Conversely, if you enhance your customer order status service, adding FedEx or UPS shipment data to the information that you retrieve from SAP or Oracle, you can do so without specifying additional messaging formats or gateways.

However, although you've exposed services that are highly specialized, business users won't have the time or patience to navigate endless, detailed services menus. That's where the value of aggregation comes in – your team needs analysts or process architects who can see the forest through the trees, understanding which services should be combined to deliver the processes by which your organization thinks and breathes.

In everyday life, people can perform acts like picking up balls and throwing them without thinking about manipulating every bodily function involved. With SOAs, organizations should be able to do the same – aggregate and enhance value-added services without having to constantly go back and rethink all the physical connections.

While self-service reporting has proven to be one of the Web's success stories, getting it right requires attention to a few important details. For Henry Ford Community College (HFCC), the requirements included a system that was fast to implement, easy to use, and easy to integrate with existing back-end systems.

HFCC learned some of those lessons the hard way after discovering that its existing reporting system did not work effectively with the school's Oracle database. Although it is an educational institution, HFCC faced pressures familiar to any private sector enterprise: it had to compete with several area schools for students, and it didn't have unlimited resources to build and operate a reporting system.

Using WebFOCUS, the school was able to generate nearly a dozen key reports barely six weeks into the project. And, to keep operations simple, it was able to take advantage of the WebFOCUS ReportCaster feature to automate distribution of reports via e-mail. However, for reporting systems, the most important requirement is figuring out how to serve different sets of customers. Here, the school developed an intuitive, Web browser-based dashboard with standard reports for the majority of users, while providing a powerful ad hoc reporting environment for power users. To date, HFCC has well over 200 reports available. The program has been so successful that it has extended dashboard access to over 70 area firms as part of the college's Trade and Apprentice program, which combines classroom and on-the-job training. Eventually, it will add a full-service student portal as well.

Clearly, at HFCC, self-service reporting is not only helping the school manage operations, it is also helping to make it a far more attractive destination for students and a stronger partner for area businesses. Behind its success, HFCC had to get the ABCs of reporting correct.

Etta Levine is editorial director for Information Builders' Insights and editor in chief of Information Builders Magazine. To provide feedback go to www.informationbuilders.com/insightstalkback

If you received this message in error, or wish to unsubscribe from this newsletter, please send a blank e-mail to stopinsights@informationbuilders.com.

Information Builders, Two Penn Plaza, New York, NY 10121