Bob Deutsche joined Intel in 2004 and has more than 25 years of business and IT experience in positions that ranged from data center operations to software development to CIO. He can be found online at Bob Deutsche on the Intel Server Room.
BOB DEUTSCHEIntel
Besides my family (and of course, Intel), I have three passions. One is high-performance aircraft (current generation to early 1930s); the second is just about anything powered by an internal combustion engine. My third passion is an insatiable desire to understand the history of both. For those who know me personally (or read my previous industry perspective on cloud computing strategy & lessons that referenced Ford’s experience at the 1964 to 1966 24-Heures du Mans with its GT40), this revelation is not much of a surprise. Once again, I will attempt to make a point about the cloud using historical analogies from the automotive vertical.
Henry Ford And Service-Oriented Taxonomies?
So, what exactly does Henry Ford’s Model T have in common with my fourth truth of corporate cloud strategy: services-oriented taxonomy is not optional?
Ford’s Model T became available in 1908. Due to its low initial price (USD $950), demand was brisk. When Ford's auto first went into the marketplace, it was assembled by a team of two or three workers who would collect the parts they needed and start the assembly process. If a part didn’t fit, they used hammers, crowbars, files, and plain old brute strength to coerce it into place until they had formed the end product (Think of it as a service).
There were two fundamental problems with this approach. The first was that the time and labor it took to complete each Model T varied. The second issue involved service life cycle considerations. If something breaks, and if every part is unique, how do I fix it? And what will it cost to repair?
Henry Ford’s response to these problems boiled down to standardization and interchangeable parts. Every piece became exactly the same as its successor and predecessor, and fit with all the others into sub-assemblies (i.e., building blocks). In a sense, the manufacturing methods Ford used for the Model T were the great-grandfathers of a concept that we refer to as a services-based architecture framework.
At a strategic level, a service-based architecture framework has four layers:
- Defining and coordinating business processes and workflows
- Replacing functional silos with networks of services
- Policy-based distributed and automated management
- Building blocks (grouped into service catalogs) that provide a cost-effective, standardized set of capabilities for business process execution, user experience, governance, security, management, communication, and virtualization
Cloud Expectations: Cut Costs and Time to Deliver
With that foundation, let’s briefly revisit some of the promises of the cloud. Although definitions vary greatly, cloud computing is generally considered to be the delivery of information capabilities (i.e., technical infrastructure, applications, or services) over the Internet by third-party-managed data centers. Today, cloud business models include software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS)—all delivered via private, hybrid, or public frameworks. Part of the cloud promise includes a commitment to cutting both costs and the time it takes to respond to business change.
If you compare the overall promises of the cloud to the architectural goals of a services-based taxonomy, you might see some similarities. This is where the discussion becomes harder. If you look at the success and history of various service-oriented infrastructure and architecture (i.e., SOI/SOA) efforts, you’ll likely find a recurring theme I refer to as the “field of dreams”. If you remember the excellent movie of the same name (it helps if you’re a baseball fan whose roots are in Chicago), it’s about an Iowa corn farmer who hears voices that tell him to build a baseball diamond in his fields. He is spurred on by the message: “If you build it, they will come.”
Unlike the movie, where “they” (the old-time players of the farmer’s dreams) did come after the ball field was built, many enterprises began the SOI/SOA journey only to find out that it was significantly harder than they expected. As the figure below shows, there’s a lifecycle you can associate with migrating to a services-based framework. In my experience, not many organizations actually reached the service catalog stage. Those that did, in general, had a hard time sustaining the effort.
Evolving Cloud Framework
Click graphic to enlarge.
As I’ve stated in an earlier post, I don’t envision the evolving cloud framework as absolute in a typical enterprise. More likely, and driven by data security considerations, it will evolve as a blend of business applications delivered:
• From both the public and private cloud
• Through traditional infrastructure
Given this scenario, integrating services (e.g., business process execution, user experience, governance, security, management, and communication) will be a necessity. While it may be possible to handle this integration on a case-by-case basis, I’m quickly brought back to Henry Ford’s Model T and the disadvantages of custom-fitting each component of the architecture to the next. I simply don’t see a clear path for cloud to fully deliver on its promise without some kind of services-based architecture running on the back end of the enterprise.
I freely admit I may not be seeing all the elements that come into play. In fact, I’m hoping a reader will provide feedback that can help me address some of the questions I have. I’d specifically welcome any examples from your own company, or other companies you’ve worked with, that can either support or crush my conclusions.
Finally, here’s our complete list of the inviolable, fundamental truths of corporate cloud strategy:
- Large-scale transformation to cloud computing, including your critical business systems, is a journey that will take you from eight to 10 years.
- Cloud is a top-down architectural framework that binds strategy with solutions development.
- Your cloud ecosystem is only as robust and adaptable as the sum of its parts.
- Services-oriented enterprise taxonomy is not optional.
- Cloud is a verb, not a noun.
- Technology-driven business practices often circumvent government regulations, but legal/government policy standards will dictate cloud’s success.
- Bandwidth and data transmission may not always be as inexpensive and unencumbered as they are today (geo-sensitive considerations).
- Altruistic motives do not generally keep the lights on.
In the future, I’ll continue to detail these fundamental truths. As always, please join in the discussion on today’s topic or anything I’ve said in my previous posts.
Related Posts from Bob Deutsche:
Cloud Computing Recipe: 1 Part Tech, 9 Parts Process
Cloud Strategy, Pickett's Charge, and You
Let's Get Real About the Cloud
For more information or to discuss any questions, please feel free to comment below or contact Bob on LinkedIn.
Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.
