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.
On July 3, 1863, at around 2:30 p.m., 13,000 Confederate troops — under the command of General James Longstreet and led by division commanders J. Johnston Pettigrew and George Pickett — began an infantry assault on heavily-fortified Union positions on Cemetery Ridge. The assault, known as Pickett’s Charge, required the Confederate troops to cross three-quarters of a mile of open ground in an area surrounded by elevated Union artillery (which is tactically not so good). It occurred on the third day of the Battle of Gettysburg, a pivotal battle in the U.S. Civil War.
Pickett’s divisions had the unenviable role of being ordered to lead a direct frontal assault on the Union positions. As was sadly predictable, Pickett lost about 3,000 men (more than half of his division, including all 15 regimental commanders) and failed to achieve his objective.
Why did General Robert E. Lee, commander of the Army of Northern Virginia and General Longstreet’s superior, order Pickett’s Charge? The reasons remain a mystery and are debated even today. While the overall objective of the charge was clear (removing the Union forces from Cemetery Ridge), the Union forces held all the advantages in the battle. Victory would clearly be difficult—if not impossible.
You may wonder what a battle fought in the American Civil War has to do with cloud computing. That’s a valid point. The answer circles back to the second of eight fundamental truths of corporate cloud strategy that I identified and began to discuss in my last post. Again, here are those inviolable cornerstones of cloud corporate 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.
Fundamental Truth No. 2: Cloud is a Top-Down Architectural Framework that Binds Strategy with Solutions Development.
At a macro level, Intel IT views architecture at three levels, with each succeeding level defining and validating the actions of its successor:
|Strategic||The longer-term (usually 18 months to five years) articulation of the context, priorities, and plans that set the boundary conditions and road map for developing a tactical architecture over a prescribed time period.Conceptual in nature, it comprehends the high-level roles, capabilities, and processes to achieve the end state. It is the most abstract of the architectural types, with a goal of establishing strategic direction.|
|Reference||Provides a template solution for an architecture specific to a particular domain. Its aim is to stress commonalty in areas such as vocabulary, boundaries, and guidelines to promote:
Reference architecture is characterized by a medium level of abstraction, with the goal of identifying and standardizing solutions. Its artifacts form a starting point for solution architecture development. These may range from architectural patterns, mechanisms, and frameworks to complete systems with known characteristics. They may be applicable for a broad class of systems spanning domains or have a narrower focus.
|Solution/Service||Describes the scope and design of a change in business functionality. These are normally used to constrain and guide program/project design and implementation. The solution or service architecture is not constrained to changes only; in some cases, it can identify a gap and develop a solution to improve the efficiency of existing/ongoing business functionality.
•A solution architecture must align with the strategic architecture and should reuse or align to the reference architecture as much as possible.
•Service architecture is an architectural strategy that aims to isolate and separate the consumption of business functionality from the provisioning of a function through commonly-defined service contracts.
In a perfect world, where strategy is always defined by a smooth flow of business planning backed by infallible leadership, the model should work well. Unfortunately, as Pickett discovered, this isn’t always the case in real life. Arguably, the decision to engage in a frontal assault on the Union fortifications on Cemetery Ridge offered a direct solution to a problem.
Whether General Lee tactically considered the assault as part of something more strategic is a point argued by military historians. Unfortunately, and as shown by the catastrophic outcome, the loss of troops was so great in this one battle that the Confederacy not only lost the Gettysburg campaign, but it never recovered. Does this outcome validate our conclusion that if one element of an enterprise strategy changes, it automatically impacts the others? It’s your call.
A recent Forrester research paper authored by Frank E. Gillett and titled Navigating The Shifts In Computing Infrastructure Markets concludes that end users (called informal buyers) drive cloud infrastructure as a service (IaaS) adoption. These informal buyers are, as described in my post on the cloud strategy objectives of a fictitious VP of sales, focused on solution-level strategy. Enterprise strategy isn’t their concern. It’s like what happened during Pickett’s Charge. A data center/IT organization’s ability to navigate the difficult open ground between a business-unit-based cloud solution and a more strategic perspective comes down to factors of leadership, relationships with business groups, and, to a degree, simple luck.
In future posts, I’ll continue to explain these fundamental truths. As always, please join the discussion on this topic or anything I’ve said in my previous posts. If you’re shy about contributing in the public discussion, you can reach me via LinkedIn.
Until next time.
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.