Who's Architecting the Cloud?
By Ron Schmelzer
This guest post comes courtesy of ZapThink. Ron Schmelzer is a senior analyst at ZapThink. You can reach him here.
As the hype cycle for the cloud computing continues to gather steam, an increasing number of end users are starting to see the silver lining, while others are simply lost in the fog. It is clear that the debate over the definition, business model, and
benefits of cloud will continue for some time, but it is also clear that the sluggish economic environment is increasing the appeal of having someone else pay for the robust infrastructure needed to run one’s applications. Yet, all this talk of leveraging cloud capabilities, or perhaps even building one’s own cloud, whether for public or private consumption, introduces thorny problems. How can we make sure that the cloud will bring us closer to the heavenly vision of IT we search for rather than a fog that hides a complex mess? Who will make sure that the cloud vision isn’t just another reinterpretation of the Software-as-a-Service (SaaS), Application Service Provider (ASP), grid and utility computing model that provided some technical answers but didn’t simplify anything for the internal organization? Who is architecting this mess?
Architecture and the Utility Services Cloud
Most of the time, when people point to practical, in-production examples of cloud computing efforts, they are talking about the sorts of utility services offered by Amazon.com, Google, Salesforce.com, and others. The Services offered in these clouds are not built with any particular application in mind, but rather whole categories of applications. For obvious reasons, these cloud providers seek to leverage economies of scale by serving the largest possible audience using a handful of highly reusable Services, where reuse is defined by usage in multiple contexts. For these cloud providers, the utility Services simultaneously provide a source of revenue as well as a platform their customers use to replace proprietary, in-house infrastructure and middleware.
Given that the emphasis of these Services is to meet the needs of a large and
For obvious reasons, these cloud providers seek to leverage economies of scale by serving the largest possible audience using a handful of highly reusable Services, where reuse is defined by usage in multiple contexts.
continuously growing audience who have diverse requirements, the utility cloud provider’s primary focus is placed on infrastructural concerns. As a result, it’s the infrastructure technologists who are in charge of this cloud. When the “architecture team” meets in these cloud providers, what problems are they aiming to solve? Business problems? Certainly not. In most cases, the architecture teams for these providers (of which we’ve been privy to a number of conversations), focus almost exclusively on technology and infrastructural concerns. Key conversations revolve around performance optimization, implementation change management, optimizing the balance between efficiency and cost, meeting reliability and uptime concerns, and addressing privacy, security, and governance issues.
Where’s the business in all this? The answer: nowhere. Where should the business be in all this? That’s a tough question to answer because without Service consumers, the cloud wouldn’t exist at all. However, it is not the goal of the cloud provider to meet any specific business requirements. Rather, the requirements are aggregated to create a business “persona” that is the focus of continual Service releases. In this manner, one could argue that there are no enterprise architects providing any value in this environment. The most pervasive form of architecture done in these environments is more akin to Information Technology Infrastructure Library (ITIL) approaches rather than any form of enterprise architecture (EA). Utility clouds are the domain of infrastructure experts, not business-IT gap bridgers or process modelers, and one could argue that this status quo will probably never change.
Architecture and the Application (Process) Cloud
However, the utility Service vision of the cloud is not the only one. Indeed, we’re starting to see the emergence of application and process clouds that provide the same infrastructural and economic benefits of clouds, but applied to process-specific concerns. These cloud providers enable the outsourcing of entire processes that run in a virtualized cloud environment as a way of handling variability in scale. For example, an insurance company can use a cloud provider's claims processing Service when their internal capacity is not sufficient to meet demand. As long as the process is Service-oriented, this approach works well and leverages the strength of the cloud's abstract infrastructure capability while staying focused on the process. This way, an organization can have its internal processes augmented by third-party cloud processes. For example, insurance clouds provide elastic capabilities for insurance applications as demand ebbs and flows. Likewise, banking, supply chain, retail, and other process-specific clouds provide cloud computing benefits for specific groups of business users.
In this environment, the cloud provider needs to balance two different, but equal concerns:
. . . the job of the enterprise architecture team is to optimize the conceptual equation of producing the smallest set of Services that meet the largest number of business processes.
infrastructural issues of the sort described above, and the challenge of meeting continuously changing business requirements. When application-specific cloud provider architect groups meet, their conversations look very different from utility Service cloud providers. Rather than focusing on infrastructural issues as they try to meet the common denominator of needs (“speeds and feeds”), the conversation usually revolves around how the team will meet new business process requirements given the existing set of Services and infrastructure. In many ways, these teams have a true EA conversation: the continuously changing and diverse business requirements on the one hand, and the technical capabilities on the other. These EA conversations invoke aspects of Agile Methodologies and EA frameworks more so than ITIL. Rather than trying to minimize the set of business processes handled by the cloud, they seek to continuously expand the universe of processes addressed.
As we often discuss in our Licensed ZapThink Architect (LZA) SOA training courses, the job of the enterprise architecture team is to optimize the conceptual equation of producing the smallest set of Services that meet the largest number of business processes. You don’t want to produce too many Services, otherwise there’s waste. Likewise, you don’t want to produce too few Services as that constrains the number of business processes you can address. As new Services are introduced, the universe of business processes addressed likewise increases. Since application / process-specific cloud providers are businesses that must justify their existence by staying focused on the business without impacting existing operations. Sounds like something all enterprise architect teams should do, no?
The ZapThink Take
In many ways, the discussion of architecture has been given short shrift in cloud computing conversations. In much the same way that the Service-Oriented Architecture (SOA) conversation degenerated into a conversation about the (often unnecessary) Enterprise Services Bus (ESB), the cloud conversation is degenerating into one about the infrastructure needed to handle scalable Service provider volume. And where is the conversation about the business process? Unless you are planning to build a general-purpose Service provider cloud to compete with the likes of Amazon.com and others, you should be focused on where the opportunity is: in the process. And to focus on the process while keeping an eye on the technology requires an enterprise architecture perspective.
The mistake that many cloud-consuming companies are making is that the cloud is giving them an excuse not to think about enterprise architecture at all.
Once again, the refrain is that SOA is not something you buy, but something you do. Perhaps we can start hearing the same mantra with cloud computing?
The thought going through the head of many a supposed architect is: “whew, thank goodness we’re putting this in the cloud so that I don’t have to invest in architecture.” Wow, what a mistake. These companies will be in for a rude awakening when they realize that all they’ve done is shifted their internal mess, which at least they have some control and visibility over, to an external mess that they have less control over. Enterprise architecture doesn’t go away simply because someone else is hosting or providing your Services. Organizations that want to have any chance of improving their agility, flexibility, reliability, and performance need to be in charge of their own architecture. There is no other option.
Given that too few cloud computing providers have your business in mind when they architect their solutions, and the ones that have a process-specific business model and approach aren’t concerned with your specific business, it lands upon the laps of enterprise architects within the organization to plan, manage, and govern their own architecture. Once again, the refrain is that SOA is not something you buy, but something you do. Perhaps we can start hearing the same mantra with cloud computing? Or will the cloud succumb to the same short-sighted, market pressure that doomed the ASP model and still plagues SaaS approaches? It’s not up to vendors to answer this question. It’s up to you … the enterprise architect. There are no short-cuts to EA. This guest post comes courtesy of ZapThink. Ron Schmelzer, a senior analyst at ZapThink, can be reached here.
In need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification. Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.