It’s the age of the mash-up and mix-in and composed service… yet I continue to wonder if we shouldn’t still be developing the SOA, at least seeding the initial SOA framework, in a top-down way. Just as the Internet blossomed only after the standards were created, and a mechanism evolved to create decentralized ‘control’, SOA still needs the standards to be set… not just technical, but policy, payment, and support.

In any sufficiently large organization, it is impossible to imagine a SOA emerging where the systems of one part of the business wouldn’t need to call the services developed in another.  That’s good.  Who pay for supporting those calls?  Until the question is answered, you have a roadblock to SOA adoption.

I support a part of the business that brings in about $1B per month.  I work with another part of the business that brings in far more.  But if I want to integrate with services developed by other parts of the business, I will get asked questions, valid ones, not only about cost… Questions include:

— if a service goes down and a consumer application is thus affected, how do we get the support staff for the consumer application to quickly identify the problem?  If that service is delivered by another support team, how do they make sure that the service is brought back up and that the consumer app is then diagnosed for lingering effects (like dropped or incomplete transactions).

— if a new consumer wires up to a service, and that linkage causes the service to be overwhelmed with calls, how do we charge back the cost of scaling that service up?  What if the service cannot be scaled up?  What if the architect says your app MUST use the service, but the cost to upgrade it is prohibitive?

I think that architecture has to address a number of issues: standards, economic models, support models, service level agreements, tracking and managing of end-to-end transactions, data consistency, reliability, throughput, performance, compatability with EAI systems like Biztalk, and more.  I don’t believe this is possible without some top-down constraints (a.k.a. Internet Standards) that place some requirements on a service that “may” be shared.

While the architects do not need to know about every moving part, they DO need to be aware of the largest of those parts, and make sure that they are managed well. 

This is similar to city planning, where the city needs to work with a large employer or a large retailer (like Walmart) to make sure that roads and parking and congestion issues are managed, without having to worry about cafe and card shop that are also employers, but have a minimal impact on the infrastructure.

So top down or bottom up?  I say: standards are top down, as are the connections between large systems.  The rest is bottom up in a fair and free manner.