Book Image

SOA Governance

By : Todd Biske
Book Image

SOA Governance

By: Todd Biske

Overview of this book

Table of Contents (15 chapters)

What is SOA?


Before we delve into governance within the context of SOA, we first need to define what SOA is. The first step in this is to define what we mean by service. One of the many definitions provided by the Merriam-Webster dictionary (http://www.merriam-webster.com/) for service is a facility supplying some public demand. The key parts of this definition are facility which means that some capability or function is performed, supplying which means that the function is provided to consumers, and public demand which means it's something that one or more consumers actually want. A SOA, therefore, is quite simply, an architecture that utilizes the core concepts of service providers and service consumers to define a system.

Building on our example of a municipality, the community may initially have started as a collection of homes, each with their own well for water, garden for food, and so on. Over time, however, the residents realized the need for some common services. It may have begun with residents each contributing property for a common road that connects their houses. In other areas, it was likely focused on the economies of scale, such as a public school system, a shared source of water, sanitation services, and as technology evolved, communications and media services. As these services evolved, the impact on individual residents varied widely. Some residents had designed their homes in such a way that a transition from their private well to a public water source was an inexpensive effort. Other residents, however, had far greater expenses in adapting their internal plumbing to the fixtures required by the public source. The municipality can be viewed as a collection of these services, with the municipality acting as the provider of the services and its residents as the consumer of the services.

While this definition may seem simple, it captures the essence of what SOA is all about: breaking down a system into a collection of consumers and providers. The key to a successful SOA, however, is ensuring that the right services are provided and that the relationships between consumers and providers are formally established and managed. A city that has a complicated maze of pothole-laden roads, unreliable electricity, poor schools, high taxes, along with a city council that was appointed for life is not going to be a pleasant place to live. Are they providing services? Yes. Are they providing them well? No. Is the relationship between the constituents and city healthy, given that the council members are assured a paycheck for life, regardless of whether any improvements are made? Probably not.

Services in IT

If we compare this to the typical corporate IT department, individual applications are similar to the homesteads provided in a new community. Many of these applications are currently implementing capabilities in their own, private manner, even though there are many applications within the enterprise that implement the same capability. Some of these capabilities will be pure infrastructure, such as security and logging, but others will be business capabilities such as customer management and order processing.

Just as some of our homeowners had a higher cost associated with utilizing the public services, the same thing holds true in the world of corporate information technology. Many applications are hampered by an inflexible design such that the cost of change is now prohibitive. This shouldn't be considered a result of poor decisions taken years ago, but rather the normal course of growth. It is unlikely that all homeowners could have anticipated the changes that would happen over the years, and equally unlikely, if not more, that application designers could anticipate the technology advances that have occurred over the last twenty years.

One key difference between the typical corporate enterprise and typical community, however, is that all things in the enterprise exist for the good of the enterprise, and not as independent entities. When an individual homeowner chose to build in an inflexible manner, the only one impacted by this inflexibility was the homeowner. The community, as a whole, is likely not impacted by this. For the corporate enterprise, however, an inflexible application is another story. As long as that application is still necessary for the enterprise, the cost associated with that inflexibility will grow larger and larger. Just as a community can bulldoze a dilapidated property, an enterprise can choose to scrap an application and rewrite, but that comes at a large expense.

In order to prevent the continued cycle of inflexibility, an enterprise must move away from today's state where the information technology assets are largely viewed as a collection of individual applications and their data to a state where the assets are viewed as a collection of capabilities provided as services. This is a very important distinction, because many enterprises have simply taken existing applications, rewritten sections of them as services, and think that they're adopting SOA. When it comes down to it, however, they still have the same applications, and those applications still have the same integration challenges. For example, the typical enterprise has a collection of applications as shown in the following figure:

When the need arose for these applications to communicate, the generally accepted approach was to create an adapter that acts as the glue that connects the two applications. For each new pair of applications that need to be integrated, a new adapter would be created, adding more and more complexity over time.

To get out of this endless cycle of adding more and more adapters in the middle, which adds complexity, the enterprise needs to move away from application oriented architecture. Application oriented architecture is where the core unit used to describe the enterprise is an application. It therefore follows that SOA, simply stated, is an architecture whose core unit of composition is a service. If we take the diagrams above and eliminate the boundaries of the application, we get a picture that looks like the following:

When these boundaries are eliminated, the enterprise can now be viewed as a collection of service consumers and service providers that are expected to operate as a community. This is instead of being viewed as a collection of individual applications that have no clear indication of where capabilities are shared, and inconsistent internal structures that do not support future change or integration needs. User interface components and all business logic services are built in a consistent, composable manner, and all data resources are exposed in a consistent, composable manner as shown in the following figure:

This approach doesn't prevent individual services from being highly customized for a particular need. What it does do, however, is to ensure that we still build for agility. If the end result is that a particular business service only has one consumer, that's still okay.

Adopting SOA and moving away from application oriented architecture will allow information technology to lead the enterprise to progress into the future, rather than being perceived as the anchor holding the enterprise back.