Implementing SOA: Total Architecture in Practice

by Paul Brown

Overview

Putting Service-Oriented Architecture (SOA) into Practice

“This book is a must-have for enterprise architects implementing SOA. Through practical examples, it explains the relationship between business requirements, business process design, and service architecture. By tying the SOA implementation directly to business value, it reveals the key to ongoing success and funding.”
        —Maja Tibbling, Lead Enterprise Architect, Con-way, Inc.

“While there are other books on architecture and the implementation of ESB, SOA, and related technologies, this new book uniquely captures the knowledge and experience of the real world. It shows how you can transform requirements and vision into solid, repeatable, and value-added architectures. I heartily recommend it.”
        —Mark Wencek, SVP, Consulting Services & Alliances, Ultimo Software Solutions, Inc.

In his first book, Succeeding with SOA, Paul Brown explained that if enterprise goals are to be met, business processes and information systems must be designed together as parts of a total architecture. In this second book, Implementing SOA, he guides you through the entire process of designing and developing a successful total architecture at both project and enterprise levels. Drawing on his own extensive experience, he provides best practices for creating services and leveraging them to create robust and flexible SOA solutions.

Coverage includes

• Evolving the enterprise architecture towards an SOA while continuing to deliver business value on a project-by-project basis
• Understanding the fundamentals of SOA and distributed systems, the dominant architectural issues, and the design patterns for addressing them
• Understanding the distinct roles of project and enterprise architects and how they must collaborate to create an SOA
• Understanding the need for a comprehensive total architecture approach that encompasses business processes, people, systems, data, and infrastructure
• Understanding the strategies and tradeoffs for implementing robust, secure, high-performance, and high-availability solutions
• Understanding how to incorporate business process management (BPM) and business process monitoring into the enterprise architecture

Whether you’re defining an enterprise architecture or delivering individual SOA projects, this book will give you the practical advice you need to get the job done.

Product Details

ISBN-13:	9780132702423
Publisher:	Pearson Education
Publication date:	04/09/2008
Series:	TIBCO Press
Sold by:	Barnes & Noble
Format:	eBook
Pages:	736
File size:	8 MB
Age Range:	18 Years

About the Author

Paul C. Brown is Principal Software Architect at TIBCO, a world leader in enterprise software and services ( www.tibco.com). His model-based tool architectures underlie applications ranging from process control interfaces to NASA satellite mission planning. Dr. Brown’s extensive work on enterprise-scale information systems led him to develop the total architecture concept introduced in his first book, Succeeding with SOA: Realizing Business Value Through Total Architecture (Addison-Wesley, 2007). He received his Ph.D. in computer science from Rensselaer Polytechnic Institute.

Read an Excerpt

If you are an architect responsible for a service-oriented architecture (SOA) in an enterprise, you face many challenges. Whether intended or not, the architecture you create defines the structure of your enterprise at many different levels, from business processes down to data storage. It defines the boundaries between organizational units as well as between business systems. Your architecture must go beyond defining services and provide practical solutions for a host of complex distributed system design problems, from orchestrating business processes to ensuring business continuity. Implementing your architecture will involve many projects over an extended period, and your guidance will be required.

In Succeeding with SOA, I discussed the need for an enterprise to pay close attention to its architecture, the role of its architects, and the importance of setting the right organizational context for their success. In this book, Implementing SOA, I turn to the work of the architects themselves—your work—guiding you through the process of defining a service-oriented architecture at both the project and enterprise levels. Whether you are an architect putting SOA into practice or you are an engineer aspiring to be an architect and wanting to learn more, I wrote this book for you.

Doing SOA well can be very rewarding. Done properly, your enterprise will comprise a robust and flexible collection of reusable business and infrastructure services. The enterprise will be able to efficiently recombine these services to address changing business needs. On the other hand, if you do SOA poorly, your enterprise will be encumbered with a fragile and rigid set offunctionality (which I hesitate to call services) that will retard rather than promote enterprise evolution. You don't want to end up there. Implementing SOA will show you the pitfalls as well as the best practices. In short, it will guide you to doing SOA well.The SOA Architectural Challenges

Doing SOA well presents you with four interrelated architectural challenges.

1. Services define the structure of both business processes and systems. Business processes and systems have become so hopelessly intertwined that it is no longer possible to design one without altering the other. They have to be designed together, a concept I call total architecture. Thus, building your service-oriented architecture is not just a technical exercise, it is also a business exercise that requires the active participation of the business side of the house.
2. You are not building your SOA from scratch. Your enterprise today operates using a working set of business processes and systems. You can't afford to disrupt business operations just because you want to build an SOA. Practically speaking, you need to evolve your existing business processes and systems into an SOA. During this transition, individual projects must continue to deliver tangible business value, independent of your SOA initiative.
3. Your SOA is a vision that requires a consistent interpretation as it is put into practice. The actual implementation of your SOA will happen piecemeal, project by project. Services that are developed in today's project must satisfy future needs, and today's projects must leverage the services developed in yesterday's projects. Ensuring that existing services are appropriately used, and that new services will meet future needs, requires coordination and planning across multiple projects, both present and future.
4. A service-oriented architecture is actually a distributed system. As such, your SOA must incorporate self-consistent solutions to all of the classic distributed system design problems: trading off service granularity against communications delays, coping with communications breakdowns, managing information that is distributed across services and sites, coordinating service execution and load distribution, ensuring service and business process availability and fault tolerance, securing your information, and monitoring and managing both business processes and services. The requirements driving your solution choices stem from the needs of the business processes involved and are thus tied in with business process design as well as systems design. As before, solutions to these problems require consistent approaches across all of your projects.

At the end of the day, your challenge as an architect is to organize your enterprise's collaboration between business processes, people, information, and systems, and to focus it on achieving your enterprise's goals.About the Book

Implementing SOA is a comprehensive guide to addressing your architectural challenges. It shows you how to smoothly integrate the design of both business processes and business systems. It will tell you how to evolve your existing architecture to achieve your SOA objectives, maintaining operational support for the enterprise during the transition. It demonstrates how to use a proactive enterprise architecture group to bring a consistent and forward-looking architectural perspective to multiple projects. Finally, it shows you how to address the full spectrum of distributed system design issues that you will face.

This book is organized into nine parts. Part I presents the fundamental concepts of architecture, services, and the total architecture synthesis methodology. Parts II through VIII discuss a series of architectural design issues, ranging from understanding business processes to monitoring and testing your architecture. Part IX then builds on these discussions to address the large-scale issues associated with complex business processes and workflow, concluding with a summary discussion of the workings of the enterprise architecture group.

In Parts II through VIII, each of the architecture topics is discussed from two perspectives: the project perspective and the enterprise architecture perspective. Each part first discusses the design issues as though the project architect were creating the entire architecture from scratch. The last chapter in each part then addresses the realities of a multiproject environment and the role that the enterprise architecture group must play to ensure that the design issues are appropriately addressed throughout the total architecture. This separation highlights the relative roles of the project and enterprise architects as well as the manner in which they need to collaborate. The enterprise architecture group chapter in Part IX then summarizes the activities of this group.

The book as a whole, and each individual chapter, can be approached in two ways. One way is prescriptive. The book presents a structured approach to tackling individual projects and managing the overall enterprise architecture. The other way is to use the book as a review guideline. Each chapter discusses a topic and concludes with a list of key questions related to that topic. Use the questions as a self-evaluation guide for your current projects and enterprise architecture efforts. Then use the content of the individual chapters to review the specific issues and the various ways in which they can be addressed. Either way, you will strengthen your enterprise architecture.

Implementing SOA is a comprehensive guide to building your enterprise architecture. While the emphasis is clearly on SOA, SOA is just a style of distributed system architecture. Real-world enterprise architectures contain a mixture of SOA and non-SOA elements. To reflect this reality, the discussions in this book extend beyond SOA to cover the full scope of distributed business systems architecture.

The pragmatic approach of Implementing SOA will guide your understanding of each issue you will face, your possible solution choices, and the tradeoffs to consider in building your solutions. The key questions at the end of each chapter not only provide a convenient summary, but also serve as convenient architecture review questions. These questions, and the supporting discussions in each chapter, will guide you to SOA success.

Table of Contents

Preface        xxvii

Part I: Fundamentals        1

Chapter 1: SOA and the Enterprise          3
The Challenge     4
The Concept of Total Architecture    5
Architecture Is Structure for a Purpose     6
Constant Changes    7
Total Architecture Synthesis        8
Making Total Architecture Work in Your Enterprise         9
Key Overview Questions    10

Chapter 2: Architecture Fundamentals        11
Structural Organization     11
Functional Organization    15
Collaborative Behavior     20
Total Architecture    26
Nonfunctional Requirements     27
Refinement    28
The Role of the Architect    29
Enterprise Architecture    30
Summary    34
Key Architecture Fundamentals Questions     35
Suggested Reading      36

Chapter 3: Service Fundamentals         37
What Is a Service?     37
Operations    38
Service Interfaces     47
The Rationale Behind Services    54
Summary    58
Key Service Fundamentals Questions    59
Suggested Reading    60

Chapter 4: Using Services        61
Service Interaction Patterns     61
Service Access         67
Access Control    72
Service Request Routing    76
Service Composition    80
Locating Services    85
Enterprise Architecture for Services    86
Summary    87
Key Service Utilization Questions    88
Suggested Reading     89

Chapter 5: The SOA Development Process         91
What Is Different about SOA Development?        91
The Overall Development Process    92
Architecture Tasks    94
Architecture in Context    96
Total Architecture Synthesis (TAS)    97
Beware of Look-Alike Processes!    105
Manage Risk: Architect Iteratively    106
Summary    108
Key Development Process Questions    108
Suggested Reading    109

Part II: The Business Process Perspective        111

Chapter 6: Processes        113
Triggers, Inputs, and Results        114
Related Processes    115
Process Maturity    116
Continuous Processes    119
Structured Processes     120
Summary     121
Key Process Questions     122
Suggested Reading    122

Chapter 7: Initial Project Scoping        123
Assembling the Business Process Inventory        124
Conducting Interviews    125
Documenting the Inventory    128
Ranking Business Processes    141
Organizing the Remaining Work    147
Summary    149
Key Scoping Questions    150

Chapter 8: The Artifice of Requirements        151
Differentiation        153
Characterizing Processes    159
Patterns of Interaction    163
Interaction Patterns Characterize Participants    171
Requirements Reflect Design        172
Summary    175
Key Requirements Questions        177
Suggested Reading    178

Chapter 9: Business Process Architecture        179
Results    180
Participants and Their Roles    182
Activities and Scenarios    186
Modeling Scenarios    191
Modeling Interactions        198
How Much Detail Is Enough?    204
Guidelines for Using Activity Diagrams    206
Summary    207
Key Business Process Architecture Questions    208
Suggested Reading    209

Chapter 10: Milestones        211
Basic Process Milestones    211
Variations in Milestone Sequences    214
Grouped Milestones    215
Recognizing Milestones Requires Design    216
Using Milestones to Reduce Inter-Process Coupling        217
Summary     218
Key Milestone Questions    219

Chapter 11: Process Constraints        221
Business Process Constraints Drive System Constraints    222
Performance Constraints     224
High Availability and Fault Tolerance    231
Security    238
Reporting, Monitoring, and Management    240
Exception Handling    242
Test and Acceptance    243
Compliance Constraints    245
Summary    246
Key Process Constraint Questions    247
Suggested Reading    248

Chapter 12: Related Processes        249
Identifying Services    252
Triggering Events    258
Summary    264
Key Related Process Questions    265

Chapter 13: Modeling the Domain     267
UML Class Notation    269
ATM Example Domain Model    274
Reverse Engineering the Domain Model    276
Domain Modeling Summary    277
Key Domain Modeling Questions    279
Suggested Reading    279

Chapter 14: Enterprise Architecture: Process and Domain Modeling        281
Process and Domain Modeling Responsibilities    282
Establishing Standards and Best Practices    283
Managing Process and Domain Knowledge Transfer         285
Reviewing Project Models     286
Maintaining the Business Process and Domain Model Repository    287
Defining Business Process Patterns     288
Defining Common Data Model Representations    288
Summary    289
Key Enterprise Process and Domain Modeling Questions     290

Part III: The Systems Perspective        291

Chapter 15: Systems Architecture Overview        293
The Challenge of Architecting Distributed Systems        294
Learning from the CORBA Experience    294
Efficiently Exploring Architectures     300
Summary    303
Key Systems Architecture Overview Questions      304

Chapter 16: Top-Level Systems Architecture        305
First-Cut Structure     305
Initial Evaluation    307
Communications and Modularization        309
Service Identification and Performance    312
Modeling System Interactions    312
Modeling Deployment    318
Addressing Performance    322
Early Architecture Evaluation        325
Key Top-Level Systems Architecture Questions    327
Suggested Reading    328

Part IV: Communications        329

Chapter 17: Transport         331
Transport Technology    332
Selecting Transports     336
Messaging Server Topology    340
Capacity     345
Point-to-Point Interaction Patterns    347
Point-to-Point Intermediaries    348
Transport-Supplied Services    350
Summary    351
Key Transport Questions      351
Suggested Reading    352

Chapter 18: Adapters    353
API-Based Adapters     354
Database-Based Adapters    355
Combining API and Database Approaches    356
File-Based Adapters    357
Protocol-Based Adapters    357
Documenting Adapter Usage    358
Summary    359
Key Adapter Questions     360

Chapter 19: Enterprise Architecture: Communications        361
Defining a Communications Strategy        361
Interaction Standards    362
Standardizing Adapters     363
Summary    364
Key Enterprise Architecture Communications Questions     364

Part V: Data and Operations        367

Chapter 20: Data Challenges        369

Chapter 21: Messages and Operations         371
Message Semantics and Operation Names     371
Transport Destinations and Operation Bundling     374
Content Representation    377
Content Transformation     378
Reference Data in Content Transformation    380
Summary    381
Key Messages and Operations Questions    381

Chapter 22: Data Consistency: Maintaining One Version of the Truth        383
Approaches to Maintaining Data Consistency    384
Cached Data with a Single System of Record        385
Coordinated Updates via Distributed Transactions    390
Edit Anywhere, Reconcile Later    390
Dealing with Data Inconsistencies      391
Data Management Business Processes    393
Summary    394
Key Data Consistency Questions      394
Suggested Reading    395

Chapter 23: Common Data Models (CDM)         397
What Is a Common Data Model?    397
CDM Relationship to the Domain Model      402
The Need for Multiple CDM Representations     405
Planning for CDM Changes    407
When to Use Common Data Models         411
Summary     415
Key Common Data Model Questions    416

Chapter 24: Identifiers (Unique Names)        417
Identity (Unique Name) Authorities    418
Hierarchical Identifiers    419
Coping with Identity Errors    423
Mapping Identifiers    429
Summary    433
Key Identifier Questions    434

Chapter 25: Results Validation     435
Checking Enumerated Values    436
Where and When to Validate    437
Summary    438
Key Data Validation Questions    439

Chapter 26: Enterprise Architecture: Data    441
Naming Schemes     441
Architecting Content Transformation    443
Systems of Record     445
Common Data Models     446
Identifiers     447
Data Quality Management    448
Summary      449
Key Enterprise Architecture Data Questions         450

Part VI: Coordination        451

Chapter 27: Coordination and Breakdown Detection         453
Activity Execution Management Patterns (AEMPs) Involving Interactions     454
Coordination Pattern Styles    456
Fire-and-Forget Coordination Patterns    457
Request-Reply Patterns    460
Delegation    465
Delegation with Confirmation        467
Summary    468
Key Coordination Questions        469

Chapter 28: Transactions: Coordinating Two or More Activities        471
Two-Phase Commit Distributed Transactions     472
Limitations of Two-Phase Commit Protocols    475
Compensating Transactions    476
Working around the Limitations of Compensating Transactions     476
Summary    478
Key Transaction Questions    479
Suggested Reading     479

Chapter 29: Process Monitors and Managers        481
Process Monitoring    483
Minimizing the Impact of Monitoring Breakdowns    484
The Process Manager as a Monitor    485
Process Management Limitations    486
Summary     488
Key Process Monitoring and Management Questions    488

Chapter 30: Detecting and Responding to Breakdowns        489
Selecting Coordination Patterns to Improve Breakdown Detection    489
Responding to Breakdowns     493
Summary    504
Key Breakdown Detection and Recovery Questions        505

Chapter 31: Enterprise Architecture: Coordination         507
Preferred Coordination Patterns    507
Breakdown Recording         509
Breakdown Annunciation    510
Recovery Processes     511
Summary    511
Key Enterprise Coordination Questions    512

Part VII: High Availability, Fault Tolerance, and Load Distribution         513

Chapter 32: High Availability and Fault Tolerance Fundamentals        515
Fault Tolerance Strategies    516
Failure Detection Strategies     517
Failover Management        519
Redirecting Clients    520
Summary    522
Key High-Availability and Fault Tolerance Questions    523

Chapter 33: Stateless and Stateful Failover        525
Stateless and Stateful Components    525
Stateless Failover    525
Saving Work in Progress through Coordination    526
Stateful Failover    528
Storage Replication    530
Summary    540
Key Failover Questions    541
Suggested Reading    541

Chapter 34: Multiple Component Failover         543
Intra-Site versus Inter-Site Failover    543
Clustering: An Intra-Site Failover Technique      545
Coordinating Peer Application Failover with Asynchronous Replication    546
Making a Business Process Fault-Tolerant    548
Summary    550
Key Multi-Component Failover Questions    551

Chapter 35: Workload Distribution         553
Work Assignment Strategies     553
Distribution Management and Work Completion    554
The Sequencing Problem    556
Access to Shared Persistent State    557
Geographic Workload Distribution    558
Summary    558
Key Workload Distribution Questions    559

Chapter 36: Enterprise Architecture: Fault Tolerance, High Availability, and Load Distribution         561
Business Process Categorization    563
Information Storage    565
Individual Component and Service Failover Patterns        565
Composite Patterns for FT and HA Services    566
Composite Patterns for FT and HA Business Processes    568
Summary    568
Key Enterprise Fault Tolerance, High-Availability, and Load Distribution Questions    569
Suggested Reading    569

Part VIII: Completing the Architecture        571

Chapter 37: Process Security        573
Security Information Classification    574
Identity and Authentication    574
Authorization    576
Encryption    579
Digital Signatures    580
Other Security-Related Requirements    580
Reference Data Servers and Performance    581
Trust Zones    582
Channel Enforcement         583
Zone Enforcement and Policy Agents    585
Multi-Zone Security    586
Summary    587
Key Security Questions    588
Suggested Reading     589

Chapter 38: Process Monitoring         591
Performance Monitoring    592
Monitoring Process Status    594
Supervisory Processes    595
The Impact of Monitoring on Performance    596
Summary    596
Key Process Monitoring Questions    597

Chapter 39: Architecture Evaluation        599
Usability    600
Performance    600
Cost and Schedule Feasibility        612
Observability    613
Ability to Evolve    613
Ability to Handle Stress Situations    614
Summary    615
Key Architecture Evaluation Questions     616
Suggested Reading    617

Chapter 40: Testing        619
Unit Testing, Test Harnesses, and Regression Testing    620
Integration Testing and Order of Assembly    621
Environments for Functional and System Testing    622
Performance Testing    623
Failure Mode Testing    627
Summary    628
Key Testing Questions    628

Part IX: Advanced Topics        631

Chapter 41: Representing a Complex Process        633
Eliding Communications Detail    634
Eliding Participant Activity Details    634
Eliding Supporting Participants    636
Abstracting Subprocesses    638
Summary    639
Key Complex Process Representation Questions     639

Chapter 42: Process Management and Workflow        641
Process Management     642
Styles of Work Assignment    647
Initiating Workflow    649
Making the Management Process Fault Tolerant    649
Human Interfaces     656
Related Processes    660
Prioritized Work    663
Dynamic Work Assignments    665
Dynamic Result and Process Definitions    666
Summary    668
Key Process Management and Workflow Questions     669
Suggested Reading     670

Chapter 43: The Enterprise Architecture Group         671
Half a Group Is Better than None—But Not Good Enough         672
Best Practice Development    672
Knowledge Transfer     673
Governance    675
Designing with Evolving Requirements    675
Summary    681
Key Enterprise Architecture Group Questions     682

Afterword         683
Focus Your Work    683
Seek the Expertise of Others     684
Be Pragmatic, But Consider the Long View     685

Index        687

Preface

If you are an architect responsible for a service-oriented architecture (SOA) in an enterprise, you face many challenges. Whether intended or not, the architecture you create defines the structure of your enterprise at many different levels, from business processes down to data storage. It defines the boundaries between organizational units as well as between business systems. Your architecture must go beyond defining services and provide practical solutions for a host of complex distributed system design problems, from orchestrating business processes to ensuring business continuity. Implementing your architecture will involve many projects over an extended period, and your guidance will be required.

In Succeeding with SOA, I discussed the need for an enterprise to pay close attention to its architecture, the role of its architects, and the importance of setting the right organizational context for their success. In this book, Implementing SOA, I turn to the work of the architects themselves--your work--guiding you through the process of defining a service-oriented architecture at both the project and enterprise levels. Whether you are an architect putting SOA into practice or you are an engineer aspiring to be an architect and wanting to learn more, I wrote this book for you.

Doing SOA well can be very rewarding. Done properly, your enterprise will comprise a robust and flexible collection of reusable business and infrastructure services. The enterprise will be able to efficiently recombine these services to address changing business needs. On the other hand, if you do SOA poorly, your enterprise will be encumbered with a fragile and rigid set of functionality (which I hesitate to call services) that will retard rather than promote enterprise evolution. You don't want to end up there. Implementing SOA will show you the pitfalls as well as the best practices. In short, it will guide you to doing SOA well.

The SOA Architectural Challenges

Doing SOA well presents you with four interrelated architectural challenges.

1. Services define the structure of both business processes and systems. Business processes and systems have become so hopelessly intertwined that it is no longer possible to design one without altering the other. They have to be designed together, a concept I call total architecture. Thus, building your service-oriented architecture is not just a technical exercise, it is also a business exercise that requires the active participation of the business side of the house.
2. You are not building your SOA from scratch. Your enterprise today operates using a working set of business processes and systems. You can't afford to disrupt business operations just because you want to build an SOA. Practically speaking, you need to evolve your existing business processes and systems into an SOA. During this transition, individual projects must continue to deliver tangible business value, independent of your SOA initiative.
3. Your SOA is a vision that requires a consistent interpretation as it is put into practice. The actual implementation of your SOA will happen piecemeal, project by project. Services that are developed in today's project must satisfy future needs, and today's projects must leverage the services developed in yesterday's projects. Ensuring that existing services are appropriately used, and that new services will meet future needs, requires coordination and planning across multiple projects, both present and future.
4. A service-oriented architecture is actually a distributed system. As such, your SOA must incorporate self-consistent solutions to all of the classic distributed system design problems: trading off service granularity against communications delays, coping with communications breakdowns, managing information that is distributed across services and sites, coordinating service execution and load distribution, ensuring service and business process availability and fault tolerance, securing your information, and monitoring and managing both business processes and services. The requirements driving your solution choices stem from the needs of the business processes involved and are thus tied in with business process design as well as systems design. As before, solutions to these problems require consistent approaches across all of your projects.

At the end of the day, your challenge as an architect is to organize your enterprise's collaboration between business processes, people, information, and systems, and to focus it on achieving your enterprise's goals.

About the Book

Implementing SOA is a comprehensive guide to addressing your architectural challenges. It shows you how to smoothly integrate the design of both business processes and business systems. It will tell you how to evolve your existing architecture to achieve your SOA objectives, maintaining operational support for the enterprise during the transition. It demonstrates how to use a proactive enterprise architecture group to bring a consistent and forward-looking architectural perspective to multiple projects. Finally, it shows you how to address the full spectrum of distributed system design issues that you will face.

This book is organized into nine parts. Part I presents the fundamental concepts of architecture, services, and the total architecture synthesis methodology. Parts II through VIII discuss a series of architectural design issues, ranging from understanding business processes to monitoring and testing your architecture. Part IX then builds on these discussions to address the large-scale issues associated with complex business processes and workflow, concluding with a summary discussion of the workings of the enterprise architecture group.

In Parts II through VIII, each of the architecture topics is discussed from two perspectives: the project perspective and the enterprise architecture perspective. Each part first discusses the design issues as though the project architect were creating the entire architecture from scratch. The last chapter in each part then addresses the realities of a multiproject environment and the role that the enterprise architecture group must play to ensure that the design issues are appropriately addressed throughout the total architecture. This separation highlights the relative roles of the project and enterprise architects as well as the manner in which they need to collaborate. The enterprise architecture group chapter in Part IX then summarizes the activities of this group.

The book as a whole, and each individual chapter, can be approached in two ways. One way is prescriptive. The book presents a structured approach to tackling individual projects and managing the overall enterprise architecture. The other way is to use the book as a review guideline. Each chapter discusses a topic and concludes with a list of key questions related to that topic. Use the questions as a self-evaluation guide for your current projects and enterprise architecture efforts. Then use the content of the individual chapters to review the specific issues and the various ways in which they can be addressed. Either way, you will strengthen your enterprise architecture.

Implementing SOA is a comprehensive guide to building your enterprise architecture. While the emphasis is clearly on SOA, SOA is just a style of distributed system architecture. Real-world enterprise architectures contain a mixture of SOA and non-SOA elements. To reflect this reality, the discussions in this book extend beyond SOA to cover the full scope of distributed business systems architecture.

The pragmatic approach of Implementing SOA will guide your understanding of each issue you will face, your possible solution choices, and the tradeoffs to consider in building your solutions. The key questions at the end of each chapter not only provide a convenient summary, but also serve as convenient architecture review questions. These questions, and the supporting discussions in each chapter, will guide you to SOA success.