Service Oriented Architecture (SOA) For Dummies E-Book

Judith S. Hurwitz

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 663

Veröffentlichungsjahr: 2009

Beschreibung

Feeling overwhelmed by the buzz about SOA--service oriented architecture? Take heart! Service Oriented Architecture For Dummies, 2nd Edition makes it easy to understand, plan, and implement the latest SOA solutions for your business. Whether you're the IT person responsible for developing SOA or the executive who's trying to get a handle on the concept, Service Oriented Architecture For Dummies, 2nd Edition will help you understand what SOA is, why it's important, and how you can make the most of it. You'll find out about the business and financial aspects of SOA, how to decide if you need it, and what it can mean to your bottom line. Discover how to: * Identify the main components of SOA and how they work to create business processes * Create reusable, flexible systems and avoid common pitfalls * Deconstruct business processes and applications to identify their components, then put them together in new ways * Construct SOA business applications for maximum adaptability * Confirm quality in a situation that's difficult to test, and assure the quality and consistency of your data * Develop a governance strategy for SOA based on your company's philosophy and culture * Work with XML and understand how it's used in SOA * Maximize the benefits of unified communications * Understand software ecosystems, rich interfaces, and the development lifecycle Packed with real-life case studies illustrating how SOA has been applied in a variety of industries, Service Oriented Architecture For Dummies, 2nd Edition demystifies one of today's hottest business tools.

Leseprobe

Service Oriented Architecture For Dummies®, 2nd Edition

Table of Contents

Introduction

About This Book

Foolish Assumptions

How This Book Is Organized

Part I: Getting Started with SOA

Part II: Introducing SOA Basics

Part III: Nitty-Gritty SOA

Part IV: SOA Sustenance

Part V: Real Life with SOA

Part VI: The Part of Tens

Icons Used in This Book

Where to Go from Here

Part I: Getting Started with SOA

Chapter 1: Getting to Know SOA

Business Lib

Tech Lib

A SOA Case Study

Better Living through Reuse

Moving in Tandem with SOA

Sweeping Unsightly Technology under the Rug

Understanding Why SOA Is Different

Chapter 2: Are You Ready for SOA? A Self Test

Question 1: Is Your Business Ecosystem Broad and Complex?

Question 2: Is Your Industry Changing Quickly?

Question 3: Do You Have Hidden Gems inside Your Software Applications?

Question 4: Are Your Software Systems Flexible?

Question 5: How Well Prepared Is Your Organization to Embrace Change?

Question 6: How Dependable Are the Services Provided by IT?

Question 7: Can Your Company’s Technology Support Corporate and IT Governance Standards?

Question 8: Do You Know Where Your Business Rules Are?

Question 9: Is Your Corporate Data Flexible, and Do You Trust Its Quality?

Question 10: Can You Connect Your Software Assets to Entities outside the Organization?

What’s Your Score?

Chapter 3: Making Sure SOA Happens

Overcoming Fears about SOA

Assuring a Better Quality of Service

Complying with Government Regulation

Educating Rita and Peter and Raul and Ginger

Choosing a Test Case Carefully

Revolutionizing IT to Work with SOA

Fostering Creativity, but with a Caveat

Banishing Blame and Working Together

Documenting and Marketing Your Successes

Planning for Success

Chapter 4: SOA Quick Start: Entry Points for Starting the SOA Journey

Mapping Your Organization’s Business Structure

Picking Your Initial SOA Targets to Gain Experience and Demonstrate Success

Preparing Your Organization for SOA

IT developers need a different approach

Business managers need to look beyond their own departments

Finding Out Why Business Partners Are Part of the SOA Success Story

Getting Help with SOA

Setting Off to the Races

Part II: Introducing SOA Basics

Chapter 5: Understanding Software Architecture

Defining a Service Oriented Architecture

Defining an Architecture

Basic architecture

Basic service

Business services

Elementary service oriented architecture

Understanding Four Problems That Complicate SOA

Complication #1: You have to keep the business logic and plumbing separate

Complication #2: You don’t start from scratch

Complication #3: Application logic creeps in to the business layer

Complication #4: Coordinating the components can be tricky

Why SOA? Better Business and Better IT

Chapter 6: Working with Software Components

Components and Component Wannabes

Understanding software components

Making sure your components play nicely together

Building in reusability

Web Services: The Early Days

When Web Services Grow Up

Defining Business Processes

Understanding a business process example

Seeing how business processes are like production lines

Creating New Applications from Old: Composite Applications

Moving toward end-to-end process

Adopting business processes and composite applications

Chapter 7: Discovering the Main Components of SOA

Making SOA Happen

Catching the Enterprise Service Bus

Welcome to the SOA Registry and Repository

Orchestrating End-to-End Services

Introducing the business process orchestration manager

Your friendly neighborhood service broker

The SOA service manager, again

Managing Business Process under SOA

BPM terminology

BPM tools

Application failures: Let us count the ways

Measuring service levels

End-to-end service

Taking just one more look at the Process Manager

Chapter 8: Playing Fast and Loose: Loose Coupling and Federation

Understanding Software Dependencies

Loose Coupling

Seeing Software as a Service

Licensing models and service

Software as a service and SOA

Implementing a Federated Software Structure

SOA and federation

Federated identity management

Federated information management

Discovering the Industrialization of Software

Chapter 9: The Collaborative Lifecycle of the Business Process

Fitting Enterprise Architecture with SOA

Managing Business Processes

A language called BPEL

Managing business processes: Orchestration and monitoring

The Dawn of Unified Communications

Figuring out why communications need unifying

Discovering the benefits of unified communications

Simple presence versus complex presence

Communications Enabled Business Processing

Making Unified Communications Dynamic

Web 2.0 and social networks

Web 2.0 and SOA: You complete me

Part III: Nitty-Gritty SOA

Chapter 10: (e)Xplaining XML

My Computer Is a Lousy Linguist

So what is XML exactly?

XML’s extensibility

How does XML work?

Discovering other technologies that work with XML

A Little Bit of SOAP (And WSDL)

Name spaces

SOAP comes in envelopes

REST

WSDL

Chapter 11: Dealing with Adapters

Making Connections

In a Bind: When Software Components Get Together

Getting to Know Your Adapter Options

Building an Adapter

Chapter 12: Discovering the Service Broker

Defining the Central Role of the Service Broker

Sitting Between Consumers and Providers

Seeing the Registry and Repository as the Broker’s Partners

Calling on the SOA registry

Collecting information for the repository

Brokering a Deal

Understanding the Service Broker’s Responsibilities

Chapter 13: The Enterprise Service Bus

Discovering ESB Basics

Finding Out What’s inside the Bus

ESB Services: Of Messages, Management, and Security

Messaging services

Management services

Interface services

Mediation services

Metadata services

Security services

Running the Enterprise Service Bus

No ESB is an island

The ESB keeps things loose

The ESB delivers predictability

Chapter 14: The SOA Service Manager

Getting to Know the Plumbing

Cutting the IT layer cake

Looking at the plumbing service

Grasping the Role of the SOA Service Manager

SOA service management: The inside view

Getting real

Part IV: SOA Sustenance

Chapter 15: SOA Governance

Understanding SOA Governance

Governing IT

Figuring out the SOA wrinkle in IT governance

Collaborating to Meet Business Goals Gained from Business Services

Chapter 16: SOA Security

Seeing How the User Fits in the Security Equation

Deciding What the User Can Do

Identity management software

Why identity management software works

Authenticating Software and Data

Software fingerprints

Digital certificates

Auditing and the Enterprise Service Bus

Chapter 17: Turning Data into Services

When Good Data Goes Bad: Getting Clean and Consistent Data

Discovering Dastardly Data Silos: An Example

Trust Me: Integrating Data Sources

Data profiling

Data quality

Data transformation

Data governance and auditing

Providing Information as a Service

Data control

Consistent data definitions

Ensuring quality of data

Data services

Data independence

Chapter 18: SOA Software Development

Building a Business Process Map

Exploring New SOA-Specific Software Development Tools

Defining the Software Development Life Cycle

BPM tools and software development

Mapping the business process

Combining SOA and the Rich Interfaces

The rich interface

Cloud computing

Discovering Mashups

Creating Software Ecosystems

Taming Mashups, Plugins, and Downloads

Chapter 19: The Registry and the Repository

Enabling the Reuse of Business Services

Combining Governance and Reuse

Understanding the Registry and the Repository

Introducing the Service Broker

“Signing” the Registry

All about the repository

Reuse of business services and SLAs

Working Together: Governance, the Repository, and the Registry

The repository and internal publishing

The registry and real-time governance

The registry and external publishing

Chapter 20: Put ting Qualit y into SOA

Grasping the Unexpected Challenges of SOA

Remembering the Good Old Days of Software Quality

Unit testing of Web Services

Integration testing

Stress testing and performance testing

Understanding Why SOA Quality Is Beyond Testing

The nature of SOA complicates testing

Virtual SOA testing

Part V: Real Life with SOA

Chapter 21: Financial Services

CIGNA

Business and IT collaboration

Why this approach works

Innoveo Solutions

Innoveo is born

Innoveo’s approach

Next steps

Jack Henry & Associates

The business problem

The SOA solution

Expanding opportunities for growth with SOA

Creating business services

Reaping the benefits of SOA

Chapter 2 2: Government

The Defense Intelligence Agency

PKI meets data composites

The next frontier: Collaboration

Hampshire County Council

SOA and information sharing

Eliminating boundaries

CommIT Enterprises

Applying semantics in a service oriented architecture

The impact of semantic models on building a SOA

The importance of context

SOA and ’Net-centric warfare

Chapter 23: Healthcare

AstraZeneca

AstraZeneca and SOA

Organizational backing for SOA

Going forward

Independence Blue Cross

Strategic SOA

Step 1: Governing SOA

Step 2: Application developers take a leap of faith

What’s next for IBC?

Lessons learned

Partners HealthCare

Decoupling the data from the application

Working with Partners

High Performance Medicine

Chapter 24: Hospitality and Travel

Gaylord Hotels

Standardization of the Property Management System

A new look at third-party hosted applications

What’s next for Gaylord hotels

InterContinental Hotels Group

Distributing key channel information

SOA implementation highlights

IHG’s SOA reference architecture: A self-healing ecosystem

Lessons learned in IHG’s journey to SOA

Chapter 25: Information Services

R.L. Polk & Co.

The business challenge

The IT challenge

Decoding a vehicle

Data as a service

Lessons learned after four years of SOA

Redlasso

How does Redlasso do it?

SOA, speed, and scale

Moving forward

Thomson Reuters

Finding a solution to improve agility and time to market

Business units gain control of business services with SOA

Working with the registry

A repository is added to the mix

The benefit of SOA

Chapter 26: Manufacturing and Distribution

Avnet

The gateway

Questions to think about before embarking on SOA

Cisco

Transforming to SOA

Changing the nature of partnerships with SOA

Chapter 27: Retail

Spotlight Pty Ltd.

Step 1: The point-of-sale system

Step 2: The ERP system and beyond

Choosing the right technology

Best practices for fast tracking SOA

The Carphone Warehouse PLC

Dealing with growth

Build or buy

Selecting reusable components

Dealing with organizational issues

Going forward

Virgin Entertainment Group

Turning data into services

Lessons learned

Chapter 28: Telecommunications

Bell Aliant

SOA and system interfaces

Selling the approach using ROI

What’s next?

Telenor Iris

The enterprise service bus

Scaling the service

What’s next?

Cadtel Systems

Part 1: A business process SOA approach

Part 2: How SOA helps to close the deal

Chapter 29: Utilities and Energy

Austin Energy

Picking the low-hanging fruit

Checking out SOA behind the scenes

Delaware Electric

Looking to IT to solve business problems

Getting some SOA help

Realizing the importance of business process

Part VI: The Part of Tens

Chapter 30: Ten Swell SOA Resources

Hurwitz & Associates

SOA Consortium

Finding OASIS

The Eclipse Foundation

SOA Modeling

The SOA Institute

Check Out the Vendors’ Sites

Some Cool SOA Blogs

Industry Groups Are Great Information Resources

Enterprise Architecture and Business Process Resources

Chapter 31: Ten SOA No-Nos

Don’t Boil the Ocean

Don’t Confuse SOA with an IT Initiative

Don’t Go It Alone

Don’t Think You’re Too Special

Don’t Neglect Governance

Don’t Forget about Business Process

Don’t Forget about Security

Don’t Apply SOA to Everything

Don’t Start from Scratch

Don’t Postpone SOA

Glossary

Service Oriented Architecture For Dummies®, 2nd Edition

by Judith Hurwitz, Robin Bloor, Marcia Kaufman, and Fern Halper

Service Oriented Architecture For Dummies®, 2nd Edition

Published byWiley Publishing, Inc.111 River StreetHoboken, NJ 07030-5774

www.wiley.com

Copyright © 2009 by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone]. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permissions.

Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services, please contact our Customer Care Department within the U.S. at 800-762-2974, outside the U.S. at 317-572-3993, or fax [phone].

For technical support, please visit www.wiley.com/techsupport.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Library of Congress Control Number: Library of Congress Control Number is available from the publisher.

ISBN: 9780470469941

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

About the Authors

Judith Hurwitz is a technology strategist and thought leader. She is the president of Hurwitz & Associates, a business technology strategy firm that helps companies gain business benefit from their technology investments. In 1992, she founded the Hurwitz Group, a technology research group. She has worked in various corporations, such as John Hancock, Apollo Computer, and Patricia Seybold’s Group. She has written numerous articles and white papers, and publishes a regular blog. Judith holds a BS and MS degrees from Boston University.

Judith provides strategic guidance to both vendors and customers of distributed technologies. Judith is a frequent keynote speaker at industry events. She was named a distinguished alumnus Boston University’s College of Arts & Sciences in 2005. She is also a recipient of the 2005 Massachusetts Technology Leadership Council award.

Robin Bloor, a Partner with Hurwitz & Associates, has been an IT consultant and technology analyst for almost 20 years. He lived and worked in the UK until 2002, founding the IT analysis company, Bloor Research, which published comparative technology reports that covered everything from computer hardware architectures to ecommerce. Prior to co-authoring this book, he was already a published author, having written the UK business best seller, The Electronic B@zaar: From the Silk Road to the E-Road (published by Nicholas Brealey Publishing), which analyzed and explained the field of ecommerce.

In 2002, Robin moved to the US and now resides in Austin, Texas. In 2005, he merged his US analyst company with Hurwitz and Associates and in 2006, he began to take an interest in the expanding area of SOA. Robin has become an influential and respected commentator on many corporate IT issues and is in great demand as a presenter at conferences, user groups, and seminars.

Marcia Kaufman, a founding Partner and chief operating officer of Hurwitz & Associates, has 20 years of experience in business strategy, industry research, service oriented architectures, software quality, information services, and analytics. In addition to publishing a regular technology blog, Marcia has written extensively on SOA, information management, and the business value of information technology. Marcia has worked on financial services industry modeling and forecasting in various research environments including Data Resources Inc. (DRI). She holds an AB from Connecticut College in mathematics and economics and an MBA from Boston University.

Dr. Fern Halper, a Partner at Hurwitz & Associates, has over 20 years of experience in data analysis, business analysis, and strategy development. Fern has published numerous articles on data mining and information technology. She has done extensive research, writing, and speaking on the topic of text analytics. She publishes a regular technology blog. Fern has held key positions at AT&T and Lucent Technologies. Fern spent eight years at Bell Laboratories leading the development of innovative approaches and systems to analyze marketing and operational data. She has also taught at both Colgate University and Bentley College. Fern received her BA from Colgate University and her PhD from Texas A&M University.

Dedication

Judith dedicates her part of the book to her family — her husband, Warren; her children, Sara and David; and her mother, Elaine. She also dedicates this book in memory of her father, David.

Robin dedicates his part of the book to Judy, for her encouragement, support, and advice.

Marcia dedicates her part of the book to her husband, Matthew; her daughters, Sara and Emily; and her parents, Larry and Gloria.

Fern dedicates her part of the book to her husband, Clay; and her daughters, Katie and Lindsay. She also dedicates this book in memory of her parents, Stanley and Phyllis.

Author’s Acknowledgments

We heartily thank our friends at Wiley, most especially Jean Nelson and Katie Feltman. Thank you to our development editor, Linda Morris. Our colleague at Hurwitz & Associates, Carol Caliendo, deserves our heartfelt thanks.

We learned a tremendous amount from all our interactions with IT executives who willingly and graciously shared their experience and knowledge about their SOA journey. We would like to acknowledge the following individuals:

AstraZeneca’s Mark Stocksdale; Austin Energy’s Andres Carvallo; Avnet’s Sean Valcamp; Bell Aliant’s Tony Lodge; The Carphone Warehouse’s Pawel Maszcyk and David Byrne; Cadtel Systems’ Bryan Rank; Cigna’s Brian Mitchell, Chad Roberts, and Tim Fitzgerald; Cisco’s Chris Wiborg, Paul Liesenberg, Guillermo Diaz Jr., Craig Hinkley, and David M. Gagliano; Delaware Electric’s Gary Cripps; U.S. Defense Intelligence Agency’s Steve Willet and Sean Kelly; Gaylord Entertainment’s Bill Glasgow; Hampshire County Council’s Jos Creese and former consultant Andy Holdup; Intercontinental Hotel Group’s Eric Norman and Bill Peer; Independence Blue Cross’s Thomas Cangelosi; Innoveo Solutions’ Nick Stefania and Didier Beck; Jack Henry & Associates’ Kevin Sligar and Debbie Wood; Partners HealthCare Systems’ Steve Flammini and Mary Finlay; RLP Technologies’ Norman Marks and Joe LaFeir; Redlasso’s Mark Thompson and Liquid Hub’s Tim Regovich; U.S. Department of Defense’s David Howard and CommIT Enterprises’ Cameron Hunt; Spotlight Pty Ltd’s Anne McDiarmid and KAZ-Group’s Victoria Redwood; State Street’s Jason Weisser, Debra Ciccerone, and David Saul; Telenor’s Magnus Bakken and Juan Carlos Lopez Calvet; The Hartford’s Ben Moreland; Thomson Reuters’ Vladimir Mitevski; and Virgin Entertainment Group’s Robert Fort.

Thank you to our friends representing many of the vendors, systems integrators, and industry associations in the SOA community:

IBM’s Debbie Cassie, Andy Warzecha, Paulson Lan, Janell Straach, Wayne Perry, Beverly Lowry, Virginia Agee, Valerie Jackson, Andrew Manby, Nicole Fortenberry, Mark-Thomas Schmidt, Greg Fleurry, Debbie Langenfeld, Patty Rowell, Sandy Berman, Fil Bowen, Doug Brown, Ambuj Goyal, Sandy Carter, John Simonds, Glenn Hintze, Sarita Torres, Sara Peck, Steve Mills, Robert LeBlanc, Michael Curry, Martha Leversuch; HP’s Tim Hall, David Gee, David Butler, Jean Kondo, Tom Hogan, Ann Livermore, Tiffany Tuel, and Ruth Busbee; Liquid Hub’s Tom Cozzolino; Progress Software’s Trip Kucera; Red Hat’s Pierre Frick and Sean White; Software AG’s Franco Castaldini; The SOA Consortium’s Richard Soley and Brenda Michelson; Thetus’ Philip Pridmore-Brown; Novell’s Ian Bruce; CA’s Al Nugent; Clarabridge’s Vanessa Stirling; LSH Communications’ Kathy Tebben; Pan Communications’ Erica Burns; and Waggener Edstrom Worldwide’s Lyn Oliver.

Publisher’s Acknowledgments

We’re proud of this book; please send us your comments through our online registration form located at http://dummies.custhelp.com. For other comments, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax [phone].

Some of the people who helped bring this book to market include the following:

Acquisitions and Editorial

Project Editors: Jean Nelson and Linda Morris

Senior Acquisitions Editor: Katie Feltman

Senior Copy Editor: Teresa Artman

Technical Editor: Susan Eustice

Editorial Manager: Kevin Kirschner

Media Development Project Manager: Laura Moss-Hollister

Media Development Assistant Project Manager: Jenny Swisher

Media Development Assistant Producers: Angela Denny, Josh Frank, Shawn Patrick, and Kit Malone

Editorial Assistant: Amanda Foxworth

Sr. Editorial Assistant: Cherie Case

Cartoons: Rich Tennant (www.the5thwave.com)

Composition Services

Project Coordinator: Patrick Redmond

Layout and Graphics: Samantha Allen, Melissa K. Jester, Sarah Phillipart

Proofreaders: John Greenough, Toni Settel,

Indexer: Broccoli Information Management

Special Help: Heidi Unger

Publishing and Editorial for Technology Dummies

Richard Swadley, Vice President and Executive Group Publisher

Andy Cummings, Vice President and Publisher

Mary Bednarek, Executive Acquisitions Director

Mary C. Corder, Editorial Director

Publishing for Consumer Dummies

Diane Graves Steele, Vice President and Publisher

Composition Services

Gerry Fahey, Vice President of Production Services

Debbie Stailey, Director of Composition Services

Introduction

Welcome to Service Oriented Architecture For Dummies, 2nd Edition. We are very excited that service oriented architecture (SOA) is starting to mature and move into the mainstream. Increasingly, we see SOA becoming not just a technology platform but a business platform. SOA is game changing, and SOA successes make it clear that SOA is here to stay. We hope this book is enough to ground you in SOA basics and to whet your appetite for the SOA adventure. We are also pleased that we can share more than 20 examples of how companies across nine vertical markets have used SOA as a way to improve business agility.

Service oriented architecture is more than a bunch of new software products strung together to allow technology companies to have something else to sell. SOA represents a dramatic change in the relationship between business and IT. SOA makes technology a true business enabler and empowers business and technology leaders alike.

The software industry has been on a journey toward a service oriented approach to software for more than 20 years. Smart people have known for a long time that if software can be created in such a way that it can be reused, life will be a lot better. If software can be designed to reflect how business operates, business and technology can align themselves for success. Finding good ways to reuse the years of investment in software means money spent wisely. These issues are at the heart of SOA and are among the reasons we think this book is so important.

SOA isn’t a quick fix: It’s a journey — and a very rewarding adventure. It’s an approach built on industry standards, with large doses of forethought and planning. It is indeed a journey. We hope this book inspires you and helps you get started.

About This Book

Service oriented architecture is a big new area and frequires that a lot of people familiarize themselves with it in a relatively short period of time. That’s why we wrote this book. Some people may want to get deeper into the technological details, while others may care only about the business implications.

We recommend that you read the chapters in Part II, regardless of how deeply or shallowly you want to wander into the SOA pool. The information therein will help ground you in basic SOA concepts and prepare you for intelligent conversations about the subject. We also recommend that everyone read the case studies in Part V, because seeing how real people put SOA to work is probably the best way to get a handle on what’s in it for you.

You can certainly read this book from cover to cover (if you’re that kind of person), but in true For Dummies style, chapters are self contained, so you can go straight to the topics that interest you most. Wherever you start, we wish you well.

Foolish Assumptions

Try as we might to be all things to all people, when it came to writing this book, we had to pick who we thought would be most interested in Service Oriented Architectures For Dummies, 2nd Edition. Here’s who we think you are:

You’re smart. You’re no dummy, yet the topic of service oriented architecture gives you an uneasy feeling. You can’t quite get your head around it, and if pressed for a definition, you might try to change the subject.

You’re a businessperson who wants little or nothing to do with technology, but you live in the 21st century and find that you can’t escape it. Everybody around is saying “SOA this” and “SOA that,” so you think you better find out what they’re talking about.

Alternatively, you’re an IT person who knows a heck of a lot about technology, but this SOA stuff is new, and everybody says it’s something different. Once and for all, you want the whole picture.

Whoever you are, welcome. We’re here to help.

How This Book Is Organized

We divide our book into six parts for easy consumption of SOA topics. Feel free to skip about.

Part I: Getting Started with SOA

In this part, we introduce you to the basic concepts of SOA, and then give you some pointers on how to get started. This part also includes a test you can use to help determine if you’re ready for SOA.

Part II: Introducing SOA Basics

In this part, we introduce you to the major concepts and components so that you can hold your own in any meaningful conversation about SOA.

Part III: Nitty-Gritty SOA

Some folks are more technically oriented than others. In this part, we dive deeper into the actual SOA architecture components. The material in these chapters is groundbreaking. We’ve done the research and put into print concepts that the software industry has been struggling to articulate for the past few years. At this point, you won’t find this material anywhere else in print.

Part IV: SOA Sustenance

Creating a SOA is one thing. Keeping it up and running, growing, adapting, and supporting business requires a lot more. This part delves into areas critical to SOA’s longevity.

Part V: Real Life with SOA

SOA is real. Real businesses are using it today to great advantage. This part shares stories that come to us from 24 companies actively helping organizations put SOA into practice. These companies represent nine different vertical markets. We interviewed people from each of the projects we describe. You can take their word for it. SOA rules!

Part VI: The Part of Tens

If you’re new to the For Dummies treasure trove, you’re no doubt unfamiliar with The Part of Tens. In this part, Wiley editors torture For Dummies authors into creating useful bits of information easily accessible in lists containing ten (more or less) elucidating elements. We started these chapters kicking and screaming but are ultimately very glad they’re here. We think you’ll be, too.

After The Part of Tens chapters, we provide a glossary. We try diligently to define terms as we go along, but we think having a handy-dandy reference is very useful.

Icons Used in This Book

Like all For Dummies books, this book makes use of icons in the margin. These icons help draw attention to paragraphs that we think you need to pay attention to, or in some cases, paragraphs that you can skip over.

We use this icon to highlight a paragraph that contains a particularly useful point that you’ll be wise to pay attention to.

Watch out and pay attention when you see this icon. The bother you save may be your own.

This icon points out a reminder or a point you’ll want to stow away in your long-term memory. You may be sorry if this little tidbit slips your mind.

When we get into details that are highly technical or even geeky, we let you know with this icon. We hope these tidbits will augment the understanding for the more technically inclined. Those with sensitive stomachs can gleefully ignore these icons.

Where to Go from Here

We created an overview of SOA and introduce you to all its significant components. Many chapters here could be expanded into full-length books of their own. SOA and the entire distributed technology landscape is a big focus for us at Hurwitz & Associates, and we invite you to visit our site and read our blogs and insights at www.hurwitz.com.

Part I

Getting Started with SOA

In this part . . .

Starting a SOA journey might seem daunting. But, as the sages say, “A journey of a thousand miles begins with a single step.” In this part, we help you take that first step by showing you some great places to start your SOA journey and some great ways to do it.

Chapter 1

Getting to Know SOA

In This Chapter

Finding out why you should care about SOA

Liberating business from the constraints (and tyranny) of technology

Illustrating the need for SOA

Saving bundles by using what you have

Expanding your SOA to customers, partners, and suppliers

Focusing on function

Service oriented architecture (SOA) is a hot topic being bandied about by IT vendors across the globe. IBM, Hewlett-Packard, Software AG, Oracle, SAP, and Microsoft (just to drop a few names) are all singing from the SOA songbook, and hundreds of vendors are adding their tunes as we speak.

“What’s SOA?” you ask. We suspect that you’ve already skimmed a dozen articles and read (or deleted) hundreds of e-mails from vendors pushing SOA, but the answers you’ve gotten so far have been, well, vague and inadequate.

The short answer is that SOA is a business approach to building IT systems that allows businesses to

Leverage existing assets

Create new ones

Easily enable the inevitable changes required to support the business

For you impatient readers out there, we expand on this short answer in Chapter 5. However, right now, we think the more important question is, “Why should I care about SOA?” In this chapter, we try to answer this question.

The promise of service oriented architecture is to liberate business from the constraints of technology, unshackling technologists and business leaders from the chains they themselves have forged. (“IT workers of the world, unite! You have nothing to lose but your chains!” as it were.) This has major implications both for the business and for the IT structure that supports the business.

From our perspective, one of the most important aspects of SOA is that it’s a business approach and methodology as much as it is a technological approach and methodology. SOA enables businesses to make business decisions supported by technology instead of making business decisions determined byor constrained by technology. And with SOA, the folks in IT finally get to say “yes” more often than they say “no.”

We pronounce SOA to rhyme with boa (bow-uh). Stretching it out by clearly articulating each letter (S-O-A) is perfectly acceptable but might leave you stymied when we say things like, “SOA what?”

Business Lib

Executives have come to rely on technology — in terms of reporting, text analytics, projections, graphical representations, risk analysis, and other analytical tools — to make informed decisions for their company. The day-to-day operations of a company have slipped, little by little, into the hands of IT. Quite simply, more and more of the activities of an organization are supported by increasing levels of business process automation — whether its business is to build ships, sell insurance, or manage cities — and since IT implements the automation of business process, business decision makers have become more dependent upon IT. While this increasing use of technology has helped the business in so many ways, technology has also created significant constraints. At many companies, business and IT management operate in very separate worlds without the benefit of a common unifying language. Unfortunately, as organizations become more diverse and complex through mergers, acquisitions, globalization, and the need to manage lots more data, the supporting IT infrastructure has become more cumbersome and brittle after being stretched in so many different ways to keep up with all the changes. This is not good for business, and neither is it good for IT.

We’re not advocating that business leaders should (or can) take control of the technology from the hands of IT. Modern businesses are inextricably tied to technology. No sizable business can function without IT — it’s as simple as that. However, we are advocating a new world order. Indeed, we advocate that business leaders and IT work together to create this new world order. Together, business leaders and IT will communicate how the automated processes of its business should be facilitated, and work together to make it a reality by using SOA. Together, IT and business leaders can determine a strategy that both liberates business from IT and allows IT to create maintainable, extensible, compliant systems to support the initiatives determined by business leaders.

Tech Lib

Just because business has become constrained by technology, don’t think that the folks in IT are having a jolly old time basking in their new-found power. On the contrary, the IT staff gets to spend its time in endless meetings accounting for why projects are late, explaining why applications can’t easily be adapted to changing business conditions, and pleading for more staff. When some clever marketer presents a new concept for selling more widgets via the Internet or mobile devices or some other new channel, IT management is always the wet blanket, having to explain why (despite the company’s investment in all the latest software and hardware) it will take 18 months to implement the new plan.

With SOA, business and IT have a way to meet each other half-way and collaborate using a business focused approach to develop new ways to use technology to grow the firm, help to spot new trends and opportunities, and see new ideas to fruition. But before you go marching off to save the world, though, we have some more explaining to do. A story will help.

A SOA Case Study

Once upon a time, there was an insurance company called ABC Insurance Incorporated. When ABC was born — oh, maybe 150 years ago — it began by selling insurance policies to factories and manufacturers. In those days, there were no computers to mess things up. The company followed business processes that were pretty simple. A nice person sent a letter inquiring about a policy. A smart person set a rate, sold a policy, and hoped that nothing caught fire or blew up. ABC thrived for more than 100 years.

But then, things got complicated. Other companies started stealing ABC’s business. Customers were asking for insurance for different kinds of risk. ABC had to change or die.

ABC was an early user of punch-card accounting systems. In the 1960s, ABC bought computers, hired programmers, and built software applications to support its business. In the 1980s, it bought software packages from different suppliers to help it continue to compete. It bought or built business applications to solve problems all over the company — one at a time. For example, it bought an application for the corporate finance department, created one to handle customer claims, and procured other applications to manage research information about what type of accidents were most common under what circumstances.

This worked well for many years, until the 1990s, when ABC found itself competing against financial services companies who decided they could sell insurance, too. Suddenly, ABC needed to find new ways to compete so it could sell a larger variety of products to current customers and also find some new customers. Its leaders thought up exciting new solutions based on the knowledge of their business and their customers.

In addition, management thought ABC could expand its business by acquiring other insurance companies with complementary products. ABC could sell these new products to existing ABC customers and sell ABC’s products to the customers of the companies they acquired. These smart guys and gals understood business strategy. Everyone got really excited until . . .

Management talked to IT, and IT said, “This is really, really exciting, but we have a small problem.”

“What could it be?” asked management.

“It’s this,” said IT. “We can no longer simply buy or build more software applications to implement our innovative plans for new products and services. The business policies and processes that we follow have become more complex. Everything we want to do has to work in concert with what we already have. The very running of our company depends on all the business applications that we built and acquired over years working together smoothly — such as the programs that tally the premiums people pay; administer the claims we process; and make risk analysis, payroll, invoicing, and sales commission calculations. When you come right down to it, our company is the aggregation of all our programs. Everything we need to carry out our day-to-day business functions — including information about our customers, our products, and our risk performance — is locked inside these programs and processes.”

“Well,” said management, “You can just write new programs to tie everything together. We’ll integrate, and we’ll all be very happy.”

And IT said, “Yes, it is possible to integrate, but integrating will take a very, very long time: at least 18 months. Maybe two years. And by then, you might want more changes that will take another 18 months or two years. By then, it might be too late. And,” IT continued, “it will cost lots and lots of money.”

Management and IT were very sad. They knew that ABC wouldn’t survive if they couldn’t find a new way of thinking about business process and technology. So they began asking everyone they knew of any way to save ABC. They searched, and they studied, and they prayed — until one day, a package arrived. In that package were several copies of a yellow-and-black book titled, Service Oriented Architecture For Dummies, 2nd Edition.

Both management and IT took copies of the book and read. They were very excited to discover that they didn’t have to throw away valuable assets and that they could reap benefits in a short time. In the end, they came up with a new strategy, one based on five key elements:

The IT organization will partner with the business managers to create a high-level map of the business processes, followed by each line of business. This will help identify the similarities, differences, and interrelationships across the business lines for the company.

The IT organization will create a flexible structure that will turn key IT software assets into reusable business services that can be used no matter how the business changes. These business services will include everything from business processes and best practices to consistent data definitions to code that performs specific business functions.

The IT organization will begin replacing the hundreds of redundant business services locked in old software with these new reusable services.

The IT organization will use only accepted industry standards to link these software assets.

The IT organization will use the service oriented architecture concept described in the rest of this book to begin to create business services that are consistent with how the business operates.

Together, management and IT began a journey. As far as we know, they are living happily ever after. In Part V, we give you many real-life case studies from companies you might recognize that indeed are alive and well and living happily on their journey to SOA.

Better Living through Reuse

One of the biggest deals in the SOA world is the tenet that you don’t have to throw away things. You take the stuff (software assets) that you use every day — well, the best of the stuff you use every day — and package it in a way that lets you use it, reuse it, and keep on reusing it.

One problem common of many large companies that have been around for a while is that they have lots of similar programs — software applications — representing commonly used business processes. Every time a department wants something slightly different, that department builds its own version of the software so that across a particular company, you might find umpteen versions of more or less the same processes — with, of course, slight variations. Many IT shops have policies and procedures designed to prevent this sort of thing, but when deadlines loom and budgets are tight, it’s often easier and quicker to write something from scratch that fills the need rather than to coordinate with other divisions. This sort of duplication becomes a nightmare when one company acquires another and finds that they have similar (but not identical) applications purporting to do the same thing.

These slight variations are precisely what make systems very complicated and expensive to maintain — even one business policy change might affect lots of different applications. In situations like this, it’s very difficult to find every instance in every application that needs to be changed. The testing required for this type of application change management takes time away from more innovative development work and can inhibit businesses from getting to market quickly with new products.

With SOA, these important business processes — such as creating an invoice, calculating an interest rate, securing a reservation — become business services. Briefly, a business service is a sealed container of software code that describes a specific business process that can be connected to other business processes. (We talk more about this in Chapter 5.) You end up with one single business service for a given function that gets used everywhere in your organization. With SOA, when you need to change a business policy, you change it in only one place. And, because the same service is used everywhere, you have consistency throughout your organization.

For example, you know that if you decide to create a new department in your organization, you’re not going to create new Accounting, Human Resources, Legal, Cleaning, Training, and Travel departments to go along with it. Even if you need to add staff, you’ll likely use your existing Accounting, HR, Cleaning, Training, and Travel departments to service — note the word service — this new department.

The problem is that over time, IT ends up embedding redundant function in programs everywhere in the organization. That redundancy — just like having separate Accounting, HR, Legal, Cleaning, Training, and Travel departments for every department — is what SOA ultimately eliminates. This lack of redundancy gives you the same obvious benefits of scalability, consistency, and maintainability.

With SOA, business managers work with IT to identify business services. Together, they determine policy and best practices. These policies and best practices become codified business services that represent honed company business processes. No need, for example, to have 30 different variations on an exchange rate translation application, each used by a different department and all requiring IT time for ongoing maintenance. One business service will do. Onward, the new world order!

Moving in Tandem with SOA

In any formal dance, from the cha-cha to the waltz, form matters. The form is what allows you to dance with someone you’ve never met. When both partners truly know the form, they move in tandem, are flexible, and navigate with ease and grace.

SOA is form. It enables the business to move, change, partner, and reinvent itself with ease and grace. In the beginning, mastering new steps requires focus and attention. Over time, the steps become second nature.

Implicit in the notion of form is standards. Using industry standard interfaces and creating business services without dependencies (more on that later, we promise) allows the business vastly more flexibility than it enjoys today to change its business model, reorchestrate itself, and partner dynamically.

Redundant reiteration, again

For any IT old-timers out there who have labored long and hard in the IT trenches, the concept of software reuse isn’t new. You’re familiar with subroutine libraries and the great theme of object orientation, and you extol the virtues of standardization. “What’s the big deal with SOA?” you ask. “Aren’t we already doing this?” Well, yes and no. Yes, because the world of SOA depends on a good understanding of reuse and on the building of reusable components. No, because SOA extends the idea of reuse not only to Web services but also to business services. (For definitions of business services and Web services, look in Chapters 5 and 6.) In the world of SOA, the level of granularity shifts profoundly. No longer are we talking simply about reusable low-level components: We’re talking about reusable high-level business services. This shift, and its implementation, is no mean feat either for business managers or for IT, but the rewards for everyone are dramatic.

Here’s a real-world application. Electrical appliances that you plug in at home today plug in equally well at the office or if you move across town. If you travel abroad, though, you likely need electrical adapters. When standard interfaces don’t agree, you must adapt. Likewise, working with industry standards set forth by standards bodies enable autonomous entities (partners, customers, and suppliers) to dance at the ball.

Sweeping Unsightly Technology under the Rug

In the next chapter, we talk a lot about architecture. For those of you who already know a lot about systems architecture and want more nuts and bolts, we suggest you skim quickly through the “conceptual” chapters in Part II to make sure you understand what we mean by the terms we use. Then dive headlong into Part III, which we promise puts meat on the bones and gives you a lot to chew on — metaphorically, of course.

One big reason we think business managers are going to like SOA is because business gets to focus more on business and less on technology, SOA technology has the potential to become more invisible at the business layer, like the plumbing in a well-designed home. In this chapter, we give you an overview of what the business can expect from SOA.

SOA enables business managers and IT to talk in business terms that both sides understand. Without SOA, the IT developer and business manager typically use very different words for the same process: for example, creating an invoice. The IT developer is concerned with APIs (application program interfaces) and how to go about creating customer records from ten different Oracle database tables. The business manager describes the actual business process used to create an invoice. With SOA, a business service is a business service is a business service. How that business service is implemented in the technology layer is the purview of IT, and business managers need not worry about it or its associated technical jargon.

Understanding Why SOA Is Different

Perhaps you’re skeptical. Perhaps, for as long as you can remember, the software industry has been promising yet another silver bullet to rid you of all business woes. We think now’s a good time to repeat that SOA is not about “out with the old, in with the new.” SOA is about reuse: taking what you have and structuring it to allow you not only to continue to use it, but to use it securely knowing that future change will be simple, straightforward, safe, and fast. SOA is indeed a journey; it can’t be built overnight. But organizations can begin SOA now and can benefit now. Ultimately, SOA renders a business more flexible — and IT more reliable, sustainable, extensible, manageable, and accountable.

We think SOA is the most important mandate facing business and IT today. And because SOA is a joint venture between business managers and IT, we present the basics necessary for everyone to come to the table with a good grounding from a conceptual level.

Chapter 2

Are You Ready for SOA? A Self Test

In This Chapter

Gauging your business and industry’s fitness for SOA

Evaluating your technological readiness

Staying on the good side of the law

Assessing whether your work environment is SOA-friendly

Tallying up your SOA score

Given what you know of SOA by your innate perspicacity and by your diligent reading of our book, we think you’re equipped to try to determine whether your organization is ready for SOA.

Readers of self-help books and lifestyle magazines are no doubt familiar with the kind of self test that supposedly can tell you whether you’re a really loving person, a person who’s ready for change, or someone who needs to get a life. Well, in this chapter, we try to help you evaluate your organization’s need for SOA. We ask you ten questions about your company. You score your answers by using the standard 1–10 scale. If your organization is at the high end of the spectrum for the question, you might be approaching a 10; if the question doesn’t resonate with you at all, you might be closer to a 1. When you tally your score, each question gets a certain weighting because some factors are more important than others. At the end of the chapter, we help you weight and calculate your score.

Question 1: Is Your Business Ecosystem Broad and Complex?

“What’s a business ecosystem,” you ask? Well, just like no species is an island in this collective enterprise we call Earth, no company can go it alone. Companies buy from suppliers and sell to customers. Beyond that, many companies have partnerships of different kinds — perhaps reselling partnerships that help sell the company’s products, technology partnerships, and distribution partnerships. All these entities — suppliers, customers, and partners — create a business’s ecosystem.

Even a small pet shop buys products and services from a variety of suppliers. It has to deal with payroll, employee management, and (potentially) partnerships with businesses that offer dog-walking services, veterinary services, and gourmet doggie dinners. The issue of complexity relates to scale. Again, if you’re the owner of that pet shop, you may indeed have all the components that we just mentioned. But if you have only three partners, it may be just as easy for you to have a few small software packages that manage finances and your Web site. Setting up a small database to track your partners may be simple.

For the sake of our handy quiz, though, you might very well own a larger company. Instead of having a single pet store, you might have a large chain of pet stores across many different regions. Your corporation may own some of these stores, and other stores might be franchises. Your company might actually have a subsidiary that produces those gourmet dinners. Your company might have a major relationship with a vast number of suppliers of everything from birdseed to grooming supplies, so you have to worry about supply chain management. On top of that, new players come into the market all the time, so your company is likely to want to make acquisitions to remain competitive. Because your company is public, you also have to meet corporate governance regulations.

Now grade yourself. If you’re more like the independent pet store, give yourself a lower score; if your company looks like a public company with a lot of acquisitions and partnerships, give yourself a score closer to 10. Somewhere in the middle? Give yourself a 5 or so.

Question 2: Is Your Industry Changing Quickly?

Not all industries are the same. Some industries change dramatically, and others are mature and stable. Why is this an important question to answer? Simply put, SOA requires an investment in time and effort, meaning that it isn’t something you should do lightly. If you don’t need to change, stick with what you have.

For example, pretend you’re in the construction industry and that your business is manufacturing cement. There are only a few large cement providers across the globe. The price for cement is relatively stable, and few companies enter the market. Clearly, anyone erecting a monument or a building has to buy from one of these suppliers. Although you may certainly need software to help run your company, the need to change that software may be minimal because the industry isn’t changing dramatically.

On the other hand, if you’re part of a media company, your industry is undergoing (and will continue to undergo) rapid changes. The Web has dramatically changed industry dynamics and has led to new products and services, new partnerships, and many mergers and acquisitions. To survive, media companies have to be able to turn on a dime.

So, if your company looks like the cement company, give yourself a lower score; if it looks more like a media company, go high.

Question 3: Do You Have Hidden Gems inside Your Software Applications?

You may not know the answer to this question, and you may have to talk to folks in IT.

Many companies have built complex applications over the past 20 years. Some of this code involves (metaphorically speaking at least) the crown jewels of the company. It includes important, unique business practices that the companies cannot afford to lose. A simple example is Amazon.com’s ability to implement a one-click purchase. Another example involves a real estate company’s technique for calculating a 30-year mortgage based on a well-documented best practice in the industry. A pharmaceutical company may have created a software program that can quickly identify a molecule well suited for drug development. In many cases, these gems are tightly linked into one aging application that can’t be changed very easily. If your company has a lot of intellectual property buried in these applications, it may be worthwhile to capture that code and make it live and breathe in the outside world.

So, if you think a lot of valuable gems are hidden in them thar hills, you should give yourself a high score. If your software holds relatively few valuable techniques or best practices, lower your score. Add a few points if your company understands the value of codifying rules or best practices as business services.

Question 4: Are Your Software Systems Flexible?

This is actually a trick question. Most business systems have been designed to meet the needs of one particular business problem or one department. As company priorities have changed, developers have patched and repatched these systems, which means that you end up with systems that don’t easily adapt to changing business conditions. Some companies have done a better job than others in writing modular applications. The more modular your applications, the easier it is for you to move to a service oriented architecture.

So, if your company had the foresight to create modular applications, give yourself a high mark. However, if you’re like most companies, you’ll have to settle for a low score.

Question 5: How Well Prepared Is Your Organization to Embrace Change?

Organizational readiness is every bit as important as the technology issues we discuss in the preceding sections. If each department wants to control its own technological destiny and is unwilling to create a companywide plan for the movement to SOA, progress will be slow. If the IT organization can’t communicate with business customers to create a mutually beneficial plan, you won’t get very far. Technology gurus tend to be religious about their approach to technology and might not be willing to listen. Individual departments might be unwilling to share code, ideas, and processes with other departments.

So, be honest about the culture within your company. Are you set up to embrace change? Is there a mandate from the CIO and the CEO to invest in a new way of leveraging technology? Do various departments contain SOA evangelists who can serve as agents of change? Or are you stuck with the way you’ve always done things? If you’re stuck, give yourself a low number; if you’re on the path to culture change, pat yourself on the back and take a high number.

Question 6: How Dependable Are the Services Provided by IT?

You may have the best strategy on paper — you may even have started to modularize your software services — but you can still fail if the quality of service provided by the IT organization isn’t up to par. For example, businesses need a guarantee that the applications they depend on are up and running at the level of performance they expect and need. Poor quality of service will affect the ability of the IT organization to move to a service oriented architecture. Simply put, a poorly performing IT infrastructure will degrade business performance even more significantly if you move to SOA.

So, if you’re a business executive, think about how often you’re able to depend on the performance and quality of the software that you rely on. Do you frequently experience problems that get in the way of completing business tasks? Can you bank on IT to get the job done? If you answer “yes” to the first question and “hardly ever” to the second, give your organization a low score. If, on the other hand, you can depend on IT to deliver on its promises, give it your thanks and give your business a high score.

Question 7: Can Your Company’s Technology Support Corporate and IT Governance Standards?

Do your company’s business practices meet mandated regulations, such as the Sarbanes-Oxley Act? Are you able to adhere to the rules designed to ensure that your IT systems are managed consistently? Can you confirm that only people with the right authorization can change critical systems? Can you prove that regulated processes have been done in the appropriate way? Are the rules regulating your company’s performance readily accessible to management? Public companies (and even private companies that interact with public companies) are being held accountable by government to prove that their business practices meet legal requirements. Companies are spending millions of dollars to reduce fraud and ensure accountability. Does your company understand the value of SOA in simplifying both IT and corporate governance?

We think there’s a direct link among corporate governance, IT governance, and SOA. If your organization recognizes that SOA will help identify the critical business services related to governance in terms of processes and rules, you’re in good shape to benefit from the move to SOA and likely have the type of enlightened management that immediately understands the value of the SOA journey. If you’re enlightened, give your company high marks; otherwise, you know the drill by now.

Question 8: Do You Know Where Your Business Rules Are?

Business rules are everywhere in every company. Ironically, many companies don’t realize that their legacy systems are chock-full of rules that dictate everything from the percentage commission a salesperson receives on the sale of a product to when a partner is eligible for a discount. Although this sounds straightforward, it isn’t. Typically, rules are buried deep in existing applications. Rules might actually be written into the code of the application itself. Therefore, you can often have a hard time finding out whether a new policy dreamed up by management actually gets implemented across the board in all software applications. For example, the vice-president of sales might have changed the commission calculation two months ago, but the rule has been changed in only two of the five applications that include a commission calculation. In this scenario, you might ask, “So what commissions are we actually paying those salespeople?” If the response from IT is, “Heck if I know,” you might have a problem.

If you have no control over where your business rules live within your vast array of applications, you have a problem and will have some work to do in order to move to SOA. If your organization has no handle on where the rules are buried, give yourself a low score. If you have an organized way to identify rules, even if you haven’t yet changed the technology infrastructure, you’re well on your (SOA) way — give yourself a higher score.

Question 9: Is Your Corporate Data Flexible, and Do You Trust Its Quality?