INTRODUCTION

In our roles as consultants, industry analysts, and (IT) community participants, we have the opportunity to interact with a variety of individuals from both enterprises and technology providers, on a broad range of topics. Given my “geek roots,” I frequently converse with architects and technology leaders on foundational architectural strategies, as well as challenges related to the “Business of IT.” ¹

As you can imagine, these interactions surface recurring themes and interesting insights. Many are inline with our published writings, some affirm our ongoing interest areas, and others are new to us. We find each interaction valuable, and the aggregation invaluable.

With that, we thought it would be of interest to our readers, to share our latest observations from these interactions, specifically in the area of service-oriented architecture. Along with the observations, we include some actions items for readers, and ourselves.

OBSERVATIONS FROM THE FIELD: SOA

In our most recent time in the field, we discussed the hard part of SOA, the continuing hype, and the prospect of “zero code.”

The Hard Part of SOA

Enterprise architects and technical leaders consistently state the hardest part of SOA isn’t the technology. Rather, the real work is in service definition, semantics, and establishing a SOA program.

SERVICE DEFINITION. Many enterprises find it difficult to determine the correct bounds (job and tasks) and granularity (collaborations) of business services. Correctness is viewed in terms of both re-use and agility. Business services should be reusable (shared) within a line of business, across lines, and in some cases, at the enterprise level. Business services should be easily changeable (replace, augment, compose) to meet business demands.

Enterprises have erred equally on creating services at too fine a grain, and too large a grain. Erring on the fine-grained side still allows for re-use, through service collaboration, but creates performance inefficiencies to perform actual work (bounds). Erring on the large-grained side creates application- or use-specific services, rather than common business services.

Illustration 1 shows the general relationship between granularity and service re-use. As service granularity increases, the opportunity for re-use of the resulting service decreases. However, what’s important to note is the reliance on collaborators when creating a large-grained service. A large-grained service, such as a process-oriented service, should be composed of multiple function and information-oriented services. The proper use of appropriately bounded collaborators is the re-use payoff.

Business Service Re-Use
PLEASE DOWNLOAD THE PDF VERSION TO SEE THE ILLUSTRATION.
Illustration 1. This drawing shows the general relationship between granularity and service re-use. As service granularity increases, the opportunity for re-use of the resulting service decreases. One of the most common service consumers are other, larger grained, services.

Observations from the Field: Service-Oriented Architecture

Industry Specifications. Architects most confident in their business service definition have been able to leverage industry-specific specifications, such as the Open Travel Alliance (OTA). OTA specifications include schemas and WSDL implementation guidelines for common travel-related interactions, such as Request Rail Availability. ²

Unfortunately, industry specifications for true service interactions, rather than information hand-offs, are the exception rather than the norm. In most cases, architects and business analysts are relying on service definition practices from SOA technology and/or solution providers, or adopting best practices from experience, gut feel, and a wide range of published methods, including our own Service Discovery. ³

Lack of Methodology. What’s missing--and desperately needed--is a publicly available, cohesive, services definition methodology. Cohesive doesn’t refer to degree of documentation.[4] Rather, we are referring to the service definition activities that span business modeling, analysis, and design. You find a service (and the need for it) during business modeling. You define and refine the service during analysis. You further refine and provision the service during design.

In such, the business definition of a service is derived independent of technology implementation--current or future. As notation and tooling are used to transition the business service definition to technical implementation, the business intent must be retained.

Since the emergence of a good methodology happens over time, from real-world experience, we encourage practitioners to share their tips and challenges publicly, and join or create practitioner-led forums to advance real-world SOA.

SEMANTIC UNDERSTANDING. For humans, machines, and the combination, semantics has always been a challenge. While it is relatively easy to receive information (conversation, message, data exchange) it is not always easy to discern the sender’s true meaning. For example, when the word “customer” is used, does it mean end consumer, prospect, or purchaser?

As information exchange between applications and businesses became prevalent, industry and company dialects were defined to assign common terms, syntax and meaning to information elements. Given the initial purpose (technical integration) of these terms, the definition and administration has largely been the purview of technologists. As such, many of the terms are cryptic, derived from the application and information sources, rather than a true business dialect.

With SOA, the need for semantic understanding becomes even more pronounced, because of the multitude of service interactions, and the self-describing nature of service-oriented languages for service descriptions, contracts, policies, and orchestrations.

Use Business Terms. Similar to the service definition (above), semantics must be expressed in business terms. These terms must be recognized and understood by both business and technology professionals and machines, within an enterprise, and often between enterprises.

Most architects are approaching the challenge of semantics incrementally. A first priority is to achieve a common language between human parties in the enterprise, to enable proper business service definition. Another is to adopt a common XML dialect to enable semantic interoperability between services. A common practice is to describe interfaces and message payloads with a common XML dialect, and leave the underlying providers (applications, data stores) in their current formats...

***ENDNOTES***
1) The foundational architectural strategies include: service-oriented architecture (SOA), event-driven architecture (EDA), process-based architecture, federated information, enterprise integration, and open source adoption. The Business of IT includes all aspects of executing IT in the enterprise, such as: Planning, Budget, Organization, Sourcing, Skills, Portfolio Management, Development, Operations, and Change Management.

2) For more information see http://www.opentravel.org/

3) For more information on Service Discovery , an extension to Customer Scenario Mapping, see http://dx.doi.org/10.1571/soa09-04-08cc .

***ENDNOTES***