This is the third in our series on preparing your IT organization to “operationalize” cloud initiatives — in other words taking control of what may well have heretofore been fragmentary and at times counter-productive experiments. Following last months’ discussion (Getting Started With Cloud – Where Should you Begin?) of the overarching issues surrounding cloud adoptions and cloud priorities in 2010, this column looks at actionable items to help you become sufficiently empowered to take control of the murky beast.
For related articles, visit Internet.com’s new cloud computing site.
By sampling through last month’s article on what other organizations are doing in cloud adoption, you probably noticed that there was a clear gradation from constituency-specific infrastructure (most popular) down to business applications with broad impact across an organization (least popular). And of course a lot in between such as SaaS adoptions for communications and apps such as e-mail.
Base Lining
So let’s start with a base lining. For cloud this comes in two flavors. The first is to do a comprehensive baseline of what’s already underway that’s cloud related. This should include internal and external cloud interdependencies, a documented list of “owners”, price points (when applicable) and any relevant SLAs or performance-related metrics. “Owners” should include both IT professionals directing internal virtualization initiatives as well as those managing relationships with external vendors.
This initial “cloud adoption” baseline may be very scattered in some organizations — a little bit of internal, data-center-centric “cloud” mixed in with some external, SaaS adoptions coming from IT and non-IT sources. Aside from the Jackson Pollock-like abstract expressionist art work that is likely to result from connecting all these dots, this initial baseline will give you a first-step for making further decisions.
- Which cloud adoptions are “working” and which are not, and which remain unmeasured?
- Which are costing you and which are not?
- Which have clear owners assigned?
- And which are most relevant to your broader service management initiatives?
Depending on what you see, you might want to create a “cloud Tsar” (call it what you will) reporting to you or one of your VPs. The role of this Tsar is to oversee those cloud-related initiatives that are not strategic to you, and ensure that even these have a minimum amount of accountability in terms of performance (SLAs), that their relationship to you and your organization is acceptable and clear, and that no further such initiatives will occur without checking with you or your cloud Tsar, first. If you get opposition, you can say that your goal “isn’t to stymie creative innovation, but to optimize it.” And since this is the truth, it doesn’t mean that you’re also running for political office.
Now let’s look at those aspects of cloud that you decide are strategic. In other words those that can help support critical business services that you own through more flexible and dynamic application infrastructure resources via internal and/or external cloud capabilities. And, by the way, making this “strategic”/“non-strategic” cut isn’t going to be a one-time decision, but something that may require re-evaluation every six months, as well as on an as-needed basis.
But far from being an enemy, cloud can be a real ally if used well in advancing your core business of delivering superior services to optimize business performance. Cloud can save you money. It can add resiliency to the performance of critical business applications. And it can allow you to be more responsive to end-consumers, application developers, and the business organizations you support.
Now, you’re ready to do your second act of base lining. This time the picture you draw should move a little closer to a Rembrandt with a more cohesive outline for answering a similar set of questions: ·
- Who are the customers and what is the business impact for your cloud initiatives?
- Who are the executive owners within IT for these initiatives?
- What is/was the pre-existing status of an application’s service performance prior to moving forward with cloud in terms of cost, performance, process efficiency, etc.?
- What are the expected outcomes in terms of improving the metrics for cost, performance, process efficiency?
- Who are the stakeholders within IT most impacted by these transitions?
- What changes in best practices, organization might be required?
- What technology gaps in service management and automation remain that might negatively impact the outcome (i.e., baseline your existing management capabilities prior to diving into the cloud)?
- What processes commitments (best practices) and SLAs can you expect from your external cloud service providers?
- How visible (or invisible) are your infrastructure and application interdependencies across internal and external cloud?
When you’re done, you should not only know where you are but where you can reasonably expect to go in terms of phase one cloud improvements. You should also have a communications strategy in place to ensure that both your IT organization and your customers are prepared for the transition. And this means not just a broadcast from you outward to the known universe, but a clear sense of how your own professionals, and their customers, will need to talk to each other in order to optimize this Brave New World.
Workloads?
I’d like to wrap up with a brief discussion of “workloads”. A term that gets used by many cloud providers and that, in itself, can be more confusing than enlightening in determining what’s “strategic” for cloud.
Workloads reflect specific processing requirements that can vary a great deal based on the application service they support. For instance, a single application service might have various software components resident on three separate physical servers or VMs: an application server, a middleware server, and a database server, each of which represents separate workload requirements.
Knowing how and where relevant applications and application components reside across an entire application ecosystem then becomes essential. Web 2.0 and SOA applications can multiply these complexities many times over. So you might look at the following application workload types before deciding where and how to go forward:
Processing intensive – e.g., high batch processing requirements for complex application queries.
Request intensive – highly interactive applications requiring fast response to many multiple requests at once.
Event driven – application services that respond to often unpredictable event streams.
Multiple application dependent – where many application components need to function with collective precision to support a single business transaction, e.g., across multiple databases, outwardly facing application servers, and middleware orchestration.
Multiple VMs on a single server – where high demand for one could easily disrupt performance on the other with no otherwise visible or logical connection.
Single user versus multi user interdependent – for instance, application development is often a single user, single constituency environment; in contrast to ERP and other applications.
Business critical, volume critical, or security critical – workloads which are very sensitive to business competitiveness or security/compliance issues are often those with the greatest perceived barriers to cloud adoptions. On the other hand, workloads subject to extremely high, unpredictable volumes can be natural targets for cloud because infrastructure resources can be dynamically reassigned based on need.
While the first two columns on cloud provided a wide range of useful reference points, I realize this one suggests a lot of tough thinking and hard work. So catch your breath. Once you’ve done all this, (and hopefully taken a little time off) you’re ready to seriously evaluate your management and technology requirements on a more granular level, invest in new solutions where needed, and negotiate with your cloud service providers. We’ll talk about these challenges next month.
Dennis Drogseth is VP of Boulder, Colo.-based Enterprise Management Associative, an industry research firm focused on IT management. Dennis can be reached at [email protected].