Architecture and the World of Cloud Computing

By Sheppard Narkier October 14, 2013

chrysWhat do The Chrysler Building and a Shantytown in an under developed area have in common? Hard to believe but the construction of each  are built using architectural concepts. The Chrysler Building’s architectural aura is obvious, while the shanty town appears chaotic and devoid of all structure – but there are implicit principles guiding its creation. This dichotomy begs the question, what is architecture and how does it relate to how we build in general, and its relevance to the systems we design?

In a very influential paper  titled “Big Ball of Mud”, Brian Foote and Josef Yoder discussed the state of architecture, specifically mentioning shanty town architecture as a concept. Coincidentally, changes to IT caused by the internet revolution, the push towards Linux and commodity platforms, the decentralization of IT, social media adoption and  the “bring your own device to work” wave has left many IT organizations little time to step back and figure out how to fix a growing morass of systems.

Foote and Yoder emphasize that the tendency to create shanty towns and balls of mud is “dictated by expediency rather than design”, but “its enduring popularity cannot be just a disregard for architecture”, there are motives that are not obvious. In their description of shanty towns, the duo argues that “despite their distasteful appearance there are forces that conspire to promote their emergence anyway”. In particular they point out that Shanty Towns:

  • Are built from common inexpensive materials and simple tools, using shantyrelatively unskilled labor, with the construction and maintenance of each unit being  labor intensive
  • Each unit is primarily maintained by its “owners” and therefore, each owner must be a jack of all trades.
  • There is little concern for infrastructure because it requires coordination and capital along with specialized resources and skills. Nonetheless there are rules of thumb regarding sewage and egress, but these rules are stretched as the shanty town grows.
  • There is little emphasis on planning or the regulation of growth. Shanty Towns emerge when there is a need for housing, and a surplus of unskilled labor, along with a lack of capital investment. The bottom line is that they fulfill an immediate local need by bringing available resources to bear on the problem, quickly.

Foote and Yoder argued that most software systems are in fact architectural shanty towns. So here we are 14 years later. How does this relate to the concept of architectural principles which are more clearly evident in the Chrysler Building?

Many of the systems built after 1999 were subject to similar driving forces that built shanty towns; (e.g. expedience). The very real fear of being left behind during the initial internet rush caused many large organizations to throw money at the localized problem and build multiple platforms, often one for each department, just to ensure that a presence was established. When the bubble burst, the money dried up and the layoffs began, and many systems were left with little support. The subsequent cloudsconsolidation and cleanup happened, at best, in a piecemeal fashion while other driving forces took hold. These days everyone is trying to mitigate the pain by moving these legacy systems to the cloud. In general the practice of Systems Architecture has been kept in the shadows too long, maligned as a bureaucratic time waster or trivialized by a set of outmoded drawings. IT architecture is not an afterthought; it is the foundation for IT sanity.

What is Architecture and Why is it Important?

The Software Engineering Institute , a very influential thought leader throughout IT, has very strong opinions about architecture, based upon their field work with thousands of organizations. Here are some of their findings, extracted from book titled Software Architecture in Practice:

  • Architecture and purpose– there is no such thing as an inherently good or download (1)bad architecture, instead architectures are either more or less fit for some stated purpose.(e.g. a 3 tier application might work for an enterprise wide query based system, but is the wrong fit for embedded avionics control). The key message is that architectures can be evaluated but only in the context of the specific goals, these goals are often stated as qualities of the architecture. Note how the goals of a shanty town architecture, which emerges over time, can be considered purpose directed based upon its goals.
  • Architecture as intellectual property: An understandable architecture that is a basis for communication, evolution and decision making has more lasting value than any reusable code base in the systems it describes. The reason is simple, specific technology changes, rendering specific code less useful over time. A traceable set of architecture artifacts age better than code, if it is kept as a relevant communication device, with clear definitions and articulated decisions.

There are three fundamental reasons that Software Architecture is important and not a mere bureaucratic exercise.

  • Communication among stakeholders– Software Architecture represents a common abstraction of a system that most if not all of the systems stakeholders can use as a basis for communication
  • Early design decisions Software Architecture represents the earliest design decisions about a system (e.g. messaging , security, scalability), and these early decisions carry a greater weight on the outcome of the system than any subsequent micro design or coding efforts. Mistakes, tradeoffs and assumptions have a profound effect on the outcome when decided upon or caught in this stage. The cost of catching a mistake in later phases of development (e.g. coding, testing, rollout, migration) rise exponentially.
  • Transferable abstraction of a system– Software Architecture constitutes a relatively small, intellectually graspable model for how a system is structured and how its elements work together, and this model is transferable across systems and disparate stakeholders with different domains of expertise.

Architecture in the World of Cloud Computing

As we view the current landscape of cloud providers and consumers, there is a subtleimages (1) shift in the buying patterns in this new “gold rush” era. At first, cheap infrastructure was made available to those who could make their applications work in this model; this phase has often been called Infrastructure as a Service (IaaS).

Consumers now realize that IaaS is insufficient for all of their needs and Platform as a Service (PaaS) is beginning to take hold in the marketplace. A good example of a PaaS offering could be a specific printing platform that can be rented for 3 days a month to produce millions of client statements. Normally, client owned and dedicated hardware for that workload, would sit dormant for 27 days until needed, so this is a perfect value proposition for consumers and suppliers.

This kind of platform requires that consumers have increased responsibilities, as they must ensure that the data is ready to be shipped securely and their applications can be run remotely on virtualized commodity hardware through standard scripts and interfaces. If the application architecture is not well understood, then deployment and scaling options will be hard to configure. If the application needs to change, and its construction and behavior is not understood, it may be impossible to virtualize it, making a cloud deployment impossible.

Architecture and Cloud Trends

At VMworld Europe this week, some important themes will be discussed regarding IT transformation. Some of the most pertinent to this architecture blog include Software Defined Data Center, Software Defined Storage, along with Management and Orchestration of applications. As one thinks about some of these ideas, the true value of a well-defined architecture across systems becomes clearer. By contrast, without abstraction and a clear understanding of an application, how could any organization attempt to achieve a key goal, such as: Defining Performance-optimized, capacity-optimized platforms that address availability and scalability requirements for mission critical enterprise workloads and truly transform their IT?

About Sheppard Narkier

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

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

4 thoughts on “Architecture and the World of Cloud Computing

  1. Great blog Sheppard – I’m really enjoying the series and the journey you are taking through architectural theory. As I read this article, the Fit-for-Purpose concept continued to be in the forefront of my mind, particularly that there is no such thing as good or bad architecture. For example, there are material differences in the business architecture of a CPG firm and a Services-based firm. While some activities and processes are paralleled (AR, AP, etc.) others are vastly contrasted (Supply Chain, Logistics, etc.). Both may be very well suited for their specific business model (think goals), but neither would be efficient or effective for the others’ business model. The Fit-for-Purpose mindset can (and should) be applied up and down the enterprise architecture model.

    • Thanks Pete.
      what has been amazing to me is that in most other aspects of our lives we fundamentally understand this principle. For example we don’t use a convertible sports car to haul landscape rocks, nor do we use pick up trucks to haul kids around to soccer practice. The list of examples is endless. Yet for some reason the one – type – fits all mentality has an unhealthy grasp in IT’S thinking process.

    • Thanks Caleb, I am trying to grow the conversation around the importance of architecture in the cloud decision process. Would like to hear your thoughts on sustainability that I am blogging about in 2014