SOA: It's a Mindset

Information Management Special Reports, October 2006

Omid Razavi

The Essence of SOA

Service-oriented architecture (SOA) has received a great deal of attention lately. Many companies are embarking on a SOA journey in order to migrate their IT systems to meet changing business requirements. So how can your organization plan for such a migration?

Because the only constant today is the need for continuous change, the ultimate end goal is that SOA will enable a company's IT systems to meet business requirements on an ongoing basis. In other words, rather than re-architecting systems and processes overnight, the whole premise underlying SOA is that its flexibility allows for incremental change as business requirements shift. SOA services are designed to interoperate with different development technologies, which make them flexible and reusable, and by creating an abstraction layer between business logic and business process layers, SOA enables businesses to focus on business processes rather than low-level application and integration issues.

This is a radical departure from how companies have traditionally approached IT. Typical IT infrastructure is designed for stability, whereas businesses demand agility. Although monolithic application suites may seem appealing in terms of initial cost efficiency, they will not offer the much-needed flexibility and agility that today's business environment demands. Point-to-point integration is initially simpler in many cases but is effectively unmanageable in the long run and suffers from exponentially increasing total costs of ownership (TCO) as progressively more connection points are added.

Consider that a typical $5 billion non-IT company might spend about 10 percent of its operational budget on IT, and out of which, approximately 20 percent on integration. This results in a $100 million annual expense on integration, with approximately $87 million being spent on upkeep of existing integration interfaces.

Shifting Mindsets

Those moving toward an SOA platform need first and foremost to adopt a different mindset and completely rethink the relationship between business and IT. With SOA, the function of IT moves from being a vertical silo to a more horizontal function that can support every facet of business activity. As such, companies can more rapidly create new applications as needed, thus reducing the expense of less-streamlined IT system upgrades.

Even given its inherent flexibility, SOA solutions need to be carefully designed, or architected. SOA development and implementation requires the use of a systematic approach, designed to be adaptable to both business and IT change over the mid to long term, yet also allows for pragmatic decision-making because some organizations need to achieve quick results and therefore delay a complete and detailed enterprise architecture analysis and design.

Systematic SOA

Companies migrating to an SOA platform are likely considering the move because traditional approaches to integration and business process management are simply no longer viable for several reasons. They are often rigid and expensive to support. A typical business process solution is not designed to take advantage of open standards, align IT infrastructure with constantly changing business processes or extend existing legacy systems. As a result, the rate of change in many organizations is dictated by what IT infrastructure is capable of, rather than what businesses need to accomplish. This creates a scenario where a business is unable to execute its strategic vision, and perhaps loses competitive advantage to agile rivals that are able to react to market threats and opportunities more quickly.

The systematic design approach to SOA fits well within an enterprise architecture framework, which helps companies to plan for the mid to long term, and at the same time better align business and IT. Within enterprise architecture, there are at least four layers of architecture:

• Business architecture,
• Process architecture,
• Information architecture, and
• Application architecture.

Each layer provides [system] requirements to the level beneath, and conversely, the goal of each layer is to provide all the required services to the layer above.

As a general rule, enterprise architecture analysis and design should always be driven from top to bottom. Specifically, this means that the first task is to identify the required business processes based on company's business goals. Within those business processes, business objects as well as operations on these Business Objects necessary to run the business processes are identified. This in turn defines how the highest-level services within the SOA will be recognized.

By extending the enterprise architecture analysis and design down to the next layer, the portfolio of applications can provide business logic and storage capacity for the Business Objects identified with the information architecture. However, in most situations, there are already many existing applications that cannot be simply ripped out.

Therefore, in all but green field situations, it is a good idea to conduct a degree of bottom-up analysis of the existing application portfolio and to identify which information services can be mapped to these existing applications. This combination of top-down and bottom-up design is sometimes referred to as the outside-in approach. Often, a separate layer of application-specific objects is also identified that may not have the exact same information structure as the Business Objects identified in the information architecture. Using an enterprise service bus (ESB), it is possible to wrap, combine and extend existing basic services in order to provide the required information services.

This systematic approach to SOA, based on the enterprise architecture approach, is an excellent way to achieve the benefits that SOA can bring to your company.

Pragmatic SOA

It is important that an SOA solution be designed in a systematic fashion. But, very few organizations today can afford to end up in a multi-year effort similar to the business process reengineering projects of the 1990s. The concept of "think big - act small" applies here.

There are various ways to scope out what is required and achieve quick results without going through a complete and detailed enterprise architecture analysis and design. One way to focus is to look at the most pressing business issue, for example, a key process that needs to be optimized or altered to ensure successful expansion of the organization. From there, only the affected business objects and applications need to be identified, reducing the total effort of the enterprise architecture analysis and design to a fraction of the effort required for a full analysis and design.

Page 1 of 2.