Meet AOS, the polar opposite of SOA

Many organizations -- often prodded by vendors -- are setting out with the intentions of building out service oriented architectures, in hopes of cutting their development times and increasing business agility.

But SOA doesn't come in a neat package. As a result, the stage where many organizations are at these days is not SOA, but rather, its mirror image, AOS -- an Agglomeration Of Services. 

Let's consider the differences:

Governance:

• In SOA, there is are well-established, and increasingly automated, governance mechanisms, backed up by federated registries, that enforce standards and enable review and vetting of new services.
• In AOS, services are created by various groups, are thrown over the wall, and who knows or cares who or how many applications are using the services?

Organization:

• In SOA, corporate management is aware of the potential benefits of shared services to the business, and one or more line-of-business executives are involved in planning and governance. Training in new methodologies is encouraged and supported; development teams receive incentives to reuse services.
• In AOS, corporate management is oblivious to SOA, or consider it to be a "techie" thing. Most shared service development efforts occur and remained confined to IT silos. Training and incentives? Ha ha.

Testing:

• In SOA, services are tested, just as other applications. In addition, regular SOA service testing is end-to-end, testing entire processes which also includes to testing for dependencies.
• Testing of services in AOS...  Well, keep dreaming.

Vendors:

• In SOA, the end-user enterprise is proactive, planning out an enterprise architecture roadmap, and selecting vendors that offer the best products and standards that fit that roadmap.
• In AOS, the end-user enterprise is reactive, waiting for current vendors to come out with new upgrades, and cross their fingers that the upgrade will not be too expensive or painful, and can be accomplished within at least five years.