Enterprise SOA

Chapter FOUR. ESA Fundamentals: Learning to Think ESA

The preceding chapters provided an overview of ESA, along with a survey of ESA's business value and information on how a company can evolve toward ESA. While these chapters effectively set the context for a deeper discussion of ESA, more work remains. ESA is essentially a new way of thinking about how enterprise applications are constructed and how they are used to support a business. At almost every level, ESA reshapes traditional thinking, introduces new concepts, and sets forth a new paradigm for building IT to support the needs of modern businesses. This chapter will introduce and explain the ideas that are fundamental to the transformation of IT that ESA will achieve.

What is architecture and why is it important?

In essence, architecture is a contract that organizes the work of hundreds of thousands—or even millions—of people. It describes the structures used in the course of that work, which in the case of software refers to data and other abstract mechanisms that will have a certain responsibility and that will be connected in a standardized way.

Architecture makes these standard abstract mechanisms or components useful by clearly defining the relationships between them. Complex, unwieldy systems can be reduced to their essence—i.e., to these relationships—and it becomes possible to see which pieces of the system are the most important. It works both ways: if you are attempting to create a piece of software that fits into an existing architecture, you'll need to understand what that piece needs to do, how it will connect to other pieces, and what its relationship to the rest of the architecture will be.

Architecture also defines the life cycle of the components. Who builds them? How are they built? How are they used? How can they be improved, and, eventually, how will they be retired? In other words, how will an architecture come to life, and how long will it live? The answers lie in the details of an architecture's design at specification time, design time, and implementation time, all of which we will explain later in the book.

For now, the key thing to remember is that the architecture circumscribes the capabilities—and the limitations—of any component within it, which is why great care must be spent in crafting the architecture before creating any components. If done properly, everyone who participates in building a system atop the architecture will know—because of the relationships clearly defined by the contract—what they should be doing and how they should be doing it as they create each component.

The goal of any software architecture is to enable the construction of systems to execute some type of task in efficient and flexible ways. For the purposes of this book, the architecture we're focused on is the Enterprise Services Architecture, and the goal of ESA in particular is to enable businesses to use software in a manner that is both more flexible and less costly than any previous generation of software architecture.