In its day the colossal Pharos lighthouse of Alexandria was one of the Seven Wonders of the World. When it fell in the fourteen century, the building blocks were reused by the Sultan of Egypt to build the Citadel at Qaitbey that still stands today. Waste not, want not.

Our modern concept of Service Oriented Architectures (SOAs) updates the ancient approach to recycling. The SOA technology framework enables the rapid implementation of business applications using reusable services or functions. It includes a methodology for finding and consuming these pre-fabricated services.

Yet if you want your SOA projects to display the same kind of longevity as the lighthouse at Alexandria, you can't simply start stacking together the blocks willy-nilly. Building a successful SOA can require just as much careful planning and process as any architectural project. Process frameworks such as ITIL can serve as a valuable blueprint to guide construction.

SOA & ITIL
While proven tools and technologies exist to facilitate the effective use of existing loosely coupled and interoperable services to implement composite applications, assuring the overall performance of the final product is another matter.

In building the Citadel at Qaitbey from the ruins of the lighthouse at Alexandria, the Sultan's craftsmen had to select blocks of stone with precisely the right dimensions while taking into account how centuries and earthquakes had affected the strength and durability of the stone.

The same holds true for developers of composite applications. The service level of the application is limited by the strength of the building blocks (e.g., the service level achievable by the worst-performing services available on the network). For maximum flexibility, services can even be accessed across the Web, making it virtually impossible for IT to characterize the performance profile of constituent services or control the numerous moving parts that can impact application delivery or performance.

Since the delivery of the service is abstracted from the business logic, data structure, or underlying computing platform, it is very difficult to:
• Quantitatively determine if the service level is tolerable for the end user or, at minimum, even meets the service level agreement (SLA)
• Quickly determine the existence and source of service delivery problems

These challenges are validated by a survey of 333 U.S. IT decision makers conducted by the global IT consultancy Ovum. The survey found that 27% of large enterprises and 17% of medium-sized companies have SOA deployed in some areas of their IT infrastructure.

However, satisfaction with the results is patchy at best, with almost one in five of the people surveyed indicating that adopting SOAs had created unexpected complexity. The problem is that traditional IT management processes and tools are not always up to the task of monitoring and managing SOA applications and that SOA deployments require as much support and investment in infrastructure management as they do in development and testing tools.

Ovum research director Gary Barnett even went so far as to claim that most SOA initiatives launched over the next three years will fail. The Ovum survey found a high correlation between a business's level of satisfaction with SOA and its commitment to managing IT as a set of services in accordance with the best practice approaches advocated by the IT Infrastructure Library (ITIL).

ITIL is a set of IT best practices initially published by the British Central Computer and Telecom Agency in 1987. The central theme of this library of books is that IT must be managed from a "service" perspective. (A word of caution. The IT "service" discussed in the seven ITIL books relates to the work IT professionals do while the "services" in SOA describe the computing functions performed by the application module.)

To deliver complex composite applications based on SOA effectively, IT must be process-focused as opposed to technology-focused. To be process-focused, IT should deliver repeatable, scalable, end-to-end functions like service delivery, service support, security management, and application management. IT should not be organized in technology or platform silos like desktop management, server administration, database management, network administration, and Windows development. Taking this holistic view lets IT address the needs of the consumers of IT services better and, more importantly, allow such services to be delivered more cost-effectively. Cost effectiveness is achieved by focusing on business needs or issues faced by the users of the applications. IT spending priorities should not center on technology-oriented silos that form impenetrable towers of Babel. SOA's goal is to effectively deliver business agility that extends beyond the efficient implementation of business applications to the effective deployment and production management of these applications. ITIL, on the other hand, focuses on delivering repeatable and scalable IT functions cost-effectively. The Ovum survey is clear in that, for SOA initiatives to be successful, infrastructure management requires as much investment as development and testing . To implement the ITIL concept, the process of infrastructure management should delivered in a holistic, end-to-end approach instead of the traditional silo approach. It's crucial that sufficient funding is allocated to implementing effective end-to-end infrastructure management of composite applications to assure the success of SOA deployment. With so much riding on the success of SOA and ITIL initiatives, funding for this crucial capability should be part of the corporation's SOA and ITIL initiatives and shouldn't be considered a discretionary spending item.

A common thread between SOA and ITIL is the assurance that business functions are delivered to the user at the appropriate service level. While SOA-based applications, especially those delivered via the Web, is complex by nature, ITIL guidelines offer a process-oriented way to monitor, report, and respond to service-level issues. A clearly defined process as stipulated by ITIL is needed to deal with SOA's complexity so that its benefits aren't neutralized by user dissatisfaction, lost business, and ineffective IT. Let's drill down into the process of assuring a successful SOA implementation:
• Monitor: There has to be a quantitative way to determine whether the SOA application is functioning correctly. In other words, "Is the right information delivered to the right user in the right time?" There are numerous QA techniques to assure that the right information is delivered. Furthermore, most organizations by now have the necessary security to assure that the right person is getting the information. Ensuring that the information is delivered at the right time is another matter especially for Web-based applications. Having the tools to monitor the application performance experienced by real users unobtrusively is an absolutely necessity because it is the (i) only way to accurately measure the user's real experience of composite applications for service-level restoration and reporting, and (ii) the key driver for making process or application improvements. For Web-based SOA applications, the starting point for such monitoring should be the end user's browser where the composite application truly "comes together" and transverses the entire database infrastructure . It's only at the browser that IT can identify whether an incident (as defined in ITIL's Service Support Module) has occurred that impacts user satisfaction. Other legacy techniques like network sniffing aren't sufficient for SOA application performance monitoring. Even though a sniffer can monitor end-to-end a packet's round-trip time for a particular network segment, it can't monitor all the critical infrastructure and application components of a composite application. The only viable approach is to monitor from the perspective of the real user at the browser for Web-based SOA applications.
• Report: There has to be a centralized, correlated view of the performance of all the infrastructure and application components involved in the delivery of the SOA-based applications. Since composite applications are (i) made up of services that are "black boxes" whose performance can't be controlled or tuned by the developers, (ii) run on infrastructure components that aren't entirely under the control of IT ops, and (iii) have different parts of a transaction served by different data centers or servers, it's important that the performance of each transaction is reported and correlated across all infrastructure tiers and application components. The legacy approach of monitoring and reporting on the performance of each technology silo - like network, server, database, etc. as a standalone unit - isn't sufficient to provide a comprehensive view of the performance of the SOA application. ITIL stresses the need for a common vocabulary across all IT processes. Such a centralized view of transactional performance based on real user experience of "consuming" real transactions offers a common view of application performance across different technology silos or IT functions. It's the only viable approach to determine the service level delivered by a SOA application.
• Respond: Assuming that IT has access to the centralized, correlated view of transactional performance, it's also critical that the performance data is presented in an actionable form so that ad hoc or trial-and-error approaches aren't needed to identify and respond to performance problems. In ITIL's Service Support Module , a problem is the cause of an incident that the browser-based monitoring capability discussed above identifies. Without actionable information, IT incident response teams will have to debate the likely cause of the incident using apples-to-oranges silo-based performance data and attempt to reproduce the problem instead of dealing with the problem and restoring the business function in the shortest amount of time. By analyzing the centralized, correlated transaction performance information, IT can also identify leading indicators of incidents so that they can be monitored and proactively reacted to before an incident impacts user satisfaction or business productivity. This type of information can also be used to improve service support efficiency as well as infrastructure and application performance improvements.