Succeeding with SOA: Realizing Business Value Through Total Architecture - Softcover

Brown, Paul C.

Softcover

ISBN 10: 0321508912 ISBN 13: 9780321508911

Publisher: Addison-Wesley Professional, 2007

Synopsis

"Like so many acronyms in public currency, SOA means many different things to different people. Paul Brown deftly avoids getting caught in the trap of overstating the case for SOA. Instead, he brings the topic skillfully into focus, zeroing in on the concepts that must be understood in order to be effective. Paul's purpose, as I've found so often in his presentations and conversations, is to get to the core of real-world architectural issues that make the difference between success and failure. Paul doesn't sit in an ivory tower pontificating; he gets right down to the critical issues in order to develop effective real-life strategies."

--From the Foreword by Jonathan Mack, Senior Technical Architect, Guardian Life Insurance Company

"As Paul Brown explains in this fine book, there is more to software development than just writing code. Successful software requires deep thought and strategy. It requires the coordination and marshalling of the resources and intellect of the entire company, both business and IT. I learned much from reading his manuscript and heartily endorse the finished book."

--Dr. Michael Blaha, author and industrial consultant

"Paul Brown has provided a practical and actionable guide that will illuminate the way for Business and IT Leaders involved in IT strategy, planning, architecture, and project management. A successful adoption of SOA will touch every aspect of the business and change the way IT does business. This book does a good job of describing the organizational challenges and risks and providing suggestions to manage them. It also dives deeply into the architectural techniques that can be employed in order to align the service architecture with the business, thus providing maximum benefit and continued funding for your SOA transformation."

--Maja Tibbling, Lead Enterprise Architect, Con-way Enterprise Services

" Succeeding with SOA achieves where most books on service-oriented architectures fail. It accurately describes what practitioners are seeing, as well as why, and gives them practical examples through case studies and instruction. Most useful both for those about to take the plunge and those who are already soaking."

--Charly Paelinck, Vice President, Development and Architecture, Harrah's Entertainment

"This book is a must-read for architects and SOA practitioners. It provides an important foundation for a SOA strategy. Brown emphasizes the importance of aligning services with their business processes, building capabilities using strong enterprise architecture standards, and ensuring an effective governance process. The book promotes the notion of mutual dependency between managing a business using business processes and managing its IT with SOA. By aligning the two paradigms, a business can become more agile, able to adapt to change both quickly and economically. This is the promise of SOA."

--Sunny Tara, Director, IT, Enterprise Architecture and Services, Harrah's Entertainment

Getting a Desired Business Return on Your Service-Oriented Architecture (SOA) Investment

Today, business processes and information systems are so tightly intertwined that they must be designed together, as parts of a total architecture, to realize enterprise goals. In Succeeding with SOA , Paul Brown shows how service-oriented architectures (SOAs) provide the best structure for such integration: clean, well-defined interfaces between collaborating entities. But even SOAs need to be correctly understood and implemented to avoid common failures. Drawing on decades of experience, Dr. Brown explains what business managers and IT architects absolutely need to know--including critical success factors--to undertake this essential work.

Coverage includes

• Setting clear and reasonable expectations for SOA's benefits
• Understanding why conventional project management techniques don't scale to today's enterprise-wide projects
• Defining a living roadmap for developing services based on business priorities
• Establishing coherent leadership that brings together business executives, IT leaders, and the SOA architecture group
• Using Total Architecture Synthesis (TAS) to rapidly develop business processes and information systems together
• Understanding the central role of architecture--and making sure the right architectural decisions get made

Whether you're a business or technical leader, this book will help you plan, organize, and execute SOA initiatives that meet or exceed their goals--now, and for years to come.

List of Figures
List of Tables
Foreword
Preface 
PART I. Building Your SOA
Chapter 1: The SOA Challenge
Chapter 2: Business Process Pitfalls
Chapter 3: Business Systems Pitfalls
Chapter 4: SOA: More Than Services
Chapter 5: Keys to SOA Success
Chapter 6: Organizing for SOA Success 
Chapter 7: SOA Project Leadership
Chapter 8: SOA Enterprise Leadership
Chapter 9: Agile SOA Development
PART II. Managing Risk
Chapter 10: Responsibility and Risk in Business Processes
Chapter 11: Managing Project Risk
Chapter 12: Investing Wisely in Risk Reduction
Chapter 13: Managing SOA Risks
Afterword
Index 

About this title

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 design work on enterprise-scale information systems led him to develop the total architecture concept. He received his Ph.D. in computer science from Rensselaer Polytechnic Institute.

Excerpt. © Reprinted by permission. All rights reserved.

Are you worried about getting a business return on your service-oriented architecture (SOA) investment? Are you a business manager who has been disappointed by an information technology (IT) project, or an IT manager or architect who has been disappointed by the business's reaction to your project? If your answer is yes to any of these questions, I wrote this book for you.

If you've been part of one of these disappointing projects, most likely the reason for your disappointment was a disconnect between the business and IT communities--a disconnect that resulted in the project failing to deliver the business value that both sides expected. It is likely that this disconnect was not even recognized until late in the project. So late that a lot of concrete had been poured over the misunderstandings and misconceptions. So late that correcting these misunderstandings and misconceptions began to look like another project.

Such disconnects are simply intolerable in service-oriented architectures. Obtaining a solid return on a SOA investment requires more than simply avoiding such disconnects. It demands proactive and constructive communications between the business and IT communities. The business must clearly define the business objectives of the SOA initiative--the things that will provide the actual business return on the SOA investment.

The business and IT communities must then join forces and work together to achieve these objectives. Together, they must define the business process and system changes required to produce the expected business results. This collaboration is not just to make SOA initiatives succeed. It is essential for any project that is supposed to produce business value. For the most part, failed projects are projects that have either lost sight of the business objectives or failed to focus the business process and system changes on achieving those objectives.

The challenge here is that business processes and information systems have become so intertwined that it is literally impossible to make changes to one without altering the other. In particular, changes to information systems alter business processes--often in unexpected and undesirable ways. Despite this, project plans rarely stop to actually consider the design of business processes, unless the project happens to be tackling a major business process reengineering effort. As a result, business processes just sort of evolve, piecemeal, project by project, as you make changes to your information systems.

When the scope of a project lies entirely within a single business unit, you can get away with this. Working within that business unit, the business users and developers sit down and discuss how it's going to work, and the developers go off and update the systems. This casual approach works reasonably well when there is only one development group and only one user group. However, this approach is woefully inadequate when there are multiple user groups, multiple development groups, and multiple systems involved. In fact, it is a recipe for disaster.

Service-oriented architectures are supposed to bring an end to this chaos. SOA is supposed to provide clean, well-defined interfaces between business entities--between service providers and service consumers. But who, exactly, are those service providers and service consumers? Are they systems? Well, yes and no. There are, indeed, systems providing and consuming services. However, those systems are providing functionality on behalf of business units for use by other business units. Thus, when you define business services, you are actually defining the boundaries between business units and the interfaces between them. In other words, you are defining the structure and organization--the very architecture--of your business units.

The architecture of business units is not a technical issue--it is a business issue. SOA determines the architecture of both business units and systems! Consequently, both business and IT need to work together to successfully implement SOA.

A Closer Look

Taking another look at those failed projects, a couple of questions arise. Which projects failed? Most likely the ones that involved multiple business units. Why did they fail? They failed because nobody on the business side of the house thought out what the business process needed to be and how the various business units and systems ought to participate in that process. Or, if they did, they failed to succinctly communicate this understanding to the IT developers.

Either way, this left the IT developers--often multiple groups of developers--guessing as they defined the dialogs between information systems belonging to different business units. Guessing about what the overall business process was supposed to be and guessing about how it should handle exceptions. They implemented these guesses, and only then were the inadequacies of the guesswork recognized. Then they began the arduous process of evolving these business processes into something that actually worked on a business level--as the project slipped into cost overruns and delays.

Let me ask you a question. Would you consider automating the interactions between your enterprise and one of its suppliers without first coming to an agreement about what those interactions would be? How the quote-order-shipment-payment process would actually work? Of course not. Then why on earth should you treat the internal dialog between your business units--your order management group, your warehouse management group, and your financial group--any differently?

Let's be clear about this. I'm not talking about massive business process reengineering. I'm simply talking about taking the time to think out the business process, thinking through what the business process ought to look like and how the business units and information systems will participate in that process. You need this picture to include both sunny-day scenarios and exception handling, and then convince yourself that this vision will produce the business value you expect from the project. Then, and only then, should you make an investment in implementing the business process and system changes.

Why is this important? Because it is business processes that actually provide value to the enterprise. Yes, information systems are an increasingly important component of those business processes, but there is no inherent business value in the systems themselves. Their value lies entirely in their ability to make business processes work. Business processes are what is important. The reason we do IT projects is to make business processes provide more value.

Oops! I slipped (on purpose). In that last paragraph, I made the very mistake I am trying to help you avoid! I said that business processes are important--and then immediately started talking about IT projects. This thinking, that there is a separation or schism between business and IT, has become an institutionalized habit in many enterprises. It usually extends all the way up to the very top of the organizational hierarchy. Yet this same business-IT separation or schism is the root cause of many project failures.

This schism is an outright showstopper for SOA. This is why architects, business managers, and IT managers, from the frontlines to the chief operating officer (COO) and chief information officer (CIO), need to work together to solve this problem. You are the only ones who can provide the solution.

So what am I asking you to do? If you are a manager, you can help by doing these four things.

1. Understand the nature of the problem. Business process architecture determines how business units interact with one another to make business processes work. Systems architecture determines how systems interact with one another to make the technical part of the business process work. Business processes and systems have become so intertwined that you can't design one without designing the other. Thus, business process architecture and systems architecture are but two different views of the same architecture--the total architecture.
2. Put someone in charge of your total architecture. If you are to make sense of and manage your enterprise's total architecture, somebody needs to own it--all of it. Business process architecture and systems architecture belong together, under one roof. Today systems architecture is in the IT organization, and as for business process architecture--well, nobody owns that! Don't believe me? Try to find someone in your organization who can describe your complete order-to-cash business process! Then ask yourself how you are supposed to manage something you can't even describe. You need to put someone in charge of your total architecture and get it under control.
3. Demand total architecture visibility. Demand that the architecture of your business processes and systems be captured in a form that can be readily understood and shared. Only then will it be possible to have meaningful discussions about modifying and improving business processes before you incur the cost of actually implementing the changes.
4. Provide the authority needed to manage the total architecture. To be effective, the group managing the total architecture needs to report to the business operations manager responsible for executing business processes. This is the only person who (a) sets the enterprise priorities and (b) has the authority to command cooperation and change in both the business and IT sides of the house. You don't need to do a massive reorganization. But you do need to take leadership personnel from business and IT, task them with rationalizing and managing how your business actually works, and support them with the authority to make it work.

If you are a business process or systems architect, take action in these ways.

1. Understand the depths of the interdependencies between business processes and systems. From determining the functional boundaries between business units and systems to determining the performance requirements and appropriate level of investment in fault tolerance and high availability, all system requirements are derived from an understanding of the business process. These are your responsibilities.
2. Understand the ultimate dependency of systems upon people for flexibility. Understand the importance of feedback in detecting and responding to breakdowns in business processes and systems.
3. Understand the social and organizational issues surrounding your work. Understand the extent to which your work depends on the cooperation of all organizations involved. Be on the lookout for signs of misaligned priorities, and take action to raise the visibility of these misalignments.
4. Understand how to efficiently organize a total architecture development. Understand the importance of providing early feedback regarding cost and schedule feasibility.
5. Execute every project from the total architecture perspective to provide true business value. Design business processes and systems together to deliver expected business benefits.

Succeeding with SOA is a call to action for both managers and architects.

For managers, the call is to set the organizational stage to actively manage your total architecture. Architecting your business is a business activity, not an IT activity. The business side of the house needs to take ownership and lead this effort. Put someone in charge of designing and documenting your overall business processes! They are, after all, the lifeblood of your enterprise. Don't leave them to chance.

For architects, the call is to realize that you are architecting business units and business processes as well as systems, and to structure your work accordingly. This volume will help you understand the context for your work. The companion volume, SOA in Practice: Implementing Total Architecture, will give you the tools and techniques for actually developing a total architecture.

PCB
Schenectady, NY
January 2007

Edition details

• Publisher: Addison-Wesley Professional
• Publication date: 2007
• ISBN 10: 0321508912
• ISBN 13: 9780321508911
• Binding: Paperback
• Language: English
• Edition number: 1
• Number of pages: 278