Product Description

"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 

---

Product Details

• Amazon Sales Rank: #904222 in Books
• Published on: 2007-05-04
• Original language: English
• Number of items: 1
• Binding: Paperback
• 288 pages

From the Back Cover

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

---

Customer Reviews

combine business processes and IT
Brown emphasises here what he calls the total architecture. A unified view of business processes and information systems within a company. He suggests that getting this view and then using it to implement a Service Oriented Architecture is far more conducive to succeeding, than by merely focusing on the information systems. Implicitly, there is a contrast between this approach and those offered by earlier SOA books, like Service-Oriented Architecture (SOA): Concepts, Technology, and Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl). It and several others that appeared in the last 2 years tended to focus on the XML nomenclature for instantiating an SOA. Important, but the tendency was to emphasise what are essentially lower level details.

In Brown's book, there is no overwhelming you with scads of XML. Actually, there are no XML examples. He stays at a higher level of design, not implementation. One perhaps better suited to business managers. The book also stresses an ongoing Total Architecture Synthesis. Where this synthesis is often evaluated as the implementation of SOA proceeds. So that rather than large discrete steps, like a waterfall approach, it tends to be smaller, agile-like re-evaluations. He suggests that this is more likely to work.

Plus, there is a real added benefit that it can keep a top level, nontechnical manager closely involved as the SOA is built out. Reducing the chance of a drifting apart of the business and IT aspects. Risk reduction is vital.

SOA Bible!
I just finished reading Succeeding with SOA by Paul C. Brown. First let me start by saying that Service Oriented Architecture has been a widely discussed and presented topic in the architecture space. That being said, Paul presents it from a new perspective that interwinds the business and technology aspects and implications of designing/implementing an SOA architecture. This paradigm (Total Architecture), recognizes the fact that underpinning a successful architecture is the effective interplay of business process, people, information and systems. The author than goes on to discuss each of these areas in great detail. On the business process sides, one of the highlights is around ensuring the processes are well owned, understood, documented and measured. The later enables the tracking of metrics to ensure that any subsequent changes/modifications can be benchmarked for improvement. On the people side, the organization must have proper project/program structure and governance to ensure the effective design and implementation of the desired architecture. This structure must ensure that incentives and goals are aligned, across business silos, to ensure the successful implementation of enterprise services. On the information and services side, discussions around what constitutes a service and best practices around designing them are presented.

As mentioned, the aspect that resonates with me the most is the level of engagement required with the business side (non-IT) to ensure a successful SOA or for that mater any architecture. This is not a journey IT can lead on its own. This in turn reflects itself on changes not only in the underlying business processes but the behavior/culture of the people.

Overall a great and enjoyable read for business and IT folks alike who are considering/interested in Service Oriented Architecture. Looking forward to reading the followup implementation guide/book by the same author! Highly recommended.

Perfect for setting realistic goals in the business/IT environment.
From how to create complete rich client applications using the platform to handling plugins, no serious developer's library should be without RICH CLIENT PROGRAMMING. Paul C. Brown's SUCCEEDING WITH SOA: REALIZING BUSINESS VALUE THROUGH TOTAL ARCHITECTURE is for any information technology library beyond the beginner's level. Both business and computer collections receive a definitive guide to service-oriented architectures and how they may be understood and implemented. With an emphasis on reasons for common failures, the author draws important connections business managers and IT architects need to know for optimum results. Perfect for setting realistic goals in the business/IT environment.