Cloud Computing Recipe: 1 Part Tech, 9 Parts Process

1 comment

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_DeutscheBOB DEUTSCHE
Intel

I recently participated in a meeting of Intel’s Enterprise Board of Advisors (EBOA) Data Center Working Group. During the call, one of the members—from a very large, multi-national company headquartered in Europe—mentioned that in their experience, cloud is more a change in process than a change in technology.

That made me think of our third fundamental truth of cloud computing strategy (and the one we’re discussing today):

Your cloud ecosystem is only as robust and adaptable as the sum of its parts.

If a stranger asked you to describe your business from end to end in 30 seconds, what would you say? You might describe it in terms of its enterprise architecture (EA), which can be a good way to understand your company as a series of connected parts.

According to Wikipedia, EA is “a rigorous description of the structure of an enterprise, which comprises enterprise components, the externally visible properties of these components, and the relationships between them. This description is comprehensive, including enterprise goals, business processes, roles, organizational structures, and organizational behaviors.”

Although there are variations used to describe the components of EA, I prefer to use those included in a framework known as The Open Group Architecture Framework (TOGAF), which includes four related but distinct architectural components. Here’s how we describe them at Intel:

Architecture Type Description
Business The business architecture serves as the interface between the needs of the enterprise as reflected in its work and the IT solutions that facilitate that business. The business processes serve as the foundation for a number of important architectural decisions in the balance of the enterprise architectural domains.
Data The data architecture is intended to promote information sharing and reuse in support of business processes across the enterprise. This is done via standard description and discovery of common data and the promotion of uniform data management practices.
Application Specifies the key elements of information systems used in executing its business processes. These elements include the services taxonomy and its components. They represent the organization’s application portfolio and identify the business systems that enable and support the execution of Intel’s business processes (outlined in the business architecture). The application architecture provides a cross-reference of capability or service.
Technical Describes current and future technology infrastructure and specific hardware and software technologies that support your corporate information systems. It provides guidance and standards for implementing technologies that are proven to work well with existing and planned technologies.

The robustness of an EA framework— by default, any activity such as cloud that requires use of these architectural components — is determined by an organization’s ability to use it. The robustness of your EA is generally measured as a factor of maturity. In mature organizations (defined on a 0 to 5 scale), the EA framework is a key component of success that links the value of the IT organization to the objectives of the enterprise. In practice though, your EA maturity can (like the attractiveness of your own reflection in the mirror) be hard to measure objectively.

The Innovation Value Institute’s (IVI) IT-Capability Maturity Framework for Enterprise Architecture Management suggests that to build an effective EA, you must be able to measure the maturity of people, planning, and practices. Maturity is measured against things like framework, process, value, governance, planning, organizational structure, skill sets, and communications.

Success Depends on EA Maturity

So, in terms of expectations for cloud execution in your organization (and with the caution that I consider mission-critical applications when I say this), your success, and likely your return on investment (ROI), are very much linked to the maturity of your EA. If you’re a somewhat immature organization, your cloud framework will likely reflect elements of this immaturity.

This is a topic on which I’m very interested in getting some feedback. I’d specifically welcome any examples from your own company, or other companies you’ve worked with that can either support or crush my ideas.

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.

For more information and any questions please feel free to contact me on LinkedIn.

For more background, see Bob’s previous posts:

Fundamental Truths of Enterprise Cloud Strategy

Pickett’s Charge, Cloud Strategy and You

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.

Add Your Comments

  • (will not be published)

One Comment