There is no business out there that is not looking to quickly create or renovate business processes to meet changing market and business conditions. Size does not matter, nor does industry sector. There is virtually no one who doesn't have a problem with inflexible or dysfunctional systems and processes.

This is the central issue for IT, which has years of keeping systems running, while working with end users to create or renovate systems to meet business needs.

In the past, renovating and inventing systems to meet business needs has been approached through expensive application integrations and custom modifications. These efforts have been labor-intensive and have offered very little return on investment when it came to reuse or transformation of the end products into the next generation of business logic. SOA (services oriented architecture) has now gained a foothold in the marketplace as a methodology for transforming and reinventing the technology side of business processes.

This article discusses the SOA value proposition, new SOA approaches that are available to enterprises-and what it is going to take for enterprises to comprehensively deploy SOA.

The Business and Technology Implications of SOA

When SOA entered the IT vocabulary, its promise was an effective means of modularizing pieces of business logic that were common to many different business processes so that this logic could be "pluggable" and reusable in many of these diverse business processes. The end goals were economy of application development and consistency of business processes. Individual Web services developed through SOA could be linked together into end to end business processes-or they could just as easily be "decoupled," if the business process no longer needed them. Just as importantly, these services could be centrally managed, secured and administered by corporate IT.

The concept makes sense, but only if persons on staff had the wherewithal to understand both the business processes and the applications and IT infrastructure behind them so the common pieces of business logic could be identified and then objectized. This process of modularization could be pursued through either a top-down or a bottom-up breakdown of business processes and applications. In some cases, a particular business sequence or application was identified and the resulting approach combined both top-down and bottom-up analysis.

Regardless of the approach decided upon, an SOA project was only as successful as the committed efforts of its end business analysts and IT experts. Every corner of the business that a given process touches needed involvement at staff and managerial levels. From here, organizations were most successful if they selected a particular area of the business and piloted a process first, then refining it before it was placed into production.

The breakdown of business processes and applications into modules for purposes of reuse has been a staple of traditional application development for the past twenty years. What is new with SOA, however, is that functional modules at application and infrastructure levels are forever being split off from business processes and applications into a separate library of services that is common to many applications and business processes. These object modules must be separately managed, and they are invoked when needed and by whatever and whomever needs them. They must be carefully coded to standards to meet the demands of flexible reuse. In a very real sense, they become real time "integrators" of applications and business processes, because they only affect the connections and the integrations at the times that they are called into service.

Case Studies

Some significant project work has been accomplished with SOA, and two popular case studies are worth reviewing.

Miami-Dade County was one government agency that aggressively pursued SOA in the reinvention of its systems and business processes. Miami-Dade determined that a build-out of services oriented architecture in a multiple mainframe environment could revitalize existing investments in legacy code as it provided new applications that improved customer service levels.

The County first used Web services to open up the back end of its applications in the late nineties. Miami-Dade has continued to roll out applications that assist over one million people in the non-metropolitan areas surrounding Miami. With the County's SOA-driven system, its public customers gained direct access to systems through a Web-based self-service interface. County personnel also benefited. In one case, building inspectors were able to interface with the system via wireless communications from the field. The results speak for themselves. In building permits alone, Miami-Dade estimates that it has saved hundreds of thousands of dollars by allowing customers to apply for local government permits online.

Miami-Dade's move to SOA was as much a positioning for future benefits as it was a reinvention of the present. The County anticipates dramatic drops in application development costs due to the reuse of SOA services in many new applications. At the same time, business process consistency and quality levels will be higher, since the same components can be recombined and reused over and over again.

Miami-Dade is also planning a standardized access to its Property Tax Appraisal System, which is used by all of its 40+ departments. The move will eliminate the multiple interfaces that these different departments now have to the information. Also in the works is the County's Answer Center Project, which allows members of the public to call, fax, email or enter queries to the County over the Internet. Members of the public will use a single access point, and will not need to know that their queries and questions are internally being processed across a broad range of legacy systems-with the seamless integration power of SOA.

In a second example, Halifax Bank of Scotland's Intelligent Finance telephone-Internet bank adopted SOA to design and deploy an end to end banking system, coordinating the efforts of over 500 IT staff in 23 different vertical projects.

Intelligent Finance decided on an SOA direction because it felt that SOA was the best way to orchestrate side by side collaboration between IT and non-IT personnel in business process design. The goal was to define a set of central business services that were used repeatedly by business processes within the bank. Once defined and developed, these services were mapped into the IT infrastructure.

Intelligent Finance first defined the key functionality of its existing backend systems and created these as basic services. Together with outside consultants, bank staff then built a business process-oriented service layer in front of these basic services. This set of services became a kind of generic banking engine which in turn provided the library of services that were required for implementing the different business processes in the system.

One critical goal for the bank was to improve the customer experience, regardless of the channel through which a customer decided to interact with the bank. Accordingly, much of the service development effort went directly into identifying and "servicizing" those business process components that were central to key customer touch points in the Internet portal, the interactive voice response system and the call center.

What Intelligent Finance ultimately discovered during its process analysis was that three central business transactions were continuously common and in use in customer transactions-no matter which channels these transactions were processed through. The common business processes were the opening of accounts, service requests and product and service fulfillment. These three areas were componentized into SOA services. Intelligent Finance then linked these services into end to end business processes that could be called into action at appropriate points of customer transactions with the bank-regardless of channel.

The overall effort allowed Intelligent Finance to reinvent and to reuse proven legacy code and business rules. It also set the stage for future application development that would be faster and more economical.

Making the Case for More Economical SOA

Most companies see the value of adopting SOA and many are doing it-but there is still a barrier to entry when costs and expertise come into play. In some cases, vendors are starting to do something about this.

Manufacturing software vendors have joined together to design an open source middleware framework for SOA. The project is called "Synapse," and is intended to redefine the meaning of "loosely coupled" applications interoperability as it presently applies to SOA. If the interoperability approach that is proposed is accepted by the open source standards community, it could allow manufacturers to mix and match applications within a common format. This would potentially eliminate integration complications between factory floor and back office software.

There are also industry experts who feel that open source software and SOA will give organizations greater nimbleness, at reduced costs to develop and deploy. As one example, open source stacks like Apache's ActiveMQ can be used for messaging at far less cost than traditional MQ messaging.

LogicBlaze is building out new product offerings of open source SOA infrastructure that will be based on Apache licensed software, and JBoss has centered itself around the JBoss Enterprise Middleware System (JEMS) as an open source SOA market platform that is interoperable with HP, Novell and Unisys. The goal is more economical SOA development for organizations-although there are still some industry analysts who maintain that open source SOA could prove to be costlier than proprietary solutions. In either case, vendors are taking notice that enterprises want more economical options for SOA-and enterprises are carefully evaluating vendors before making the leap to either proprietary or open source SOA models.

Key Success Factors

SOA will continue to evolve to the marketplace, with a plethora of both proprietary and open solutions that organizations of assorted sizes and goals can choose from. Along the way, there is a set of best practice steps that help to assure success with SOA:

Both IT and non-IT managers need to understand the value proposition of SOA sufficiently so as to realize how it can be applied and how it can make a difference to the organization's ability to do business. Usually, it is IT that must ensure that this understanding happens.

SOA will not be hugely successful for an organization unless managers and staff from both IT and non-IT functions come together to break apart and define those central components of business processes that happen repeatedly-and that can be transformed into reusable services that many different business processes can invoke. Without this, SOA cannot succeed-and the organization will not gain business agility.

It is best to pilot an SOA implementation first. This allows both IT and non-IT personnel to gain experience that they can take to the next step.

Partner with vendors who can bring critical SOA experience and ongoing support to your company in any SOA effort.

NaSPA member Mary E. Shacklett is President of Transworld Data. She is listed in Who's Who Worldwide and in Who's Who in the Computer Industry.