Monthly Archives: April 2011

A Concise List of Business Use Cases for Cloud Computing

This blog entry can also be seen at: http://blogs.smartronix.com/?p=114

At the upcoming Interop Las Vegas Show (5/10/2011) I’m presenting “A Roadmap for Transitioning to Cloud Computing”. One of the key steps in my roadmap is identifying a business use case for cloud computing. I started with a quick search on the topic to see what others were offering up as use cases and came upon two well-defined documents, NIST’s Cloud Computing Use Cases and the Open Cloud Manifesto’s Cloud Computing Use Cases Version 4. Both of these documents have a wealth of information and each approach the problem domain from different angles. However, I still didn’t see a concise set of business cases that rapidly illustrate the problem domain for which cloud computing provides a solution. Hence, a great reason for a blog entry!
While I’m sure there’s some that I will miss, the ones that I readily discuss with customers are:

  • Reduce Costs. Okay, saying reduce costs and cloud in the same sentence is like saying it’s hot in the Moave Desert. The business use case for costs surrounding cloud computing is multi-faceted and based on your deployment model (e.g. public, private, hybrid). At a high-level, in certain cases and depending upon the overall utilization of compute resources in your own data center you could save money using public cloud because you only pay for the quantity of compute resources you need when you need it. Of course, if you’re seeking to develop a net new environment, public cloud options allow you to respond to opportunities more quickly without having to first fund a complete data center prior to delivering the service, which is a great financial benefit, but not really costs savings. Finally, private cloud environments will provide savings over traditional data center designs by using lower power, require less cooling, require less headcount to support and delivering the same or better performance with fewer resources. There’s a lot more meat on these bones, but for purposes of this entry, I’ll stop here.
  • Scale Out. There are certain times where scaling out is more effective than simply scaling up. Scaling up allows more users to be satisfied by a given environment, but has inherent levels of saturation, typically based on the size of the network. Scaling out allows more users to be satisfied simultaneously. A good analogy is scale up is to serial as scale out is to parallel. By spreading the demand across more environments, there is greater resiliency in the overall solution and you are placing less load on a single environment leading to greater performance. Cloud computing makes it easier to develop solutions that can scale out as well as up. Of note, scale out business case incorporates what the market is calling “Big Data”. Big Data requires massive parallel processes for storage and analytics that requires the ability scale up and out to support.
  • Elasticity. When hardware is acquired for the purposes of supporting a single application or solution it is typically sized for some growth, but mostly static in design. That is when the application is not being used, for example from 8pm to 6am the next morning, it is very difficult to a) turn that hardware off so it is not using power and b) repurpose that same equipment to support other functions, such as large batch jobs in that same time period. Elasticity put control in the hands of the cloud services consumer over where compute resources will be applied and when they will be applied.
  • Disaster Recovery (DR) / Continuity-of-Operations (COOP). The cloud simplifies the ability for organizations to develop cold, warm and hot disaster recovery sites at a reasonable cost. In the past, DR/COOP was a significant overhead, in some cases, requiring double the amount of hardware to be acquired for any single solution. Depending upon need, the cloud can provide various levels of DR/COOP support up to and including active-active failover scenarios.
  • Mobile/Secure Computing. While mobile computing does not require cloud computing, public cloud and hybrid cloud architectures can be very effective for rolling out mobile computing solutions. The main benefit of this architecture is to create a scalable and responsive application for mobile devices that operates in a separate security domain from the data and other key business applications. In essence, one could say that the use case here is creating advanced security architectures that better protect critical business IT assets by simplifying the development of hybrid architectures that are loosely-coupled.
  • Community Cloud. Some clouds are designed specifically to support the needs of a certain communities, for example, many service providers are now developing Federal Community Clouds to support the needs of the US Federal government to operate in a domain that is physically separated and meets specific security requirements and goes through the government’s certification processes. In this case, the business case is to leverage the body of work that has already been provided to deliver applications more quickly and more effectively. In essence, this use case could fall under cost savings because taking advantage of this effort significantly reduces the cost of deploying the application. However, it’s important enough to stand alone since the community may operate outside the bounds of the business itself, such as a standards body or non-profit agency.

If others have business cases that were not explained here and that are not a derivative benefit of one the business cases already defined here I would love to hear from you.

Update: Here’s a couple of additional business cases sent to me by Jeff Schneider.

  • Improved Time-to-Market / Agility. This was touched upon by a couple of the aforementioned use cases, but certainly deserves its own category. Sometimes solution and/or application delivery can be impeded by acquisition of the environment for development. This includes development, testing, and staging that occurs before deployment. The cloud is an excellent resource for support of the software development life cycle. Of course, the ability to transition the staging environment into a production environment with a some small scripting or a few flicks oft the mouse can dramatically speed time to market/completion of a solution.
  • Improved Contract Terms. Jeff’s point on this was that the cloud offers better terms than traditional managed service providers (MSP). Businesses looking for greater flexibility and shorter commitment periods will certainly gain by using the cloud in these circumstances.

Who’s Not Doing Enterprise Architecture?

Today, Jason Bloomberg of ZapThink released a blog entry entitled, “Why Nobody is Doing Enterprise Architecture”. A key point in the article is the statement, “Enterprises aren’t architected at all. They are grown.” Bloomberg goes on to describe that architects don’t terraform enterprises, but establish a framework for growth. I believe there is an aspect of this argument that is correct, however, I would argue that the issue is not with the activity, but with the name.

I met with Jim Stikeleather at the Department of Energy Information Management Conference in mid-March (2011). Jim is the Chief Innovation Officer for Dell Services and for those old enough to remember a founder of Technical Resource Connection (TRC), which was acquired by Perot Systems and one of the premier architecture and distributed computing shops during the mid-90’s. Jim and I had this exact conversation and my take on it was that business does not value enterprise architecture because it doesn’t understand enterprise architecture. That is, enterprise architecture itself is a poorly-defined and weakly agreed upon practice, but it is occurring.

I reiterated a story to Jim that I met with a customer that was looking at their infrastructure from a traditional siloed perspective. They were evaluating the network looking for performance optimizations and then would evaluate the servers and then the applications. I explained to them that they would certainly find things at each layer that they could improve, but that they would not see significant improvements if they didn’t examine the architecture in a holistic manner seeking to understand how the applications operating on the servers impacted the network. The customer looked at me like I had just explained to him out he could cure infections with Penicillin and turned to his staff and recommended to refocus their approach at improvement by looking at multiple dimensions at once.

Now, as far as I was concerned I had just recommended an enterprise architecture approach toward infrastructure optimization, but I never officially called it that with the customer and the customer immediately recognized the value. To wit, I recommended to Jim that once again terminology is getting in the way of value and that perhaps a better name for enterprise architecture might be multi-dimensional architecture. This latter terminology better captures the essence of the activity and doesn’t tie it to a particular scope—it can be as large or as small as it needs to be to accomplish the mission.

I believe that businesses engage in multi-dimensional architecture all the time. They design solutions that contain business processes, workflows, applications, user experiences, network connectivity, failover/recovery, etc. What’s more they consider the impact of any one particular aspect of the system on the rest of the system as a whole. To me that is what was designated by the term enterprise architecture when it was first, poorly, coined.