Head in the cloud, Feet on the ground: an article about the cloud

My brother in arms Eugenio and I wrote an article a few weeks back discussing the opportunity that "the cloud" offers in terms of IT optimization. Of course this is not the only opportunity that "the cloud" will offer, but it is likely to be one of the most used, at least initially and especially in the current economical climate.

You can find the article titled: Head in the cloud, Feet on the ground, in the freshly released Architect Journal (page 16 of the .pdf file, page # 14 of the journal)

To give you an idea of what the article is about, here is a excerpt.  image

From a pure economical perspective, driving a car makes very little sense. It is one of the most expensive ways of moving a unit of mass over a unit of distance. If this is so expensive, compared to virtually all other transportation means (public transport, trains, or even planes), why are so many people driving cars? The answer is quite simple: control. Setting aside the status symbol element of a car, by choosing the car as a means of transportation, a person has full control on when to depart, which route to travel (scenic or highway), and maybe most appealing, the journey can start from the garage to the final destination without having to rely on external parties. Let’s contrast that with taking the train. Trains have strict schedules, finite routes, depart and arrive only at train stations, might have loud fellow passengers, are prone to go on strike. But, of course, the train is cheaper and you don’t have to drive. So which is one is better? It depends if you are optimizing for cost or for control.

Let’s continue this transportation analogy and look at freight trains. Under the right circumstances, typically long distances and bulk freight, transport by rail is more economic and energy efficient than pretty much anything else. For example, on June 21, 2001 a train more than seven kilometers long, comprising 682 ore cars made the Newman-Port Hedland trip in Western Australia. It is hard to beat such economy of scale. It is important to note, however, that this amazing feat was possible only at the expense of two particular elements: choice of destination and type of goods transported. Newman and Port Hedland were the only two cities that this train was capable of transporting ore to and from. Trying to transport ore to any other cities or transporting anything other than bulk would have required a different transportation method. By restricting the cities that the train can serve and restricting the type of content it can transport, this train was able to carry more than 650 wagons. If the same train was asked to transport both bulk and passengers as well as being able to serve all the cities of the western coast of Australia, the wagon count would have likely be reduced by at least an order of magnitude. 

The first key point we learn from the railroads is that high optimization can be achieved through specialization. Another way to think about it is that economy of scale is inversely proportional to the degree of freedom a system has. Restricting the degrees
of freedom (specializing the system) achieves economy of scale (optimization).
•   Lesson 1: The cloud can be seen as a specialized system with fewer degrees of freedom than the on-premises alternative, but can offer very high economy of scale. 

Of course, moving goods from only two places is not very interesting, even if you can do it very efficiently. This is why less optimized but more agile means of transport such as trucks are often used to transport smaller quantities of goods to more destinations.
  As demonstrated by post offices around the globe, their delivery network is a hybrid model including high economy of scale — point-to-point transportation (e.g. train between two major cities); medium economy of scale trucks — dispatching mail from the train station to the multiple regional centers; and very low economy of scale but super high flexibility, — delivery people on car, bike, or foot capable of reaching the most remote dwelling.
•   Lesson 2: By adopting a hybrid strategy, it is possible to tap into economy of scale where possible while maintaining flexibility and agility where necessary.

The final point we can learn from the railroads is the notion of efficient transloading. Transloading happens when goods are transferred from one means of transport to another; for example, from train to a truck as in the postal service scenario. Since a lot of cost can be involved in transloading when not done efficiently, it is commonly done in transloading hubs, where specialized equipment can facilitate the process. Another important innovation that lowered the transloading costs was the standard shipping container. By packaging all goods in a uniform shipping container, the friction between the different modes of transport was virtually removed and finer grained hybrid transportation networks could be built.

•   Lesson 3: Lowering the transloading costs through techniques such as transloading hubs and containerization allows a much finer grained optimization of a global system. In a world of low transloading costs, decisions no longer have to be based on the constraints of the global system. Instead, decisions can be optimized at the local subsystem without worrying about the impact on other subsystems.

  We call the application of these three key lessons
       (a) optimization through specialization,
       (b) hybrid strategy maximizing economy of scale where possible while maintaining flexibility and agility where necessary and
       (c) lowering transloading cost in the context of software architecture:
localized optimization through selective specialization or LOtSS.

The rest of this article is about applying LOtSS in an enterprise scenario (Big Pharma) and an ISV scenario (LitwareHR)       

FYI: some of this will also be used as the base of our Symposium at the PDC.

Enjoy! and as usual, feedback welcome.

Comments (1)

  1. Gianpolo makes the suggestion (lesson 2) that a hybrid model can add economies of scale – yet drawing from his example of the iron ore train rumbling across the scorched red earth of the Australian outback – for this specific application there is no more economical model than very large modes of transport (many examples in Australia).

    Perhaps the IT equivalent is the massive, high volume systems like airline registration which have to be centralised in order to share data in real-time.

    There are horses-for-courses and in some cases a hybrid model may simply fail to serve any particular group while trying to be "all things to all people".