Service Oriented Architecture Field Guide for Executives

Kyle Gabhart, Bibhas Bhattacharya

• Publisher: Wiley
• Year: 2008
• Print ISBN: 9780470260913
• eBook ISBN: 9780470419564
• Edition: 1
• Topic: Business
• Subtopic: Business Strategy
• Index: Business

Service Oriented Architecture Field Guide for Executives is a fundamental breakthrough in the business and technology perspectives of service oriented architecture (SOA). A valuable resource to help you understand and realize the benefits of SOA in today's companies, this guide will show you how to plan, implement, and achieve SOA value. Use a prescriptive approach to help you clearly understand SOA and to determine its applications for your business. Applicable to all industries, technology platforms, and operating environments, this innovative book will provide you with essential strategies.

SECTION ONE :

WHAT IS SOA AND WHY SHOULD I CARE?

If you haven’t heard about service oriented architecture (SOA), then you have likely been living under a rock for the past several years (it is also very unlikely that you would purchase a book on the topic). There is a tremendous degree of hype, FUD (fear, uncertainty, and doubt), and misinformation floating around regarding SOA, service orientation in general, and what it really means for modern enterprises. This first part of the book is aimed at cutting through all of this and providing a solid foundation in SOA, its huge potential, and its inherent risks.

Chapter 1, “SOA Primer,” introduces and defines SOA, explains what it means to be service oriented, and describes how we evolved to this point. The chapter introduces the typical architectural layers that comprise an SOA enterprise solution and the key SOA infrastructure elements that are commonly found.

Chapter 2, “Business Process Management and SOA,” introduces and defines business process management (BPM), explains what it means to be process-centric, and describes how all of this relates to SOA. Alignment between IT and business through BPM is examined, along with the relationship between objects, services, and processes. Finally, process modeling is explored in great detail.

Chapter 3, “SOA Value Proposition,” identifies the four core SOA value propositions (reduced integration expense, increased asset reuse, business agility, reduced risk) as well as several emerging values (alignment, time to market, visibility, and modernization). These value propositions are then explored by looking at the two fictitious case studies used throughout this book.

Chapter 4, “Risks in SOA Adoption,” takes a raw and honest look at IT challenges and barriers to SOA success. Common SOA promises are examined, including business and IT alignment, process automation through SOA, service reuse, service composition like LEGO^® blocks, smoother integration through open standards, and improved business responsiveness. SOA has potential, but this chapter provides a very real look at the risks inherent within SOA.

CHAPTER I

SOA PRIMER

You awake to the familiar buzz of your alarm clock and stumble out of bed and into the bathroom. With a flick of a light switch you are blinded by the bathroom light (unless you have one of those fancy bathroom lights that gradually brightens to allow your eyes to adjust). Later you plug in your coffee grinder, grind some fresh beans, and then brew a steaming pot of coffee. Throughout your morning routine, you use electricity. You use as much or as little of it as you need and you do so with little regard for how much electricity you have consumed that day, week, or month. Some weeks or months, travel and work schedule may dictate less time at home (and less electricity consumption); other days or weeks, you may consume much more. Electricity is a service. It is available on-demand based on a predetermined fee structure and is delivered consistently based on industry standards and regulated infrastructure. Electricity, like other utilities, is service oriented.

FROM AD-HOC SOLUTIONS TO SERVICE ORIENTED CAPABILITIES

At first glance, service oriented architecture (SOA) sounds like a techie thing with little relevance to business and delivering customer value. But service orientation is more than just a technical architecture; it is a movement within government organizations and private industry that is transforming business value chains, organizational alignment, and technical delivery capabilities.

To better understand this transition, we will first examine the evolution within the electric utility industry from ad-hoc creation of electricity toward a true service oriented model. Then we will explore the parallels currently occurring within the realms of business and technology with respect to SOA.

Edison Had a Neat Idea

Generating electricity to illuminate a bulb is a pretty cool concept. The means of getting the electricity to the bulb has evolved over time. Creating that electricity via generators was a fine initial implementation, but that method was not as economical or reliable as desired. Generators required individuals and businesses to stockpile fuel in order to produce electricity. They also had limited ability to regulate the electricity flow, resulting in reliability problems as well as safety concerns. Later, the electricity needs of towns and cities were supported by power plants. Generation of power within homes and businesses gave way to transmission of power from centralized plants via electrical lines. Eventually, these plants connected with one another via a standardized power grid, enabling the exchange of power supply across great distances. Power demand could now be supplied by plants in other regions via the power grid. As demand changes, individual plants can throttle the supply of power, enabling the entire grid to respond to market needs.

There is another interesting aspect to the electric power industry, and that is the economics of deregulation. Although in some parts of the world electric service is owned or at least heavily regulated by the government, others have deregulated and embraced a free-market model. In these deregulated markets, private industry can build a plant, generate electricity, connect to the grid, and negotiate service levels and a price to sell this electricity to brokers. Industry standards, transmission protocols, and robust infrastructure enable a truly service oriented industry in which demand can wax and wane, supply can be delivered from anywhere on the grid, and new providers can enter the market and negotiate price and service level agreements (SLAs) as needed.

Service Orienting Modern Enterprises Is a Good Idea, Too

From localized generation of electricity to transmission of electricity from centralized power plants to distribution of electricity via a power grid, the electric utility industry has evolved into a service oriented model. As illustrated in Exhibit 1.1, this same evolution is taking place in modern enterprises today. Originally, businesses deployed local software (applications and databases) and hardware (personal computers and servers) to support business operations. Large, distributed businesses would require multiple instances of such software. Later, network infrastructure and distributed computing technologies allowed businesses to deploy centralized solutions (software and hardware) with distributed client-side access in lieu of multiple copies of the full software /hardware stack. These centralized solutions are much more economical and more powerful than having a bunch of solutions deployed in every location. The drawback, however, is that these solutions are not flexible. They offer a monolithic, one-size-fits-all solution. If you need to tweak one aspect of business operations (e.g., modify your supply chain process, change the data processing logic for one product type, outsource one component of the application, etc.), you generally have to go through a long design-development-testing-deployment life cycle. Service orientation is about taking those monolithic solutions and breaking them up into flexible, reusable, and configurable components. These components, or services, are available to service requests from anywhere in the network without the traditional barriers of operating system, programming language, or platform technology. Additionally, these can be reconfigured and a chain of services rearranged in a fraction of the time that traditional solutions can be changed in order to respond to changing business needs. To return to our electric utility industry analogy, service orientation allows enterprises to respond more readily to electricity demand (service requests) and to adjust power supplied by power plants (reconfigure service providers) to adjust to the demands of the grid (network).

EXHIBIT 1.1 As with the electric industry, the computing industry has evolved into a service oriented model

Finally, there is the issue of economics and deregulation. Just as a deregulated power industry permits new providers to join the grid and sell power to customers, so, too, does a service oriented enterprise model. The key in both cases is industry standards, transmission protocols, and robust infrastructure. By service orienting the enterprise, businesses introduce the potential to connect systems and databases within their internal enterprise and even connect to trusted partners and third-party service providers. Why maintain an address cleanup capability when you can simply invoke address services maintained by the U.S. Postal Service (or similar national postal service)? Why maintain your own geographical tracking and management capabilities when you can simply call services made available by Google Maps? Service orientation allows business needs to be fulfilled by any provider within the local or extended network, provided that they support the appropriate technology standards, message transmission protocols, and required SLAs. On-demand, service oriented capabilities, backed by service contracts and enforceable SLAs—imagine scaling your business, meeting increasing customer demands, and doing so as effortlessly as you turn on a light bulb.

WHAT EXACTLY IS SOA?

In exploring SOA, we will start by defining the concept and then look at some of the most common components that comprise SOA solutions.

Defining SOA

SOA can be expressed very simply:

SOA is about connecting customer requirements with enterprise capabilities, regardless of technology landscape or arbitrary organizational boundaries.

Digging in further, we learn that SOA means different things to different people. At a very low level, it is a technical architecture supported by standard formats and protocols. At a more general level, it represents a shift within the enterprise toward breaking up organizational silos and monolithic information systems to enable flexibility in how customer solutions are assembled. Chiefly, SOA aims to align technology investments and initiatives with business goals through an enterprise governance plan.

In some respects, the A in SOA is a bit unfortunate. While architecture is certainly a key aspect of any successful SOA initiative, it tends to give the erroneous impression that SOA is an “IT thing” that the business community need not worry about. The reality is that service orientation is an enterprise strategy with far-reaching implications into business capabilities, organization structure, technical infrastructure, and the overall agility and efficiency of enterprise operations. Consequently, a distinction will be made in this text between SOA (a style of enterprise architecture) and service orientation (an enterprise strategy that focuses on business processes, serving customers, and alignment of enterprise resources with business objectives).

DECONSTRUCTING SOA

No two service oriented enterprise architectures look the same. SOA is an architectural style with a handful of common elements and themes and myriad implementation strategies. A nominal, representative architecture can be identified in order to better understand SOA and “what it looks like.” A reference diagram depicting the SOA layers is illustrated in Exhibit 1.2. This diagram will serve as a useful reference in this section and throughout the rest of the book. While any given implementation of SOA may be more or less complex than this model, this diagram provides a good starting place.

The layers illustrated in Exhibit 1.2 are as follows:¹

• Operational resources. Comprised of existing systems, applications, and databases, the operational resources layer represents the legacy enterprise. Your customer relationship management (CRM), enterprise resource planning (ERP), and product life-cycle management (PLM) systems are good examples of operational resources. Some of these systems are commercial off-the-shelf (COTS), while others are homegrown, but all of them house valuable enterprise data and business logic. The services that are made availa...

Table of contents

• Title Page
• Copyright Page
• Dedication
• PREFACE
• Acknowledgements
• SECTION ONE : - WHAT IS SOA AND WHY SHOULD I CARE?
• SECTION TWO : - IS SOA RIGHT FOR MY BUSINESS?
• SECTION THREE: - HOW SHOULD I GO ABOUT ADOPTING SOA?
• APPENDIX - STANDARDS IN SOA
• INDEX