At the March meeting, the Object Management Group (OMG) issued a Request for Proposals (RFP) for a Value Delivery Metamodel specification. The RFP is based on the concept of value chain models for business analysis and planning. This specification should link strategic planning to operational activities, including SOA, and provide an important tool for enterprise transformation. I've talked about the importance of value chain modeling in past blogs, see Value Chain Modeling Is Essential for SOA Management.
In the OMG RFP, the term "value delivery" was chosen to avoid conflicts with current techniques and to recognize that an enterprise will need to manage multiple value chains and their relationships when more detailed models are developed. Paul Harmon provided some useful background on value chains and related techniques in his recent BPTrends article Value Chains and Other Processes. In another BPTrends article, George Brown describes the evolution of these concepts in Value Chains, Value Streams, Value Nets, and Value Delivery Chains.
These articles highlight the diversity of techniques that have emerged from the basic concepts presented by Michael Porter in his1985 book, Competitive Advantage: Creating and Sustaining Superior Performance. The amount of activity over the last 24 years highlights the importance of the fundamental concepts. The Value Delivery Metamodel is important for conventional enterprise management as well as SOA.
I believe the diversity of approaches to some extent reflects the need for different abstractions of the underlying concepts in order to provide manageable models with limited tools. A metamodel is essentially a specification of a computer-based modeling language. The OMG process should bring together a group of submitters with different perspectives to define the basic concepts and resolve variations in terminology. The resulting specification will enable the development of interoperable modeling tools, supporting different business viewpoints, to more effectively capture and manage value delivery models.
The OMG has also organized another forum for discussion of such issues. The Business Architecture Work Group meets in conjunction with the quarterly OMG meetings, and involves business architects as well as information technology people interested in developing better modeling tools for business planning, analysis, design and governance. I hope that the RFP along with the BAWG will bring together a cross-section of perspectives for a new generation of business modeling capabilities.
Service Oriented Architecture (SOA) has emerged as a popular information technology trend. The concept of a service is fundamental to SOA, but there are diverse opinions about what a service is, and thus some confusion about what SOA is about. Like many English words, the word service has multiple definitions. We need to clarify the meaning of service in the context of SOA in order to gain a clear understanding of SOA.
The SOA Reference Model from OASIS describes a service as "The means by which the needs of a consumer are brought together with the capabilities of a provider." The Open Group, SOA Working Group offers this alternative, "A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a ‘black box' to its consumers."
These definitions describe service as involving a business relationship. While a service relationship may be implemented as an integration of computer applications, a service implies the existence of responsible participants. While many Internet services may, on the surface, appear to be applications with web interfaces, each actually represents a business entity that operates and maintains the capability and realizes some business value for their effort. Consequently, discussions of services and SOA should not be confined to programming and systems integration, but should comprehend business integration, and access to business capabilities across organizational boundaries.
OMG is finalizing the specification of SoaML (SOA Modelling Language). In the development of this specification, there were lengthy discussions resulting from ambiguity of the term "service". Recently, I drafted the following definition with the assistance of Jim Odell.
Definition of Service
The following definition draws on the Webster dictionary and takes a dictionary approach, defining alternative meanings for the word. Note that, from a modeling perspective, there are four different types of elements: class and instance of two different concepts - action and entity.
1a: The work or action performed by one that serves . A class of work or action performed. This refers to the value delivered by a service provider without reference to a particular consumer or actual performance of the work or action. So, we may say that John provides a shoe repair service, something that he does for different customers.
1b: The occurrence of a unit of work or action provided to a particular consumer . An instance of a class of work or action. This refers to work or action provided (or intended to be provided) to a specific consumer. So, we may say that Jane received a service from John when he repaired her shoes. Note that Jane may return with another pair of shoes, for another shoe repair service.
2a: An entity supplying some public demand . A class of service provider. This refers to a capability to perform a type of work or action. We may refer to a bus service as a type of transportation infrastructure often provided by municipalities.
2b: An organizational entity that offers the capability to perform defined types of work or action for consumers . An instance of a class of service provider. This refers to a specific provider's offering of a capability. For example, the bus service of Detroit. We can also refer to John's accounting service. The qualifier distinguishes an instance from a class. Note that the accounting service (capability) may provide a number of different services (types of work), such as bookkeeping, tax reporting, budgeting, etc.
This definition clarifies differences in meanings of the term. I prefer to use service to refer to the action performed, and service offer to refer to the expression of availability of services of a particular type from a service provider. I also prefer to use service unit to refer to the organizational entity that has the necessary capability and offers to perform a service. A service unit may be part of a larger service provider enterprise. A service unit may engage other services inside or outside of its enterprise to fulfill its obligations. So, SOA is a composition of service units providing and consuming services.
It turns out that a service (the action, per se) is not represented in SoaML. There are elements to specify a service design, to define a service interface and to identify participants that provide or consume services, but an actual service activity occurs in the runtime environment, not in a model. Nevertheless, service is a fundamental concept for understanding a SOA model.
Organization structure is a fundamental aspect of business architecture. It is more than the traditional management hierarchy; it is about working roles and relationships. A modeling standard and supporting tools are needed both for business architects and for the many ways organization structure affects business operations, planning and decisions.
The Object Management Group (OMG) has an outstanding Request for Proposals for an Organization Structure Metamodel. There has been some initial work on this specification, but it has been delayed due to limited resources and the demands for other specifications. There is a need to expand participation.
An enterprise should have an organization structure model as a central point of reference for organizational roles and responsibilities. This should be a basis for employee directories, approvals in business processes, separation of responsibilities, collaboration, and a variety of other activities involving people, responsibilities and authority. A draft OMG specification addresses the traditional management hierarchy, and it also addresses cross-organizational project teams, committees and chains of command for differing purposes.
The OMG recently re-opened the opportunity for new submitters to participate in the specification development process. Under OMG procedures, the OMG issues an RFP and interested members with an appropriate level of membership (1) submit letters of intent (LOI) by a specified date, and (2) submit proposals by a specified submission date. The revised LOI date is now November 24, 2008, and the submission date is February 23, 2009. Submitters often work together to prepare a joint submission. After receipt of initial submissions, a revised submission date allows for additional work and the opportunity for submitters to resolve differences to develop a submission that all can support. The status of the RFP and current submitters are tracked on the Organization Structure Metamodel (OSM) RFP page. A new revised submission date is expected to be set by the Business Modeling and Integration task force in December, once new submitters have been identified.
I believe this is an important specification for the industry, enabling the integration of an enterprise-wide central point of reference and administration. It is also an important component of a broader OMG strategy to support business architecture modeling. The OMG Business Architecture Work Group is exploring these broader issues. The OSM should complement existing OMG specifications for strategic planning (Business Motivation Metamodel), business rules (Semantics of Business Vocabulary and Rules), and business processes (Business Process Modeling Notation and Business Process Definition Metamodel).