Over the last four decades, software architectures have attempted to deal with increasing levels of software complexity. But the level of complexity continues to increase, and traditional architectures seem to be reaching the limit of their ability to deal with the problem. At the same time, traditional needs of IT organizations persist — the need to respond quickly to new requirements of the business, the need to continually reduce the cost of IT to the business, and the ability to absorb and integrate new business partners and new customer sets, to name a few.

As an industry, we have gone through multiple computing architectures designed to allow fully distributed processing, programming languages designed to run on any platform, greatly reducing implementation schedules, and a myriad of connectivity products designed to allow better and faster integration of applications. However, the complete solution continues to elude us.

Now, Service-Oriented Architectures (SOAs) are being promoted in the industry as the next evolutionary step in software architecture to help IT organizations meet their ever more complex set of challenges. Is the SOA concept real, though, and even if it can be outlined and described, can it really be implemented?

The promise of SOA is true — after all the hype has subsided and all the inflated expectations have returned to reality, you will find that a SOA, at least for now, is the best foundation upon which an IT organization can take its existing assets into the future as well as build its new application systems. This is the first in a series of articles intended to help you better understand the value of a SOA, and to develop a realistic plan for evaluating your current infrastructure and migrating it to a true service-oriented architecture.

For some time now, the existence of Web services technologies has stimulated the discussion of Services-Oriented Architectures. The discussion isn't a new one; the concept has been developing for more than a decade now, ever since CORBA extended the promise of integrating applications on disparate heterogeneous platforms. Problems integrating those applications have always arisen, often because so many different (and non-CORBA-compliant) object models became popular; thus many architects and engineers became so bogged down in solving technology problems that the promise of developing a more robust architecture that would allow simple, fast, and secure integration of systems and applications was lost.

The problems, however, persist, and become more complex every year. Basic business needs such as lowering costs, reducing cycle times, integration across the enterprise, B2B and B2C integration, greater ROI, creating an adaptive and responsive business model, and so on keep us looking for better solutions; but more and more, we are finding that "point solutions" won't solve the basic problem. The problem, in many cases, is the lack of a consistent architectural framework within which applications can be rapidly developed, integrated, and reused. More importantly, we need an architectural framework that allows the assembly of components and services for the rapid, and even dynamic, delivery of solutions.

Many papers have been written about why particular technologies such as Web services are good, but what is needed is an architectural view unconstrained by technology. Let's begin by considering some of the fundamental problems that underlie our search for a better foundation, for how these problems are addressed will determine the success or failure of the effort.

Page 2: The First Problem: Complexity