What you need to make middle out SOA architecture work

In middle-out SOA, we want to do as little as possible from the "center."  The real value is at the edge, where the services are being created and where value actually lies. 

Our goal, in middle out architecture, is to set up standards, mechanisms, and protocols that everyone will follow.  We will give names to services that need to be created, and we will describe a small set of standard message exchange patterns, complete with the names to be used at the endpoint.  Where possible, we will specify transport mechanisms as well.

Important: in Middle Out SOA, the central group writes NO code.

Let me give you an example.  In the metropolitan area around Seattle, there are quite a few suburban cities.  East of Seattle, across Lake Washington, is the city of Bellevue.  Next to it are the cities of Redmond and Kirkland.  These cities each began from their own centerpoint and grew outward until they collided in the same area.  The Microsoft campus is on a 'spur' of Redmond that is surrounded almost entirely with the city of Bellevue. 

 

If you look at the map, you will see that there are PLENTY of roads that are either borders between the cities or cross from one city to the other.  As a driver who drives in this area, I can tell you that the roads have the same name on both sides of the city lines.  Normally, you do not know which side of the line you are on, or where the transition happened. 

Why is it so seamless?  It is not overtly controlled.  The cities are quite distinct from one another.  Rememer, they grew from their own centers out.  So why is it, when they intersected, the arterials lined up and the names are standard and the roads don't change width or designation? 

It is because the planning departments in these cities all work together on standards.  There is a standard numbering scheme for the entire of King county (5,974 square km) that allows all streets, even ones in rural areas, to have names and numbers that don't change from city to city.  The roads have a standard width, and roads of a particular arterial classification have standards for sidewalks and traffic lights.  I can find a business by its address, regardless of what side of the street that business is located on.

My car is a data packet that travels over these roads, and I have the routing mechanism in my brain, deciding the route and alternatives as needed to find my destination address.  It works because those roads and addresses are consistent and integrated.

The coordination between the two cities is practical and useful.  Each city has an ordinance requiring its planning department to cooperate with other cities.  That is important.  The ordinance is a fixed decision, made by their governing bodies, that gives their planning boards support and direction.  Without the ordinance requiring cooperation, passed by each city, the roads would not work.

This is the fundamental idea behind middle-out architecture.  Know the MINIMUM set of standards that everyone has to agree on, and get the management to buy in to requiring that minimum amount of cooperation.  Then cooperate.  Each area is responsible for their own governance. 

It is an inherently distributed mechanism, and therefore scales well.  Note that the minimum set useful in an enterprise is larger than the minimum set useful across the internet as a whole (at this time).  Mashups and SaaS services will not have a consistent mechanism for sharing data... at least not until customers demand it.  On the other hand, in an organization, consistency at the data level makes more sense and therefore a common event and schema model can be expected and used.

Middle out is not new.  It is a way of describing what works in other areas.  It is only new to SOA because SOA is new to IT.  We are still learning what other folks already have learned.  We are still catching up.

Comments

• Anonymous
  July 23, 2007
  My son, like the rest of kids his age, as well as many others is spending every waking hour reading the

• Anonymous
  July 25, 2007
  I agree completely. However, your analogy sparked a side thought which may be worth consideration. If your car is a data packet, you, the driver, are a process. The function of the process is to deliver the data packet to its intended destination. While the departments of the cities create standards, intended to grease the wheels of the enterprise, some cities (like the ones around the Hampton Roads area in Virginia, where I live) have ancient roots, and structure that existed prior to the emergence of these standards. In addition, because humans are involved in the implementation of the standards, there may be improper or incomplete implementations at various points. In other words, no standard is a complete solution to a problem, but only approaches the solution. On the other hand, it is the responsibility of the driver (process) to deliver the car (data packet) to its destination. This requires a certain amount of independence and creativity on the part of the driver, a measure of intelligence. While the ultimate goal is to keep this requirement to a mimimum, because that goal can only be approached, processes in an enterprise should be designed to be able to deal with these exigencies, balancing that against the goal of making them light-weight.

• Anonymous
  July 28, 2007
  The comment has been removed

• Anonymous
  July 28, 2007
  The comment has been removed

• Anonymous
  August 07, 2007
  " SOA is not something you buy. SOA is an architectural approach, not a product. Anyone saying anything

• Anonymous
  August 07, 2007
  " SOA is not something you buy. SOA is an architectural approach, not a product. Anyone saying anything

• Anonymous
  August 13, 2007
  So, I am totally thrilled in my new role at Neudesic , where today, I got to spend quite a bit of time

• Anonymous
  August 31, 2007
  Nick Most of the time the road stays the same size. Sometimes, however, the road on one side of the border is well plowed in snow, and the other side is not. :) Some services are a lot more responsive than others. :) Seriously, there is one road at the Brookline-Boston border where they put up a road block to prevent kids from using the road for racing. The barrier was large enough to prevent racing, but small enough to let the fire trucks manuover around it. The locals on the Brookline side of the border thought it was a good thing. The analogy with SOA is here you are crossing a trust domain. When you cross a trust domain, some times things are made difficult on purpose.

• Anonymous
  July 09, 2008
  This is 9th of a series. I haven’t really received much feedback. Please let me know if this is

• Anonymous
  December 02, 2008
  This is 9th of a series. I haven’t really received much feedback. Please let me know if this is useful, if posts too long, too abstract, your thoughts. Symptoms of a Problem, Diagnosis and Why SOA? Dynamic IT to Support the Agile Business and Business

• Anonymous
  December 02, 2008
  So, I am totally thrilled in my new role at Neudesic , where today, I got to spend quite a bit of time with one of our Distinquished Engineer, David Pallmann , the architect of our Neuron ESB . We're doing a lot of thinking and doing with SOA at Neudesic.

• Anonymous
  December 02, 2008
  My son, like the rest of kids his age, as well as many others is spending every waking hour reading the latest Potter book. Ruby/IronRuby/CLR/DLR Great news from John Lam of the first public drop of the IronRuby source code . IronRuby is licensed under

• Anonymous
  February 03, 2009
  This is 9th of a series. I haven’t really received much feedback. Please let me know if this is useful, if posts too long, too abstract, your thoughts. Symptoms of a Problem, Diagnosis and Why SOA? Dynamic IT to Support the Agile Business and Business