Service-Oriented Architecture

A Planning and Implementation Guide for Business and Technology

Eric A. Marks, Michael Bell

• Publisher: Wiley
• Year: 2008
• Print ISBN: 9780471768944
• eBook ISBN: 9780470447475
• Edition: 1
• Topic: Business
• Subtopic: Accounting
• Index: Business

Praise for Service-Oriented Architecture

"This book provides a superb overview of the SOA topic. Marks and Bell provide practical guidance across the entire SOA life cycle-from business imperatives and motivations to the post-deployment business and technical metrics to consider. With this book, Marks and Bell demonstrate a unique ability to take the complex dynamics of SOA, and through an eloquent set of metaphors, models, and principles, provide an understandable and insightful how-to manual for both technical and business executives. This will become a required handbook for any organization implementing SOA."
—Dan Bertrand, Enterprise Technology Officer & EDS Fellow, EDS Corporation

"A fundamental breakthrough in the business and technology perspectives of SOA-this book belongs in every software developer, architect, and IT executive library. Marks and Bell demonstrate a creative and practical approach to building complex, service-oriented systems. I especially liked the hands-on perspective brought to multiple aspects of SOA. A must-have guide in the technology turbulence of the future."
—Ariel Aloni, Chief Technology Officer, SunGard Data Management Solutions

"This outstanding text gets straight to the heart of the matter, cutting through the hyperbole and discussing how to drive real business value through SOA. It will certainly impact my behavior, our governance models, and, subsequently, the successful business outcomes we derive as we continue to embrace SOA. A must-read for battle-scarred SOA veterans and fledgling architects alike."
—Christopher Crowhurst, Vice President and Chief Architect, Thomson Learning

"Too often, SOA has been perceived as 'all about the technology'-standards, technology stacks, operational monitoring, and the like. In this book, Marks and Bell expand beyond the technology to provide a refreshing business-driven perspective to SOA, connecting the dots between business requirements, architecture, and development and operations, and overlaying these perspectives with tried-and-true governance techniques to keep SOA initiatives on track. A must-read for those leading the charge to adopt SOA within their enterprise."
—Brent Carlson, Chief Technology Officer, LogicLibrary and coauthor of San Francisco Design Patterns: Blueprints for Business Software

"Marks and Bell have captured a wealth of practical experience and lessons learned in what has become the hottest topic in software development. In this book, they explain in detail what works and what does not, from procedural issues to technical challenges. This book is an invaluable reference for organizations seeking the benefits of SOAs."
—Dr. Jeffrey S. Poulin, System Architect, Lockheed Martin and author of Measuring Software Reuse: Principles, Practices, and Economic Models

"One of the last things companies often consider when implementing a business solution such as SOA is the impact on people. Marks and Bell provide an in-depth look at 'what has to change' from a process standpoint to make any SOA implementation a success. A great read for those considering to embark on an enterprise SOA and looking for the right mix of people, process, and products."
—Alan Himler, Vice President of Product Management and Marketing, LogicLibrary

SOA is a complex topic and a complex organizational goal

Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology shows you how to plan, implement, and achieve SOA value through its prescriptive approach, joining the business and strategic perspective to the technical and architectural perspective.

Applicable to all industries, technology platforms, and operating environments, this innovative book provides you with the essential strategies to drive greater value from your SOA and realize your business goals.

CHAPTER 1
Introduction to the SOA Business Model

Service-oriented architecture (SOA) is a concept whose time has come. SOA is garnering great hype for such a simple concept, and we are here to tell you that SOA is more than hype. It is a concept with great promise for your information technology (IT) operations, for your business operations, and for your organization as a whole. We must remember, though, that SOA is a concept. Before we put our simple definition of SOA on the table, let’s discuss what SOA is not.

SOA is not a product. SOA is not a solution. SOA is not a technology. SOA cannot be reduced to vendors’ software products, much as they would like you to believe. SOA is not a quick fix for the IT complexity that has accumulated over 30-plus years. And finally, SOA does not address every IT challenge facing business and IT executives today. However, with proper planning and execution, SOA will deliver compelling business benefits to your organization in the short, medium, and long term. SOA is the right model for IT today, and for IT in the future. So, what is an SOA?

SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. “Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.

ELEMENTS OF AN SOA

An SOA has many moving parts, not the least of which is the enabling technology that makes it work. The following list represents the essential ingredients of a successful SOA. Each ingredient is explained in the sections that follow.

• Conceptual SOA vision
• Services
• Enabling technology
• SOA governance and policies
• SOA metrics
• Organizational and behavioral model

Conceptual SOA Vision

An SOA is a business concept, an idea or approach, of how IT functionality can be planned, designed, and delivered as modular business services to achieve specific business benefits. The conceptual SOA vision includes clearly defined business, IT and architectural goals, and a governance model and policies to help enforce standards and technical requirements of the SOA over time. This is the definition of an SOA target state, the goal to be achieved over time.

Services

Yes, an SOA needs services, which as we said, means all possible services in the organization. Along with services comes a services design model to assure reusability, interoperability, and integration across all business processes and technology platforms. Services are the central artifact of an SOA. Services are the primary architectural asset of an SOA. As such, they merit significant attention throughout this book and throughout an organization’s migration toward SOA through many projects and initiatives, each of which will most likely contribute services to the SOA over time.

Enabling Technology

While the technology of Web services and SOA generates lots of press, it is probably the easiest area to implement despite the vendor flux and standards volatility for various categories of technology solutions. The technology is essential to support realization of your SOA vision. However, the enabling technology is not your SOA. The enabling technology must be implemented to accomplish two objectives: (1) It must allow your services to operate reliably and securely in your enterprise in support of your stated business objectives; and (2) it must enable you to carry forward your existing IT architecture as well as enable your legacy systems to be leveraged to support your SOA goals. In many organizations, legacy mainframe systems and other applications are major contributors of services to an SOA.

SOA Governance and Policies

An SOA conceptual architecture cannot be realized unless it is communicated to the constituents of the SOA—business users, developers, architects, business and IT executives, and business analysts. In addition, communicating your SOA conceptual architecture to close trading partners is also advised. However, telling your SOA constituents what your conceptual architecture, vision, and goals are is one thing. Enforcing conformance to your SOA conceptual architecture, vision, and goals is another matter. SOA is not a big bang implementation model that we expect from large, packaged software applications. SOA is achieved incrementally through time at the project level by continuously defining and enforcing the standards that it will be based on. These standards are the policies that in the aggregate define your SOA conceptual architecture and, when implemented, help your organization achieve its SOA vision and business goals. An SOA governance model defines the various governance processes, organizational roles and responsibilities, standards and policies that must be adhered to in your SOA conceptual architecture.

Metrics

SOAs require a battery of metrics in order to measure the results you are achieving. These metrics include fine-grained metrics, such as service-level agreements (SLAs) for individual services, as well as usage metrics, policy conformance metrics, developer metrics, business and return on investment (ROI) metrics, and process metrics. Plan your metrics early, and don’t forget them when you go live with services. You’ll want the data, count on it.

Organizational and Behavioral Model

Your current IT architecture is the result of years of organizational behaviors, business decisions, and architectural choices. In order to achieve SOA, behavioral and organizational considerations must be understood and changed first; then over time will come gradual migration toward your SOA vision and goals. New organizational models and behavioral models will be essential to your SOA success.

SOA: BEHAVIOR AND CULTURE

SOAs contain a substantial amount of behavioral content because these initiatives are process-driven and span organizational boundaries. The “soft issues” of an SOA strategy must address the organizational issues and challenges that may help or inhibit SOA adoption, such as services ownership, the business and IT relationship, budgeting practices, and more. Organizational, cultural, and process issues thread through several facets of an SOA initiative. How do you organize your enterprise architecture functions and roles to support an SOA? How do you organize your developer resources to help ensure the realization of the goals and performance of your SOA initiative? What is the optimal IT structure for an SOA? Is centralized IT better? Or is a centralized enterprise architecture team optimal, supported by distributed developers embedded within specific business units? What are the skills, roles, and competencies of your architecture organization that will facilitate migration to and attainment of your SOA?

In addition, cultural and behavioral aspects are crucial to achieving SOA success. We will use a metaphor here. Imagine you’re an archaeologist. You’re examining the artifacts of a long-since decimated culture—the physical remains, artifacts, tools, cooking utensils, and so forth—to ultimately make inferences about the behaviors that caused these artifacts to be frozen in their earthen matrix in the way that you’ve discovered them. That’s what archaeologists do. They attempt to derive behavior from the physical remains and artifacts. Now, fast forward to your current IT architecture. It is comprised of legacy mainframes, distributed systems, desktop systems, software and documentation, user manuals, data models and schemas, which are all artifacts that resulted from the accumulated behaviors of your organization through time. These behaviors were a result of business and IT strategy and the various choices and decisions that caused your IT architecture to develop into its current state. So, if you plan to achieve SOA, you have to begin with behavioral, cultural, and other organizational factors that will lead to SOA success, and then architect your way toward SOA. You must enable and reinforce the behaviors that are more likely to result in the desired architectural outcome: SOA. If you start with enabling technology without changing behavior, years from now you’ll end up with another layer of technology that an IT archaeologist will have to interpret.

Exhibit 1.1 depicts these elements of an SOA according to our model. As you can see, the SOA strategy drives the governance model and policies. Services are at the center of the model because they are the central asset and organizing principle of an SOA. They are the key asset of an SOA. The enabling technology surrounds the services, within the framework of the SOA governance model and policies. The SOA governance model also drives the metrics, the SOA architecture process, and finally the behavior and culture that must be addressed to ultimately realize the business and technology benefits of SOA.

Although these elements represent the essential ingredients of an SOA, there is much more to it. What most organizations will find is that they need new ways of managing various business and IT processes to meet the demands of an SOA initiative. This book represents a collection of models required to implement SOA. But why is SOA such an important concept now, and why is there so much interest in it these days? Simple. SOA offers too many business and IT benefits for business executives to ignore. Competitive advantage is at stake with SOA. First movers will have it; SOA laggards will not.

EXHIBIT 1.1 Elements of an SOA

NEW SOA CONCEPTUAL, ARCHITECTURAL, AND ORGANIZATIONAL MODELS

SOA initiatives will stress and in most cases break current operational and architectural models of ...

Table of contents

• Cover
• Contents
• Title Page
• Copyright
• Acknowledgements
• Dedications
• Preface
• CHAPTER 1: INTRODUCTION TO THE SOA BUSINESS MODEL
• CHAPTER 2: GENERAL MODEL FOR SERVICES
• CHAPTER 3: SOA BUSINESS MODELING
• CHAPTER 4: SERVICES IDENTIFICATION, ANALYSIS, AND DESIGN
• CHAPTER 5: SOA TECHNOLOGY AND SERVICES INTEGRATION MODEL
• CHAPTER 6: FUNDAMENTALS OF SOA ASSET REUSE: SERVICE REUSABILITY MODEL
• CHAPTER 7: SOA GOVERNANCE, ORGANIZATION, AND BEHAVIOR
• CHAPTER 8: ARCHITECTURE ORGANIZATION MODEL
• CHAPTER 9: SOA BUSINESS CASE AND RETURN ON INVESTMENT MODEL
• INDEX
• WILEY END USER LICENSE AGREEMENT