In writing the SOA governance piece for InfoWorld, I've been thinking a lot about how organizations can misuse governance. I've been spending some time reading what Jeff Schneider and Dion Hitchcliffe have to say on the subject of tolerance. One thing that springs to mind is to get overly restrictive in ways that cover up poor design and reduce loose coupling. Here are a few examples I was turning over in my mind.

Suppose that my organization is making a commitment to SOA. One of the issues that will come up that requires governance is choosing a standard for security tokens. Will we, for example, support SAML, Kerberos, or something else? There's another choice, however and that choice is to be tolerant of different security token formats. This requires installing or licensing some kind of token exchange service. The trade-off is more upfront work for increased service consumption, looser coupling, and more flexible partner interaction later on.

Now, let's look at Social Security Numbers (SSNs). Most organizations store them and usually in more than one place. So, think about the possible variants:

• A 9 digit string
• A 9 digit number
• A 11 digit string with hyphens
• A 10 digit string with a single hyphen (EIN)

There are probably other ways people encode this and we haven't even talked about storage (CHAR vs. VARCHAR fields, for example).

In order to introduce tolerance in the exchange of SSNs, we need to know a number of things that identify the semantics of those 9, 10, or 11 bytes and provide some way of exchanging them.

One way to handle this problem is with strong governance. You establish an enterprise-wide, end-to-end data architecture that spells out all the details surrounding every piece of data. I deal with this in some detail in Chapter 16 of Digital Identity on Identity Data Architectures. You have to determine the way each data element will be displayed, exchanged, and stored and then update the data stores and applications that rely on them to match this model over time.

That's not a bad idea, but even if you do that you'll invariably want to hook up with a partner that does it some other way. At some point, you'll be forced to deal with the semantics of a SSN and apply them to the various formats that exist. Doing so allows you to create an exchange service so that when service A wants to send an SSN to service B, they can route it through a translation service that exchanges formats in a semantically neutral manner.

Too much work? Well then SOA probably isn't for you. This is a problem that can't be ignored. If you don't provide a way to translate common data among legacy apps and partners as part of your infrastructure, then every project will end up dealing with it individually and building it over and over again in an ad hoc manner.

Tolerant services increase the opportunities for serendipitous use and thus increase service re-use and consumption. Intolerant systems are just building tomorrow's chains in a new way.