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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

One thought on “Should SOA be Top Down or Bottom Up”
  1. Some people argue for a fractal notion of the service economy. Among other things, this implies that the service portfolio should have a good mixture of different sizes / granularities.

    In city planning, small retail outlets such as cafes and card shops may have less individual weight than a major retailer such as Wal-Mart. But collectively, they may be at least as important. One of the challenges for city planning is to achieve a good balance between the large few and the many small.

    The terms "top-down" and "bottom-up" can be interpreted in different ways. If an architect only worries about fitting the big pieces together, and assumes that the small pieces will somehow look after themselves in the remaining space, this sounds like one version of "top-down".

    What if the architect concentrates on providing "positive space" in which the small pieces can thrive, and prevents the big pieces from encroaching on this space. Is this "top-down" or "bottom-up"?

Leave a Reply

Your email address will not be published. Required fields are marked *

11 + twenty =

This site uses Akismet to reduce spam. Learn how your comment data is processed.