Google excludes scheduled maintenance from its Google Apps SLA, but not Google App Engine

Back in July of 2010, I wrote about how Cloud Service Providers exclude scheduled downtime from their service level agreements.  Last Friday, Google made a significant change to their SLA for Google Apps by removing scheduled downtime from their Google Apps SLA:

• Exclusion of scheduled downtime from availability SLA
• Exclusion of intermittent downtime (periods of less than 10 minutes) from availably SLA

Obviously, it is good news for Google Apps customers.  It highlights Google’s infrastructure & operational maturity (in this case, for Google Apps specifically).  

I also think the announcement is important, because it sets a higher standard for service delivery.  By raising the bar, Google also intensifies competitive pressure on service providers such as Microsoft to offer more robust Cloud services.  Ultimately, both customers & the industry should benefit from this.

However, as I discussed in my July post, for infrastructure & platform services such as Google App Engine for Business, scheduled maintenance still remains excluded in all SLAs:

• GAE: http://code.google.com/appengine/business/sla.html
• AWS: http://aws.amazon.com/agreement/
• Azure: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=72193dd2-eeaa-4054-93f6-f6b725cf76af&displaylang=en#QuickDetails
• RackSpace: http://www.rackspacecloud.com/legal/sla/
• GoGrid: http://www.gogrid.com/legal/sla.php
• …

It is 2011.  If we mark the beginning of Cloud Computing by the initial public release of EC2 (2006), I think enough time has passed for Cloud service providers to do a better job of managing planned outages in a non-service-disruptive way. 

--------
Sidebar - I am a regular user of AWS, GAE, Force.com… I have been using these services for more than a couple of years.  To be fair, I have never received any emails from any of the major cloud for scheduled downtime.  I have received a few from other service providers.  So, I would say that they are all doing a pretty good job operationally (a lot better than probably what most enterprises would do), and make sure the services are always up, and almost always perform well :-].  So, they just have it in the SLA agreements for legal protection & liability.   

Never-the-less, when it comes to migrating or designing enterprise solutions, depending on the application type and use-case, this can become an issue, and require both technical implementation & operations planning.

A review and analysis of IBM Test & Development Cloud, and opportunities

IBM finally GA'd its Development & Test Cloud last week: http://www.ibm.com/cloud/enterprise
In addition to a public cloud service offering, IBM is also providing an option to deploy such an infrastructure-as-a-service model on-premise (private cloud): http://www-935.ibm.com/services/us/index.wss/offering/midware/a1030965

I believe Cloud Computing is critical to IBM’s future growth.  It may even be the only solution to declining revenues in some of IBM’s business segments.    I will share some opinions below after a quick solution review.

The IBM cloud is built on Rational & Tivoli components.  Rational provides design, development, testing, and application lifecycle management & governance, and Tivoli enables automated resource provisioning & service management (self-service request management, performance monitoring, usage metering, billing):

IBM Test & Development Cloud

I think there is an opportunity for IBM’s Cloud to be a huge success for the following reasons:

Virtualization
For IBM public cloud, KVM powers the virtualization layer.  The on-premise solution is virtualization technology agnostic: KVM, PowerVM, and VMWare.

• In a previous post, I made the observation that most large enterprises cannot standardize on a single virtualization infrastructure.  They have to deal with multiple virtualization technologies.   While there seems to be some gaps in IBM’s on-premise solution (ex. no Xen or Hyper-V support), I think IBM is in a much better position than VMWare or Oracle to unify management across different virtualization technologies.   This would be a a big competitive differentiator and value to the enterprise.
• Secondly, in the world of Cloud Computing, vendors are primarily focused on x-86 platform.  All other platforms are ignored.  If IBM can extend their public cloud to support pSeries and maybe even zSeries (mainframe-as-a-service ?), this would also be a huge competitive differentiator.  This would allow more workloads to be moved to the Cloud and benefit customers.  As an example, customers would be able to move some of their mainframe batch jobs to the Cloud to save MIPS.

OS Coverage
The initial set of OS images are limited. In the initial public offering, IBM only offers Red Hat & Novell images.  There are no Windows images (yet ?).  I think it is just a matter of time for IBM to offer Windows images on their public cloud.

As I said above, the on-premise solution can support AIX images now, and maybe zOS in the near future (why not?).  If IBM were to offer AIX & zOS VMs in the Cloud, it would not only be able to realize a new revenue stream and possibly revive that segment, but keep customers from migrating to other platforms.  I think this could open new opportunities.  The challenge is how to do this in a balanced way without cannibalizing the existing customer base, and creating incentives for IBM sales teams to execute after those opportunities.

Pricing
IBM’s cloud “infrastructure pricing” is competitive to AWS.  However, for IBM software, there are different licensing & subscription options:

Customer scenarios	Software	Infrastructure
	Charge	Charge
You "bring your own IBM license" ("BYOL")	Prepaid for software license	Per VM per hour
You own an IBM software license and can use the pre-built IBM images in the portal catalog
You "pay-as-you-go" ("PAYG")	Per Image per hour	Per VM per hour
You choose the desired software, accept the license terms online, and receive a monthly usage bill
You "bring your own software and licenses"	Prepaid for software licenses	Per VM per hour
You bring your own software or software for which you hold valid licenses and install them on the servers you provision
You want to test "pre-release" software	No charge for restricted use	Per VM per hr
From time to time, pre-released software images will be made available on a temporary basis for test (non-productive) use
You are an eligible ISV/SI developer	No charge or by usage	Per VM per hr
You can use selected IBM "development use only" ("DUO") software for development, test, proof of concept and sales demos on the IBM Cloud
Options available vary by software package.

IBM hasn’t published detailed pricing on their software subscription pricing (PAYG), but it would be a fair to assume it will be less than what they charge on Amazon.  [N.B. on AWS, IBM only offers a very small subset of its software primarily targeting ISVs for development & testing as opposed to enterprise customers.]
Now, let’s talk about the market and the opportunity for IBM.

Market maturity, opportunity & customer addressability
Since the recession a couple of years ago, Cloud Computing has gained more momentum in the enterprise.  IDC estimates spending on Cloud services in the range of $42B by 2012. 
If you look at early Cloud providers such as Amazon or Google, while I have enormous respect and appreciation for the innovation and technical design and delivery of the services, I argue they haven’t been able to gain traction in the enterprise space.  The only exception is SalesForce.com [take a look towards the bottom of this post.].  They have done well, because the founder had an enterprise software background.

As an example, if you look at Google’s enterprise business in 2009, it booked around $209M (that includes revenue from their search appliance + Google Apps).  In a previous post, I estimated AWS revenue to be around $200M / year.    If you compare these numbers with IBM SWG, MSFT or Oracle software revenues, I think it would be easy to conclude they haven’t captured a big marketshare in the enterprise space.  I think this is fundamentally due to their lack of business relationship, partnerships, and investments in sales & marketing.

So, I think this is a good time for IBM to enter the market.

In terms of opportunity and access to market, IBM is a global company with delivery centers around the world. It has business segments that align well with customers considering or transitioning to Cloud Computing. To understand the potential opportunity for IBM better, let's look at some numbers. 

IBM Development & Test Cloud is an offering from Global Technology Services (GTS):

The numbers above are in millions.  In 2009, GTS revenue was around $37B with a gross margin of around 35%.

There are several business lines in GTS:

• Strategic Outsourcing (SO) – This segment offers outsourcing services to commercial and public sector.  In 2009, IBM’s SO revenue was $19.3B.
• Integrated Technology Services (ITS) – This segment offers different IT services (project based) from IT strategy –> middleware services –> infrastructure services.  In 2009, ITS’ revenue was $8.7B.
• Business Transformation Outsourcing (BTO) – This segment focuses primarily on business process outsourcing (BPO), and “IT transformation” services.  In 2009, BTO’s revenue was $2.2B.
• Maintenance – This segment offers product maintenance and support services.  In 2009, GTS maintenance revenue contribution was almost $7B.

IBM has C-level relationships in Fortune companies in all industries.   Some of these companies have already entrusted IBM with their IT infrastructure and mission critical systems.  This puts IBM in a huge advantage over other service providers. 

As SO contracts are renewed, and as ITS engages customers in IT strategy and middleware services, IBM should also be able to harvest opportunities for both private cloud as well as public cloud. 

[N.B.  The cool thing about Cloud services is that they are not like SO contracts (i.e. fixed).  Once you sign up a customer, as long as you’re meeting your SLAs, and manage the offering in terms of features/capabilities, you should be able to maintain a profitable recurring revenue stream (i.e. reduced sales & marketing costs, reduced infrastructure costs through efficient multi-tenant delivery).]

Consider this....If IBM were to convert 10% of 2009 GTS revenue from existing base to Cloud, let's say over the next 3 years, they would make about $3B in Cloud revenue by 2013…Now, that’s revenue & marketshare.

Here is another reason why Cloud could help IBM.    IBM Software Group booked $22B of revenue in 2009:

SWG revenue breaks down as follows:

• Cross-brand middleware:  This is combined revenue from WebSphere, Tivoli, Lotus, Rational, Information Management worth over $12B.  IBM doesn’t break down the revenue by brand. 
• Other middleware: This include legacy middleware such as CICS & IMS.  IBM made over $4.6B there.
• Operating Systems: This includes software such as zOS, AIX, AS/400, & TPF.  In 2009, the OS revenue was > $2.1B.  This is dependent on how IBM’s hardware group (Systems & Technology Group) performs.
• Product Lifecycle Management (PLM): I think it is a joint venture with Dassault Systems.
• Other: This includes all IBM Software Group services (aka Lab services).  In 2009, the revenue for this part was $1.4B.

As you can see above, except for lab services, x-brand middleware is the only segment that’s been reporting growth. There are two reasons for this:

• Acquisitions: IBM has made some big acquisitions in this space: (i.e. Cognos for $5B, FileNet for $1.7B, Sterling Commerce for $1.2B…).  Acquisitions help IBM book new business.
• Renewal rates: This is recurring revenue from existing customers.  I was told by a software sales exec, average renewal rates for a successful enterprise software company is around 98% (depending on the product, maturity, etc).   So, this is helping IBM SWG maintain revenue and marketshare.

I haven’t heard of any new notable products out of SWG lately.  So, looking at the above, I think it is fair to conclude acquisitions have been the primary vehicle for growth in SWG.  So, with Cloud Computing, SWG  should be able to develop a new revenue stream.

So, for SWG, I think Cloud Computing can offer the following benefits:

• Use Cloud as a sales & delivery channel for SMB.  This would be very helpful to IBM.
• Offer a viable alternative to clients looking at other sourcing options
• In the beginning, I think Cloud can offer a parallel revenue stream for SWG particularly for WebSphere, Tivoli, and Rational
• Compete with other private cloud vendors and public cloud service providers
• Partners and alliances help IBM realize almost a third of its total revenue.  SWG gains a lot from these GSIs and ISVs.  SWG can offer new solutions to these partners to help grow its revenue.  Also, help ISVs cloudify their solutions.

All of the above should help IBM sustain growth.

[N.B. There is some difference between private and public clouds in terms of revenue.
Software is a high margin business.  In the case of IBM SWG, the gross margin for SWG was 86%.  The reason for this is software licensing & maintenance costs.  With public clouds, this is radically different. It is a volume business.  For IBM to be profitable in the public cloud space, they must sign up more and more customers.  On the private cloud side, they should be able to do better.]
----------------------
IBM is building a good story here.  From SWG side, with WebSphere CloudBurst, the recent acquisition of Cast Iron, and Rational Software Delivery Services, IBM is putting together all the asset to enable Cloud Computing for the enterprise.  On the GTS side, IBM is in a good position to create opportunities, and work with enterprise customers to help transition to Cloud.

Finally, from a competitive perspective, in the enterprise space (as opposed to consumer space), I don’t think IBM needs to worry too much about AWS or Google.  As long as IBM prices its public cloud offerings from GTS, Lotus, etc competitively, and maintain a close relationship with enterprise accounts, I think they should be able to do OK.

In the enterprise space, I think SWG should keep an eye on Oracle and VMWare on one side, and MSFT on the other.  GTS will have to worry about the usual competitors such as CSC, HP/EDS, etc...

Technology-centric approach to Enterprise Cloud Computing doesn’t work

There is a lot of Internet chatter and conversation on Cloud Computing.  Since 2007, Google Trends shows growing increase in Cloud search keywords:

Majority of these articles and posts though are primarily focused on technologies (i.e. virtualization, dynamic provisioning, security, management & automation, metering & chargeback) that enable building a Cloud infrastructure or platform.  Technology decisions and effective implementation are absolutely necessary, but building, operating, offering, and managing a Cloud transcend technology. 

Cloud Computing doesn’t arrive in a box of CDs.  It is an evolution in IT competency and operational model (i.e. Incident Management, Asset Management, Configuration Management, Change Management, Performance & Capacity Management, SLA Management).  A technology-centric approach to Cloud Computing does not address IT operational gaps.

One of the fundamental requirements for Cloud transition is IT standardization.  Standardization is key to IT simplification and cost reduction, and requires an analysis of both IT and application portfolio.  In this regard, an analysis of the various workloads, performance characteristics, HW/SW compatibility & infrastructure requirements, application strategy such as any decommissioning, re-hosting, or outsourcing plans,… and review of enterprise architecture are necessary to establish standard configuration templates.  Without such an analysis, it would be very difficult to determine the right set of services to offer in the enterprise.  A technology-centric approach to Cloud Computing does not address IT standardization.

As I said in a previous post, there are different entry-points to Cloud Computing.   There are a couple of implications here.  First, organizations choose different strategies and approaches for IT cloudification based on their priorities.   Second, organizations are at different levels of IT maturity.  Some may have experience building and running CoEs. Some may have experience operating & managing shared services centers. Finally, some may already be running a Cloud (or have already implemented an on-demand and utility-based shared infrastructure way before the term “Cloud” was in vogue.) So, there is a lot of considerations in terms of organizational maturity, alignment, change management that are essential to a successful Cloud transition. These are not addressed by a technology-focused approach to Cloud Computing.

These were just some examples.  So, next time when you get a visit from a vendor, showing you a quick demo of 1000-node cluster, with dynamic scaling may be including spillover to EC2, a nice management interface, etc, a question to consider is how do I operationalize this? 

Oracle, AmberPoint, and the SOA Management ecosystem

Earlier this morning, Oracle announced it had entered into an agreement to acquire AmberPoint.  AmberPoint will be integrated and managed under Oracle’s Enterprise Manager division, and over time will be ported to the EM management framework.

For both existing customers and new prospects, this is positive news on many levels (i.e. broader/deeper capabilities after integration with EM, removing any doubts or concerns over vendor financial stability, product viability, solution’s strategic fit in the enterprise, etc).  AmberPoint will fill the gaps in Oracle’s SOA management capabilities today, and should play a key role for Oracle Cloud management in the future. With Oracle’s sales and distribution channels, AmberPoint will be able to reach new markets and extend market share.

In SOA management business, AmberPoint and SOA Software were the only key niche players left.  This acquisition puts Oracle in direct competition with SOA Software.  It will end the Oracle and SOA software partnership.  Looking forward, SOA Software is likely either going to get acquired – or - has to figure out a different product and partner strategy to compete. 

In terms of acquisition, the usual suspects for SOA Software include IBM, Microsoft, CA, HP, BMC or possibly even SAP.   Any of these vendors should be able to take their solutions and integrate them as part of a broader ESM/BSM solution.  SOA Software assets could help accelerate with that.  As far as product strategy, I think SOA Software will have to break away from just “SOA management” targeting enterprise customers into broader Cloud management also targeting Cloud service providers: self-service, asset/portfolio management, Cloud operational governance (quota, policies, SLA, billing, …) configuration, provisioning, automation…  They can do some of that on their own or go to market with new partners.

In summary, Oracle’s acquisition is definitely good for customers.  It also forces the other player to consider solutions and strategies.

What apps are likely to move to the Cloud…

Earlier this week, IDC published an interesting survey on what applications are likely to move to the Cloud.   I thought about blogging about this, because they made some good points & observations in their analysis, and it also follows my previous post on application and workload analysis for Cloud Computing nicely.  
I am not going to repeat what’s said in their survey, but wanted to add a couple of points before moving any application to the Cloud:

• Cost: What is the current annual cost of maintaining and running the existing application?   For most enterprises, cost reduction is the key driver for Cloud, so establishing the cost should probably be one of the first activities in any migration.  [N.B. If the Cloud is considered for new applications, a similar cost analysis should be performed to estimate the initial cost of building the application + estimating the annual ongoing maintenance and operation.  It would be best to breakdown the costs in terms of infrastructure, operation, and solution development & maintenance.]
• Cloud Selection: Different Clouds offer different capabilities and different charge-back models.  As an example, with Google App Engine, you can upload your web app to Google’s infrastructure.  You’re not charged unless the application serves requests.   Now, contrast that with EC2.  Obviously, you must launch your AMI to start your application, so you’re billed for CPU usage even if the application is sitting idle. Please note that I am not suggesting GAE is better than AWS.  They are different platforms for running different types of applications, and offer different capabilities.  So, Cloud selection is a very important consideration not only with regards to costs, but also in terms of building, delivery, and management of the target solution.

There are many other considerations such as service provider’s alignment with the enterprise in terms of operations, support, compliance, SLA, and technical fit of the Cloud service vis-a-vis the application, etc…
Finally, in the overblown world of Cloud Computing where “Cloud” is myopically restricted to only a few forms such as AWS, GAE, Force.com, etc, it should be noted that many companies have already been using Internet-based services routinely for more than a decade.  These services have been used to fulfill simple functional requirements such as address normalization or tax calculation to more complex business processes (i.e. risk analysis) or business process outsourcing (i.e. order fulfillment) where enterprise data is typically hosted on an external  service provider or tightly integrated with the service provider.  So, in addition to the list of application types that IDC has presented in their survey, hosted solutions and/or BPOs represents another class of candidate applications for “Cloud Computing”.

Workload Analysis in Cloud Computing

Not all workloads are the same, and not all Clouds are the same!

Different applications have different set of requirements and characteristics.  Some Clouds (i.e. GAE or Heroku) are natural fits for certain class of workloads (i.e. WebApps) whereas for other types of workloads (i.e. batch), other Cloud services (i.e. AWS) are more appropriate.  In some cases, the business operation and/or legal requirements may require a completely different deployment (i.e. private Cloud). In a previous post, I referred to workload analysis in the context of approach to Cloud adoption. In this post, I thought to share some ideas about it.

The aim of Workload Analysis in Cloud Computing is to look at different aspects or characteristics of an enterprise application to determine the feasibility of moving or porting the application to the Cloud.  This analysis also provides input to implementation approach, Cloud service selection, and an initial business value assessment (i.e. cost reduction, IT simplification)…

The following proposes some guidelines in workload classification & characterization:

Workload Category: At a high-level, there are two kinds of applications in the enterprise:

1. Custom Applications – This class of applications are developed and maintained by the enterprise.  The enterprise has control over its design, technology selection, implementation,  infrastructure requirements, maintenance, and overall portfolio roadmap. 
2. Packaged Apps – For this class of application, the respective vendor is in control of its implementation, packaging, release, supported configurations, product plans, etc.

In the case of Custom Apps, If an enterprise is considering to deploy an application to the Cloud to achieve cost reduction or simplifying IT by delegating the infrastructure operation/maintenance to an IaaS, there is flexibility from simply taking the application pretty much as is to the Cloud –> re-factoring the application to leverage Cloud services (i.e. RDS).  In the former, the potential is substantial savings in infrastructure cost and business value in terms of new hardware & software purchase avoidance –> potential for much better SLAs and a lot more cost savings by reducing or totally eliminating the burden of additional FTEs (i.e. Database Administrators).

For Packaged Apps, the enterprise may or may not be able to move the solution to the Cloud due to licensing restrictions, technical infrastructure requirements, complex integration issues with other back-ends, etc… [it is good to check the packaged vendor for any existing or future plans for SaaS offering…]

Next, there are a set of general characteristics or attributes to consider when analyzing the applications:

• Workload Type: In general, there are two types of workloads: Batch or Online.  It is important to consider this differentiation for the following reasons:
• There are different resource requirements and considerations. As an example, batch workloads may require specific capacity in terms of storage and compute resources (i.e. vCPU, memory) to finish the job in a timely fashion whereas for online workloads network bandwidth may be more critical…
• There are differences in programming models.  As an example, some batch jobs may be implemented over a framework like Hadoop whereas for some online workloads a PaaS like Force.com may be the best choice. 
• Workload Frequency:  Sometimes, a workload may run at month-end or every quarter.  I like to note this attribute in the analysis for investment cost / benefit analysis.
• Workload Cost: It is important to capture the total cost of workload including hardware, software, application maintenance and support, etc.  I think it would be even more useful to develop a cost allocation model reflecting percentages in infrastructure, software, application development, support and maintenance, etc…  This information is useful in Cloud service selection.
• etc…

So, in summary, it is good practice to develop a consistent approach/process for analyzing workloads in Cloud Computing adoption.  This analysis has a range of use from business case justification to Cloud service selection. 

Also, as described in previous post, there are several sources of information to aid in workload analysis (i.e. Project Portfolio Repository, any existing server/application consolidation or decommissioning analyses, issues log or problem management database, etc). 

Finally, I highly recommend an excellent presentation that David Chou posted on his blog on patterns of moving to the Cloud…

The enterprise has to deal with a mixed bag of virtualization vendors…

A couple of weeks ago, I was at Oracle Open World and attended a good session on JRockit (JRockit: What’s new & What’s coming).  The presenters were from JRockit lab in Sweden, and they presented many things from  new features, JVM performance, JRockit Mission Control (JRMC), JRockit Real Time (JRRT), and JRockit Virtual Edition (JRVE).   JRVE is a JVM that sits directly on bare metal hypervisor (it eliminates the OS layer, thus offering better performance, and simplification in terms of installation, configuration and maintenance).

Back in the BEA days, they showed a prototype of WLS VE running on JRVE at VMWorld in 2007.   That version was running on VMWare’s ESX.  With this version, it only supports and is certified on Oracle VM… Not a big surprise, if you think about it.  Since Oracle’s acquisition of Virtual Iron, Oracle has been optimizing its stack on its own virtualization infrastructure…

I was talking to a customer the other day to ask them about their Virtualization strategy.  This is large company that has deployed different types of servers and OS for different kinds of workload.  Currently, for Microsoft platform, they are using VMWare (when I asked him about Hyper-V, he said no plans yet).  For Linux, they are standardizing on RHT Enterprise Virtualization (KVM)… Oh, not to forget, on the mainframe, they are using zVM.

It occurred to me there is already a myriad of different virtualization tools and technologies deployed in the enterprise.  With Oracle’s solution strategy, there will be compelling reasons for many to deploy yet another virtualization technology in their environment (i.e. Oracle PaaS).  Furthermore, in addition to virtual machines and appliances deployed within the enterprise, many enterprises that adopt Cloud computing (hybrid clouds) will have to deal with additional virtualization infrastructures (i.e. EC2), their set of provisioning APIs and other management interfaces… 

The good news is that major virtualization vendors already support DTMF standardization efforts (i.e. OVF, VMAN) in their solutions or plan to support it.  There are also new standardization efforts around open APIs (i.e. vCloud) to abstract the virtualization technology, and provide a standard programming model to provision and consume virtual resources as well as support those interoperability use cases in the hybrid Clouds…  On the other side of spectrum, there is a growing number of virtualization vendors with provisioning solutions to facilitate packaging, grouping of related VMs (i.e. vApp)  for multi-tiered applications.

So, I don’t think most enterprises can standardize on a single virtualization vendor.  The trick is to figure out a virtualization management strategy that provides unified visibility and control in terms of asset & configuration management as well as infrastructure operation and governance.  Let me know what you think…

The future of SOA is Cloudy…

A couple of months ago, I was at an Oracle event in Redwood Shores.  The event brought together some of Oracle’s marquee customers & Fusion middleware product management team to discuss challenges/issues with regards to SOA, BPM, infrastructure management... and provide an opportunity to learn more details about FMW roadmap and offer feedback…

I seized the opportunity to talk to several customers about their SOA implementation.  Most of the customers (small –> large) had passed the initial stage of SOA readiness assessment, transition planning, and initial service portfolio development.  They had already implemented and deployed multiple enterprise services into production.  The most common issue related to SOA infrastructure management, and making sure it offers the level of resiliency and availability their customers demanded.

SOA introduces additional layers in the already multi-tier distributed applications.  First, you have the SOA management layer that handles performance management and policy enforcement.  Next, you have the Enterprise Service Bus (ESB) that abstracts service endpoints, and offers integration logic intermediation between service consumers and providers.  Finally, there may be integration adapters used to facilitate semantic and protocol integration with backend applications (i.e. SAP).  During a service request, all of these components must be available and fully functional.  Otherwise, the request fails and either the infrastructure must handle automatic management of the exception and re-routing of the service request message to maintain SLAs or the client must re-try the request upon receiving the exception.

Another area of concern is related to capacity management.  It is common practice to use high volume / peak load metrics to calculate capacity.  The result is over-provisioning of resources  (AKA server proliferation) and low utilization of assets.  In terms of IT financial management, the impact is monumental from increased hardware and software licensing costs to additional FTEs to configure & maintain the assets, and finally data center floor space, power consumption, …

So, many customers are already in their next level of SOA maturity.  They are focused more sharply on SOA operational governance.  This is where “Cloud” and SOA converge.

Before we get to that, let’s do a quick review of “SOA business value”.

SOA promises lower IT costs, reduction of IT complexity, business agility, etc… However, rarely is SOA business value measured against metrics related to the above.  The universal measurement for SOA in many organizations continues to be “service reuse”.  The more reuse, the better…Often, it is not even clear at what level of the organization reuse occurs to map and measure the value more clearly, but that’s a whole different blog…

For SOA to deliver lower IT costs, reduction of IT complexity, and agility, it is required to change the infrastructure to be more adaptive and resilient.  Unfortunately, in my experience, this is often not properly considered in SOA programs.  The vendors give you an ESB, and you’re good to run :-[

The “cloudification of SOA” involves the following capabilities:

• Dynamic Resource Management – Rather than over-provisioning to meet peak demand, a private Cloud infrastructure can enable demand-based provisioning.  This enables the enterprise to utilize IT assets more effectively and realize reduction of IT costs in terms of HW/SW/datacenter.  For some workloads, policies can be established to spill over to public Clouds like Amazon (hybrid Cloud). 
• Automation – Automation is a key component of Cloud infrastructure.  Automation is used in a variety of scenarios from automatic scaling to align with resource demands as well as automatic error/exception recovery.  This is a key enabler for service level management.
• Performance Management – Performance visibility and management across different layers of the stack is fundamental to any Cloud infrastructure.  Without it, there is no DRM or automation.  Once the organization is able to capture and correlate performance metrics across different layers and map them to a service request, they can do a better job of capacity management.  This also helps SOA with service performance management and SLA.
• Self-Service capabilities – Finally, this is an area that may not be readily consumable in all organizations, but it is a vision.  The idea is simple.  The goal is to bring the same self-service capabilities available in public Clouds to the enterprise (i.e. self-service service registration, self-service provisioning, self-service resource configuration and policy specification, etc…)   Imagine an environment where you can go to a self-service portal and request a server from a list of pre-configured images, click a button to provision a server in a few minutes rather than a few weeks that typically takes for IT request review/approval, procurement, HW installation and configuration, and delivery… Many companies are looking at this approach or have already implemented initial self-service portals to enable self-service capabilities.  In this scenario, it is possible to communicate IT agility using concrete metrics (i.e. average time to provision a server, # of demands serviced / week, etc)

Here is a conceptual diagram to illustrate the above:

So, to summarize, SOA operational governance and management poses difficult challenges in the enterprise.  The common approach to SOA does not address infrastructure issues to enable realization of SOA business values.  A Cloud Computing approach can help organizations with that.

I would be very curious how many are looking at Cloud as a progression of their SOA programs, and if they are looking at self-service capabilities.  Look forward to comments or questions.

IT Portfolio Management & Cloud Computing

Earlier today, I presented at iCMG’s Architecture World 09 about the impact of Cloud Computing on IT Portfolio Management.   I started the discussion with a quick review, and an overview of Cloud Computing.  The first set of slides came from my Cloud Computing overview and case study.  Then, I spoke with IT Portfolio Management and its relationship to other IT management practices and IT Governance.

I reviewed IT Portfolio Management in the context of shared services and Cloud Computing.  Here are some of the key points:

• Cloud Computing lowers the barriers and risks for enterprises to experiment with new ideas (i.e. rapid prototyping and experimenting).  This is a huge benefit and capability for the enterprise.
• Cloud Computing makes it much easier for enterprises to perform ongoing financial analysis (i.e. TCO).  For example, Cloud Computing billing, by itself, facilitates understanding of the costs with more precision, because its delivery model eliminates a number of the variables associated with indirect costs (which are often the main contributors to different results)…
• With Cloud Computing, it is much faster to measure benefits due to readily available analytics…

You can find the slides here.