Considering the SOA Reference Model

Part I - Business Grounds

Dec. 27, 2006 06:00 AM

SOA RM: "...in SOA, services are the mechanism by which needs and capabilities are brought together"

Recently OASIS voted the SOA Reference Model (SOA RM) into a standard. In spite of its high level of abstraction, this model emphasizes the business orientation of SOA. This two-part article will elaborate on the business aspects of the standard. Part 1 discusses one of the possible business grounds for SOA and design-for-changes uses cases. Part 2 will describe several technical design pillars of SOA in light of the standard.

Business Agility
The SOA Reference Model (SOA RM) is the first standard that shifts SOA from a pure technical realm into the business world; you can see it right away from the SOA service description. You can wonder what "needs" and "capabilities" means; why an application in IT, which is considered to be an SOA service, becomes a mechanism; and, finally, where all the technical definitions of interfaces, clients, providers, QoS controls, etc., are. Don't worry, they're all in their places but now they have been repurposed toward business agility.

In particular, the SOA RM says: "the central focus of service-oriented architecture is the task or business function - getting something done." That is, in SOA, we're talking about a business function of the organization rather than about isolated business operations that implement the function today. The function is something the organization cannot exist without; the organization business model is the combination of such functions while the actual implementation of the function is the secondary category. Unfortunately, up 'til now, the majority of IT applications fit exactly into that category. Now SOA creates an opportunity for IT to become the business partner and perform as a function for its enterprise rather than just a support provider.

The SOA RM states that an SOA service operates in an "execution context," which is defined as a "set of technical and business elements that form a path between those with needs and those with capabilities." The standard expands the interpretation of "those with needs" and "those with capabilities"; "those" are not only IT applications and operations, they are the business elements as well, and, moreover, the business elements are first. If IT looks at its organization from the business perspective (versus operational/procedural ones), it can find that very few applications correspond directly to the core business tasks; other applications support a lot of just-this-moment operational requirements that were real years ago. If you add runtime and procedural application integration to this view, it becomes easier to see why IT has difficulties implementing and supporting frequent business changes required by the modern market.

Finally, when explaining how SOA differs from other models, the SOA RM outlines that it reflects business-motivating considerations that are expressed "within service descriptions and service interfaces." This is what SOA brings to the table the first time because a service description in the form of the service contract includes policies that "may also express business-oriented policies - such as hours of business, return policies, and so on." That is, some services in SOA elevate to the level of business entities. Now that it's more clear what "capabilities" are, we are saying that an SOA service can implement much more than the interface "API"; it's responsible for the functional and non-functional aspects, many of which might be invisible to the consumer though the service interfaces. Nonetheless, the invisible capabilities are just as important to the service consumer as the visible ones, because consumers now depend on the honest behavior of the service outside of the consumer's control. For example, your enterprise service engages a third-party service to publish your results on the Internet. Would you like to use that service if you find that it doesn't filter porn ads and they get or can get published with your data?

You are right, not every SOA service is that complex and there are a lot of simple and very useful services that IT can offer. However, the power of SOA is in the services that implement business services and, accordingly, get involved in the risks of real business life. In this article, I will go a step further and elaborate on how a business may be decomposed into elements useful for building SOA service applications, and what the IT managers and architects have to understand and deal with if they really want to modernize IT to be agile in business. That is, the article tries to position SOA as a business-centric application architecture driven by business (not by technology) and organized in a way that is oriented to support business changes, both today and tomorrow.

Business Model Decomposition
Since the SOA RM standard attempts to facilitate an enterprise technical architecture to mind real business functions, it would be worth finding out what they are. This way, one of the working assumptions we make is that every organization operates on the basis of its business model. A business model definition is still evolving; in this article, we'll use the one below:

A business model is "a conceptual tool that contains a set of elements and their relationships and allows expressing the business logic of a specific firm. It is a description of the value a company offers to one or several segments of customers and of the architecture of the firm and its network of partners for creating, marketing, and delivering this value and relationship capital, to generate profitable and sustainable revenue streams."

A business model also has instrumental and structural elements. For example, distribution channels and revenue models are instrumental elements while value configurations (the configuration of activities and resources) and core capabilities (the capabilities and competencies necessary to execute the company's business model) are structural elements. Talking about structural elements of the business model, we can recognize Business Services and Business Processes, the compositions of which constitute core capabilities. Both Business Service and Business Process have internal structures as illustrated in Figure 1 and described below.

The functional organizational decomposition of an enterprise model helps in recognizing its Business Services and Processes. Each Business Service is unique in the organization but may formally be described in the same way as other services. In particular:

The foundation of a Business Service is data: The data becomes business data when its business meaning is defined via business metadata. A Business Service specifies methods, activities and/or rules that might be applied to manipulate the business data. Business methods, activities, and rules may be grouped for cooperative execution in different scenarios. The latter have their own methods and rules for composing data processing activities; those compositions are usually called business operations and workflows. The execution of data manipulation methods, activities, and/or rules in business scenarios produces results. The results become business results when corresponding business metadata is defined. The Business Service frequently includes a delivery mechanism of the results to the business consumers although it is optional. (Other important elements of a Business Service such as documentation and audit rules and procedures are skipped here for the sake of simplicity.)

A Business Service consists of at least one business unit of work, which encapsulates some business data and data processing activities. The entities of the data processing activities are different heterogeneous "things" representing additional data, applications, communication processes, human activities, information containers (e.g., a spreadsheet), and more. The business unit of work defines how a particular business task of the Business Service is implemented. The implementation is not crucial for the enterprise and is the subject of change based on solution availability (including technical ones) and market trends.

Business Service changes, in its core, are infrequent and usually reflect industry and corporate policies or corporate restructuring. Instead, the Business Service may be extended or split into several new Business Services. What can and may happen to the Business Service is defined in the enterprise business model.

A Business Process is defined in Wikipedia as:

"a collection of related structural activities that produce something of value to the organization, its stakeholders or its customers. A business process can be part of a larger, encompassing process and can include other business processes that have to be included in its method. In that context, a business process can be viewed at various levels of granularity."

In the Business Process, Business Services interact with each other according to special methods, activities, and/or rules. The interactions may be viewed as an exchange of the results (actual or logical) produced by the Business Services. That is, a Business Process consists of methods, activities, and rules for exchanging results between Business Services. Methods, activities and exchange result rules constitute the "things" the enterprise business usually changes to adapt to market needs. The richer the spectrum of changes available and the easier the changes are to do, define the market adaptability and business stability of the enterprise. SOA targets this exact area; however, without implementing Business Services (in addition to the technical services), SOA can't help in the Business Processes.

At the entrance point into a Business Service, the foreign results become new data and the Business Service's stack starts again. Sometimes, metadata transformation is needed to convert foreign result interpretation into the local one. The transformation may be done either by adding additional metadata (i.e., accepting metadata provided with the foreign results) or by replacing some or all of the foreign metadata with internal metadata - business data interpretation.

Thus, we can rephrase the goal of SOA:

The creation and maintenance of such application architecture that can effectively support corporate Business Services and Business Processes with the highest effectiveness and can quickly adapt to the changes in them.

Thus, SOA may be viewed as a technical architecture built around an enterprise business model, not around isolated business procedures or just-this-moment operational needs. SOA is supposed to address current and upcoming business requirements, diversity, which is limited by a particular business model. If the business model is unclear in the organization, Services and Processes, SOA won't help but rather will confuse the company a lot.

Design for Business Changes
Forrester Research states, "The reality of the digital age is that your business is embodied in your technology - you don't have a business until you have it implemented in your technology base, and your business can change only as fast as your technology can." SOA promises to make the changes faster and easier. Let's observe these changes.
Looking from the enterprise perspective, we can find three types of possible change in the business that the technology has to support:

Changes in the business methodology of doing things (e.g., changes required by the Basel II regulations in financial credit management)
Changes in the set of tasks performed by a business service and/or in a business process (e.g., adaptation to the market trends)
Changes in the core of the business service, i.e., in the business model, dictated by the market dynamics (e.g., enterprise strategy change)

SOA can help IT in two ways by:

Offering services that can be easily combined in different compositions
Hiding change implementations behind the service interfaces

The first way is popular but it has significant pitfalls: to gain certain flexibility in the compositions, the services either have to be quite generic, which hits performance and risks losing control over details, or there should be a lot of fine-grained services available, which makes management and maintenance difficult and you can end up with a significant ballast of in-definite non-reusable services.

The second way is the IT hope of SOA. However, those who hope are usually forgetting that the changes are not free due to the cost of retesting and revalidating all the dependencies (in the Service Contracts) and the actual support for multiple service versions - not all service consumers "are in need" of the changes at once.

The following examples illustrate the third way of designing SOA services - the design for changes. This approach is based on an a priori knowledge of the business model and its potential modernization. Certainly, this way does not help in converting the service to a completely new one, but it covers the majority of other, smaller change-cases.

Access Control System
Assume we build an access control service based on roles. A user or subject in a role is permitted to operate on a resource - client's data - and perform the activities associated with or defined for the role. The role is equivalent to only one activity, e.g., "read," "write," or "edit."

Due to business responsibilities, many users may or have to perform several activities but individual role assignment demands costly operational support. The business requires reducing the cost of the access control management and maintenance.

Traditional Application-Centric Design
IT decides to simplify management and maintenance by gathering users into groups and each group is assigned multiple roles. That is, all users in the group inherit all the roles from the group. The business objective of reducing costs is reached.

In a while the market has changed and the client's data has received new internal dependencies. For some users, their duties have become conflicted with the new data dependencies and those users had to be restricted from acting in one of the roles, but they still have to perform in others.

Since a group has been designed to provide inheritance of all the roles to all group members, the only possible way to restrict a user in the role is to create another group with a reduced set of roles and put those users into a new group. It's easy to imagine that if a group has a relatively small number of associated roles (three, for example), eventually we have to create seven groups to represent all possible combinations of the roles. Considering the realistic number of different clients and original groups in the firm, this becomes a maintenance nightmare. Plus, adding a new role to the initial group increases the number of group variations almost exponentially, and the operational cost rises correspondingly.

SOA Design Style
We have started by studding the business model and found that users may be grouped (to make management cheaper) based on their business responsibilities that follow certain corporate policies. This means the grouping should be changed if user activities are in conflict with the policies. Another potential reason for the access change is a reassignment of the business responsibilities to a user. With this business knowledge, the access control service has to be designed in such a way as to accommodate access changes even if current business requirements don't say anything about it (which, actually doesn't mean there isn't any problem).

Instead of explicit role inheritance from the group to the users, each user becomes associated with a mask specified for the given group. The mask addresses all roles in the group and defines which concrete roles a particular user inherits from the group. As a default, all roles are inherited. If a user's access should be changed, the user's mask is modified and no new masks or groups are created. Plus, the modification may be based on corporate business policies. What we get is this: almost the same savings for the business but it works now and in the future.

This described case fits into SOA very well because the change may be done behind the service interface transparently for the service consumers. However, if the service has not been designed for change from the beginning, it would be too risky adding the masks later (even behind the interface) because, in case of a mistake, it could create problems with resource access for many users and negatively affect corporate business service.

About Michael Poulin
Michael Poulin works as an enterprise-level solution architect in the financial industry in the UK. He is a Sun Certified Architect for Java Technology, certified TOGAF Practitioner, and Licensed ZapThink SOA Architect. Michael specializes in distributed computing, SOA, and application security.