SOA World Magazine serves as the Internet technology industry's journal of first resort for technical and strategic insights on the new distributed computing paradigm that is transforming use of the Internet by business and by individuals.

Long-Tail SOA and the Mythology of Reuse
In praise of the niche market, the other 80%
BY MARC RIX

Not all services are created equal. It would be great if implementing SOA were simply a matter of applying a standard design pattern to all services. Once IT had identifi ed and codifi ed an optimal design standard, services could be stamped out in assemblyline fashion until the IT landscape had been transformed. Unfortunately, we don’t live in a cookie-cutter service Utopia.

Different Strokes for Different Folks

Services exist in all shapes, sizes, colors, and fl avors. What’s more, they’re not all conducive to the same design approaches. Services are the modern digital incarnation of useful business functions: Get Employee, Create Purchase Order, Calculate Credit Score, Find Recommended Products. Any amount of work done by a system on behalf of another system (or user) qualifies as a business function. IT’s raison d’etre is to provide these functions to the enterprise, and the types of functions offered are as varied as the customers who use them, the complexity of the tasks done, and how each one relates to other functions. Some functions are big, some are small, some are used throughout the enterprise, and some are used only in obscure business niches. No two services are exactly alike and each service delivers a unique amount of value to the enterprise. To understand a service’s value we need to understand how it’s used.

Like books, songs, movies, news, and coffee, different customers prefer different IT services. There are popular “mainstream” services that appeal to large groups and unpopular “niche” services that appeal to only a few people. What’s more, as the world is discovering that there’s tremendous value in offering niche products to obscure “Long-Tail” consumer markets, IT has a similar opportunity in providing big value to the enterprise by offering Long Tail services. This flies in the face of traditional IT strategy (and popular SOA strategy for that matter), but it’s an essential ingredient in the recipe for agility.

Download SOA World Magazine, April 2008

PDF format, 10.9MB, 36Pages.

14 EDI to XML: A Practical Approach
CARLO INNOCENTI

26 First Step Toward Manufacturing Semantic Interoperability for SOA Adaption Strategy
RAMY ABAAS

30 The SOA Governance Imperative
IAN BRUCE

34 Why Enterprise Architects Continue to Fall Short with SOA…and Enterprise Architecture
DAVID LINTHICUM

Visit SOA World Official Web Site

Defining Terms
WRITTEN BY SEAN RHODY

I t seems like not a day goes by lately in which some new story of malfeasance in office doesn’t come out – whether it’s lying under oath, using the services of a call girl, or spying on other officials in the government in order to further a personal agenda. Clearly, our elected officials don’t have a clue about the meaning of governance.

Given that, it’s not really surprising that there seems to be some confusion in the SOA market place about what we mean when we say “SOA Governance.” To some vendors, governance means a product. When I say governance, I mean a process. While I think it’s simple to explain what we mean, I don’t think the confusion about terms is beneficial to the industry.

When an enterprise IT organization adopts SOA, it begins a journey of transformation within the infrastructure as well as within the fundamental business processes of the corporation.

This has a number of results that are fundamentally disruptive to the steady state of the organization (change always is). The small pilots that are created as the first steps toward SOA have very little impact on the organization. They create a few services, help define product selection and everyone goes on the way they have been working. But after a certain point, maybe 20 or 30 services or so, a variety of issues crop up.

One is ownership of a service. Ownership implies control, but it also implies cost and funding. When a department funds a small server to do LDAP, and it becomes overwhelmed because 16 other departments now want to use the same shared service (identity management), finger pointing can quickly occur. Rarely do funding models and growth predictions get rolled into the first services, and yet many of them are the support services that are necessary for every project.

Another issue is that of version control and consolidation. When a company decides that there will be one defining service for some particular purpose, it needs to be able to consolidate various versions of the truth that may already exist. This poses several problems.

The most immediate problem is getting multiple groups to agree on what the single version of the truth is. Sometimes this results in huge battles or a large number of “optional” parameters.

Groups that have defined basic communications differently (like marketing and manufacturing having their own views of what is a customer) are not likely to easily change their perspectives, but it’s usually in the organization’s best interests not to have multiple versions of the truth. In the case of a tie, who gets to be the tie breaker?

These and other questions point to the organizational and managerial aspects of serviceoriented architecture. While there are multiple ways to organize around these basic issues, there is no getting around the fact that there needs to be some organization that makes decisions and helps determine the transformation of the IT landscape from silo applications to shared (or at least shareable) services.

That’s really what I mean when I say governance – organization and processes for controlling the use of services.

Now what some vendors seem to call governance is something I think of as SOA Management– namely the observation of, enforcement of, and reporting of the quality of service or service level agreements. SLAs and QoS are both important facets of the IT world – but I rarely regard them as governance. In most cases you can’t truly decide on the SLA or QoS, rather it’s derived from best performance characteristics or limiting factors like network latency. So rather than governance, I usually think of this as Management or Reporting.

Most of the time, confusion over terms isn’t so bad – but you can see that calling one thing something else can lead to bad behavior and mistaken purchase orders.

Time to run; I think I’ve just been nominated for governor.

Comments (0)

Name

Email

Comment

smaller | bigger

Add Comment