Pete Lacey's SOA definition

Read this SOA definition from Pete Lacey this morning and it almost makes sense...too bad it's not what most people mean.

So, then, what is SOA? For one thing, SOA is misnamed. It’s not an architecture in any sense of the word. It is, to use a Burton Group phrase, a mind set. It is the generally held belief that when implementing systems one should expose system functionality for general consumption directly from the network, as well as or instead of burying it behind a user interface. It is, as well, the belief that there is a great deal of value to be generated by retrofitting network accessibility into most existing systems. And it is the belief that this can only work if the means of doing so aren’t locked to a particular language, framework, operating system, vendor, or network architecture.

It's a bit hard to disagree with that as a good policy. However, having a bit of a linguistic bent, it makes me wonder if there isn't something fundamentally wrong with an acronym that is "misnamed". Mr. Lacey does suggest an alternative term for what he is describing: Network Oriented Computing. However doesn't that make it a worse definition of SOA (since the definition better fits another term)? It does. His final definition of SOA is "a technical approach to NOC that has a non-uniform service interface as its principle abstraction. Today, SOAP/WS-* is the chief implementation approach.". This is a better definition because it actually is an architecture. It also sits well next to ROA (Resource Oriented Architecture).

The killer final definition he offers is: "Business Service Architecture (BSA): An unnecessary term (also not an architecture) that tries to make the obvious something special. Aka, business analysis. Aka, requirements gathering." Reading this crystallized something important about why phrases like IT-Business alignment always bothered me- you align the IT systems with the business via requirements gathering. Now, maybe you are doing it at high level and want to give it a special name, but the dangers of abstract terms are that people can look like they are agreeing about how to do something, but really have completely different ideas about what they are concretely going to do.

Hmm, that might be a topic for another post.

The Alignment Trap

Lots of good articles in the Fall Sloan Review of Management which I am just getting around to reading...

Avoiding the Alignment Trap in IT
One of the big ideas in IT Enterprise Architecture lately is Business / IT alignment. This is generally defined as the concept that the shape of the services offered by IT should reflect the offerings of the business. At the very least, it makes it easier for the CIO to justify why they are spending money on project X- because it is directly tied to a business need. To some degree it's a communication convenience.

In reality, the biggest benefits seem to come from simplifying the infrastructure and putting an emphasis on integration. A second article in the SMR by Cynthia Rettig really hits it on the head: The trouble with enterprise software:


...enterprise software may be just too complex to deliver on its promises. She also suggests that the next new thing — service-oriented architecture (SOA) — is not likely to fare much better, for many of the same reasons. There are no easy fixes, cautions Rettig, save a large dose of sobriety, clear-eyed analysis and emphasis on simplicity and efficiency.

If you want to read one of the best advocates for the odd beast known as SOA, I suggest following Bobby Woolf's blog or reading his new ebook. His old book is has had a solid slot on my shelf for a couple of years, but I still haven't felt the need to install an Enterprise Service Bus. (Despite the fact that I more or less use it as a design pattern for integration architectures, just without the overhead of actually having it be a running piece of software)

In any case, I am not writing myself out of a job here- the message is simple though: don't try to do everything at the expense of ending up with complexity. Keeping things simple and hitting the "Pareto important" requirements is the winning strategy.

Authentication in the database- revised

There are some people out there that believe there is one right way to build an application. The people that believe in best practices. The people that fall victim to Harwell's laws. (Particularly #1, "People always try to use their experience even if it doesn't apply to the current situation." and #3 "If a manager doesn't know how to improve an organization, then he/she will change it to look like the last organization that he/she remembers")

The particular issue I am dealing with has to do with web application security architecture, but it comes up again and again in architecture, particularly in web services. Where does authentication live and where does authorization live? And what trusts what. In particular, should a web application authenticate a user's x509 cert or Kerberos ticket, and then pass user information on to further systems, or should it pass the users security information on to further systems, such as databases. In other words, should authentication performed at each stage of a request that passes through multiple systems?

If you ask Oracle any question of the form "Should X be in the database?" the answer is yes. Apparently Microsoft is training their people to think the same way. It sure works great to induce vendor lock-in.

Somehow I am of the opinion that the first system a user comes in contact with should perform the authentication, that system should authenticate to other systems- as a system, not a user, and that their should be trust in the initial user authentication.

Having the database re-authenticate the user seems wasteful...and of no value.