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.
- 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.
- 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.
- 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.
- 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.
