Packaging Information in the Form of Services: The SOA Challenge
- The Concept of Total Architecture
- Growing Pressures
- Framing the Challenges
- Staying on Track
- How to Use This Book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Business processes and information systems have become so tightly intertwined that it is no longer possible to design one without designing the other. Business processes do not simply depend on information systems—they define the services required.
Altering business processes inevitably requires system changes. Conversely, system changes inexorably alter business processes. Herein we find the SOA challenge—designing systems in such a way that accommodating most business process changes simply requires rearranging existing business services. If you can accomplish this, you will not only reduce development costs but will also decrease the time-to-market for these business process changes and thereby improve your enterprise's competitive position.
But business processes involve more than just the functionality of systems. They involve information. Information is central to business processes, and these processes determine what information is required and how it should be managed. Requisitions, orders, claims, and reports, for example, are nothing more than information.
Business processes also depend on people, particularly for decision making and exception handling. From simple work tasks and approvals all the way up to strategic decision making, people provide the flexibility that enables business processes to deal with unexpected emerging opportunities and unanticipated problems. From soothing a disgruntled customer to coping with mergers and acquisitions, people make the difference.
Business processes, people, information, and systems together comprise the symbiotic collaboration that makes the enterprise work. Independently, they accomplish nothing. Together, they bring the enterprise to life. It is this partnership that enables the enterprise to produce its results and achieve its goals.
When you build a service-oriented architecture, you package a significant portion of the systems functionality and related information in the form of services. A service is a bundling of information and the functionality required to manage it. An order management service, for example, provides operations for placing, revising, and canceling orders as well as for checking order status. The service manages the order information, including ensuring the durability of the information.
Packaging information in the form of services presents a serious challenge because enterprise goals are not static. They are in constant flux. Changing business pressures and emerging opportunities continually force enterprises to reevaluate and reprioritize goals. When these goals change, enterprises must then refocus this collaboration of business processes, people, information, and systems on the new priorities. This reprioritization needs to be efficient. The ability to respond to new opportunities and changing pressures is, itself, a critical success factor for the enterprise. To quote Thomas Paine (in a phrase later made famous by Lee Iacocca), we can "Lead, follow, or get out of the way." We want to lead. This book will show you how.
The Concept of Total Architecture
Here's the challenge: Organize the collaboration between business processes, people, information, and systems, and focus it on achieving enterprise goals. Design the services in such a way that they facilitate rather than hinder the reorganization and refocusing of the enterprise business processes. Oh, and by the way, do it quickly and efficiently.
To make your enterprises work effectively, business processes, people, information, and systems must be architected together, as a whole. This is total architecture. This approach is not a choice. It is a concession to reality. Attempts to organize business processes, people, information, and systems independently result in services that do not fit together particularly well. The modification of business processes becomes inefficient, and the focus on the real business objective gets lost.
When business processes cannot efficiently evolve, enterprises find themselves hamstrung as they try to respond to changing opportunities and pressures. They produce inefficient, fragile, error-prone business processes that seem to defy attempts to improve them. As enterprises grow in scope and complexity, architects embed information systems even more deeply into the business processes to help manage this complexity. The web of people, processes, information, and systems becomes increasingly tangled. So, you have no choice but to address the total architecture. The only question is how best to do it.
Total architecture defines the structure and organization of business processes as well as information systems. This is a business responsibility, not an IT responsibility. Because of the interdependency between business processes and systems, this work must be done in concert with the systems architecture. Architecture is no longer just an IT issue—it is an enterprise issue.
Systems Are More Than Services
Systems functionality goes beyond simply providing services. When a business process employs services, some participant in that business process needs to decide when and how each service is employed. We commonly refer to this logic as service orchestration. This service orchestration itself is not, necessarily, a service, although many services (known as composite services) will employ service orchestration.
The vast majority of the functionality in your enterprise systems today is not provided in the form of services, and it is unrealistic to think that you can turn all of this functionality into services magically overnight. You must be able to employ this legacy functionality in your business processes just as effectively and efficiently as with your well-designed services. Where appropriate, you also want to evolve this legacy functionality into services.
So while services are the major focus here, there must also be a notion of architecture that is inclusive of service orchestration and nonservice functionality.
Services Involve More Than Business Functionality
When you think of a service, your thoughts probably trend toward the business functionality provided by the service. After all, an order entry service is all about placing and managing orders. But closely related to this business functionality are a bunch of rules regarding the use of the service. Who is authorized to place orders? Who can examine order status? Who is authorized to approve orders?
The rules surrounding the use of services themselves involve additional information and functionality. This information and functionality are also part of the service, and these elements are subject to change as business processes change. In fact, if you look at business process evolution, these rules seem to change more often than the functionality whose use they govern!
While you want business rules to govern access to services, you also want to minimize the technical constraints for accessing them. For the greatest flexibility, you want universal access to your services, rather than having decisions regarding implementation technology or deployment location inadvertently constrain the use of the service. So, for example, you want services implemented in COBOL on mainframes to be as accessible from business process management (BPM) tools and Java-based application servers as they are from within the mainframe itself.
You need location independence in addition to technology independence. For example, a global bank needs to be able to provide services for its customers no matter where they happen to be, for example. A customer from North America should be able to walk into a bank in Europe or Asia and use the banking services as readily as if he or she were at home. From the systems perspective, this means that the local banking system needs to be able to access customer information regardless of the actual location of the service that happens to have information for that specific customer.
This need to alter access rules flexibly and provide ubiquitous access to services in turn drives the architecture of individual services toward a modular design. This modularity separates business functionality from access rules and routing rules, while providing uniform service access from any technology. These are the core service architecture requirements that will enable you to independently alter business functionality, access policies, and routing rules.