News Desk

As I look upon the enterprise landscape today, I cannot help but wonder if the enterprises are going to be all right. Every couple of years, enterprises have to face the onslaught of their vendors who bring in newly coined phrases, acronyms, and newly minted software platforms, along with the promise of ROI. In the latest onslaught, enterprises are facing terms such as SOA, Web services, BPM, and BAM.

The new buzzword is AJAX, or Asynchronous JavaScript And XML. The speed at which the IT industry coins terms and makes it fashionable to use them gives the cool name creators in the fashion and entertainment industries a run for their money. System integrators and consultants capitalize on the confusion and introduce new solutions and services that range from architecture blueprinting to specific product implementations. Enterprises turn to industry analysts to understand who is the leading vendor of the current hype cycle and eventually cave in to the trend and buy another piece of technology to add to the existing collection. During the course of my career, I have been in all of the camps: vendor, consultant, and system integrator, which enables me to provide some unique and original thoughts on how to save the enterprise architecture.

Understanding Architecture
Architecture is the most misunderstood, yet most widely used word today in IT. This is a word that has been borrowed by IT. This word has its origins from Greek around the 1500s when the related word, architect, meant a "master builder." Today, architecture, related to usage in IT, is used very loosely to denote the art and discipline of creating software, computers, systems, databases, information, and enterprises themselves.

In order to make the right decision, one has to understand all of the options. To make the right decisions pertaining to SOA, one has to understand what SOA is as well as the available options. Though SOA is looked upon as a technical term, in order to make the right decision, SOA has to encompass business as well. Even before the term SOA was coined, I had consulted on numerous occasions with large enterprises on their "enterprise architecture." Companies have always been interested in ensuring that their investments in technology, applications, and infrastructure materialize into tangible gains either in productivity and efficiency of operations, or a direct impact to top-line and bottom-line growth. SOA cannot be viewed myopically as only a technology term that impacts the technology architecture of an enterprise.

SOA needs to be divided into four layers and addressed holistically:

• Business architecture
• Functional architecture
• Technical architecture
• Infrastructure architecture

Figure 1 shows that SOA is the most generic (commodity) at the bottom layer and is very specific (unique) to a particular way of doing business at the top layer. Even though two companies may be in the same line of business, industry vertical, and may even have the same business model, the business architecture is very specific and is dependent on the people, business culture, company history, relationships, business processes, and the business characteristics among other things that cannot be duplicated exactly by another business. On the other hand, the lowest layer is the most generic where infrastructure could consist of mainframes, networks, routers, servers, etc. Although the configuration and implementation of the infrastructure elements could be different, the important point is that as one traverses down the SOA layers, one goes from specific to more generic.

An enterprise has to first identify its business problems and prioritize them. Subsequently, it must figure out the business process characteristics of the business problem and its impact on the business architecture and model that within the context of the business architecture. This is easier said than done.

With this new way to look at architecture in general and SOA in particular, an enterprise now needs to catalog the artifacts that reside in its layers in order to embark upon a successful SOA strategy. The artifacts run the entire gamut, containing business processes, application, services, technical components, documents, policies, infrastructure components such as servers, and anything else that represents enterprise knowledge.

SOA and ROI: A Business Problem?
The SOA vendors sell everything from soup to nuts that fits into the SOA layers. The main point that is harped upon is that SOA will allow enterprises to create and make available "services" that can be put together to provide application functionality. Vendors such as IBM maintain that modular components should be easily defined and manipulated along with dynamic definition of application and operations (see the first entry in the References section). The attractiveness lies in the fact that these services can be located through a registry and that the services can be reused in multiple areas.

The risk of having loosely coupled services that orchestrate business processes is that there is really no control over what is transpiring during process orchestration. BPM vendors realized this and provided products to design, visualize, and orchestrate business processes. However, that was not enough. The IT infrastructure and applications that supported the process orchestration were now loosely coupled and were represented as services. As such, vendors stepped in to manage applications and services and monitor business activities. The vendors that offered products in this area originally were specialized, from managing only infrastructure, servers, network etc. to managing only Web services or applications.

The problem with existing SOA solutions is that there is also no attempt to model the business problem. There is an attempt to model the processes (BPEL, BPMN). There is an attempt to model the software system (UML). Business Process Execution Language (BPEL) is a way to represent orchestration between two parties. Several vendors jointly submitted this standard to Oasis and the standard is at version 2.0 currently. Business Processing Modeling Notation (BPMN) is a way to represent workflow graphically. As such, BPMN complements BPEL. Neither BPEL nor BPMN provides a way to understand the business issues that may arise inherently from business process orchestration. They also do not provide a way to correlate disparate business-related events that occur as a consequence of process orchestration. There is no attempt to model the specific set of business issues. That is the gap in the current approach to SOA. It is currently being addressed from a purely technological angle with the technology decisions driving the business decisions. This is contrary to what one observes when analyzing SOA as a layered architecture. It is clear that the business architecture is the most specialized and must drive the rest of the architectural decisions. Forget the business-to-IT alignment in the enterprise: there is no business process-to-software systems alignment in the SOA model. Vendors such as Red Rabbit Software have bridged that gap with a business domain modeling studio.

A research field called Complex Event Processing (CEP) has been around for many years now Advances have been made in a related area called Business Event Processing (BEP). Alert readers will immediately notice the introduction of two new terms in keeping with the rapid pace of name generation in IT. BEP is related to CEP in that there is an attempt to relate events in time and space (causality) as they transpire during business process orchestration. There have been attempts to apply CEP to various problem areas, but the application almost always tries to work its way up from the technology layer and tries to bridge the occurrence of technical events to possible business causes. CEP is more applicable, as it stands today, to scientific and technical problems whereas Business Event Processing targets business domains, business pain points, and business models, as well as how to take a top-down approach from the business architecture and make an SOA strategy successful.

By utilizing BEP, an enterprise can first model a set of business events that relates to its business issues. These issues are encountered specifically within a business domain. For example, a consumer packaged goods company may have issues with its inventory levels and safety stock whereas an insurance company may have problems with the cycle time taken to process an insurance policy application. Once a business domain model has been created, it is mapped to the actual business functionality that supports the business processes. By utilizing the BEP platforms, it is now easier to enable only the impacted applications to conform to an SOA strategy while, at the same time, ensuring that the specific business issues that plague a particular domain are better understood. Visibility into the business problems will now be possible, all the way from the business architecture through the entire SOA stack.

In order to realize ROI from investment in SOA, an enterprise needs to clearly articulate its business issues and what is quantifiable and measurable with regard to the issues. Any SOA technology adoption should also include a platform that would help model business issues and then allow an enterprise to track the solution to the modeled issues. Also, there is no single solution to the SOA technology. SOA needs application servers, Enterprise Service Bus, Business Processing Modeling, and Business Event Processing in the technical architecture layer, and these technology components come from different vendors.

The challenge also is whether the newer technologies can work on top of existing technologies. An SOA strategy will take a few years to implement and the new technologies will have to work with the existing (and in most cases legacy and proprietary) technologies to ensure that it is "business as usual" in the enterprise while the architecture is undergoing transformation. Enterprises cannot afford to run a parallel IT department while waiting to convert their existing applications to SOA and then flip a switch to the new architecture. The real problem is that most of the existing SOA approaches take an "all or nothing" approach with respect to enterprises.