EC2 Troubles Must Be Taken in Context

EC2 Troubles Must Be Taken in Context

Proponents of cloud computing aren’t going to like the fact that Amazon had issues that resulted in outages among its EC2 customers’ sites. The know-it-alls out there are probably already saying, “If Amazon has issues like this, imagine what would happen if you placed your bet on a less-experienced cloud vendor!” The gravitational shift toward the cloud for both core and non-core systems has surely slowed down.

But the fact is that most insurers have their own outages when they host applications internally, in some cases with more frequency and severity than we’re seeing here with Amazon. It’s interesting to note how some of the customers who are known to be affected have reacted. “We wouldn’t be where we are without EC2,” said one. So despite the horror of having their public-facing site go flighty for a day (or two–we’re hearing the problems are not completely resolved), there’s apparently a reserve of goodwill that has built up over many months of near-flawless operation.

Instead of putting the industry on red alert, Celent believes this event should focus the discussion on the relative reliability of various approaches, and the tradeoffs between them. Should you know your vendor’s architecture and reality-check their DR and failover strategies? Absolutely. You should also run the business case for change, especially if gaining scale quickly, moving nimbly into new markets, or handling seasonal spikes in activity are issues for which you have few answers. Outages caused by a vendor are never a good thing, but they are probably not your biggest, baddest problems either.

SOA Removes the Fog from Cloud

SOA Removes the Fog from Cloud

A lot has been made about Cloud computing recently; even to the point of asking if it is more fog than cloud. The focus of these discussions is strictly on the technology which is where they miss the point. It is reminiscent of the early SOA discussions.

Celent defines Cloud computing as the use of computing resources, typically a server or part of a server, over the Internet. The implications of this are: companies can leverage a vendor’s server offerings to build or expand their server capabilities; focus is on hardware, not software; and carriers need to package up an image of their software to install it quickly.

While technically speaking, Cloud solutions do leverage the Internet and virtualization, neither of which is new. However, if using these technologies is so easy, why do companies, especially insurance companies struggle with gaining the benefits of Cloud themselves? I believe the answer is identical to why many insurance companies were not as successful with SOA, lack of strong governance and understanding of the full picture.

Many companies when trying to implement SOA solutions, focused strictly on WS-* standards and SOAP, although inconsistently across the enterprise. Companies that have been successful in their SOA journey have realized that SOA is more than technology and standards; it also includes architecture, organization, governance, strategy and process maturity.

Insurers that believe Cloud, and more importantly, SaaS is nothing more than invocating functions over the Internet and using virtualization for cost effective infrastructure implementations will miss the benefits of Cloud and continue to struggle with application and infrastructure upgrades and cost savings. Similar to SOA, insurers must look at their architecture, organization, governance, strategy and process maturity to decide if a private cloud is more effective than a public cloud solution. The advantage that most Cloud vendors provide is that they will do this for you if you cannot or do not.

Cloud, technically speaking, may simply leverage the Internet and virtualization, old technologies, but do not be fooled into thinking that is all it is.

Is Your IT as Good as You Think It Is?

Is Your IT as Good as You Think It Is?

During a recent interview with a senior level leader within a large P&C insurer responsible for their outsourcing efforts, he made the comment that they plan to increase their use of BPO and explore SaaS solutions. However, he then went on to state that the biggest hurdle that they face in using SaaS is they do not really know how good they are to be able to compare if any vendor can do a better job than they can. This struck me as very on target and reflects the state of many insurers, although most will not admit it.

I’ve worked in IT for over 25 years with some very large and distinguished companies, as well as smaller, not so well known ones. In each case, I was fortunate to work with some very qualified and intelligent people. In most cases, we usually believed that “our” IT team could do the job better than anyone else. This is a great attitude to have from a team perspective and fitting to some degree for companies at the time. However, this can no longer be acceptable with the maturation of BPO and SaaS. You can no longer delude yourself into thinking you can do IT solutions (soup-to-nuts) better than any SaaS vendor, especially into today’s market where utilization, agility, speed to market, lower TCO are key business drivers. An insurer’s IT team may know the business and their IT systems better than anyone, but it doesn’t mean that they can support business solutions going forward better than anyone else.

I’m not suggesting that BPO and SaaS vendors can always support insurance applications more effectively and efficiently than an Insurer’s IT support staff, but insurers have to begin determining how well they actually perform to be able to decide if a SaaS or BPO vendor is a better long term solution. It would be like creating a baseball team that does nothing but practice and play games among themselves and believe that they have the best team around. Within most sports, the metrics to compare already exist. They do not exist within most IT development and support staff today. What is your current support level for your current applications? How much control do you really have over your applications and infrastructure? How secure is your data today? These are valid concerns stated by insurers today with respect to BPO and SaaS, but they should be the same questions insurers are asking of themselves.

BPO and SaaS are beginning to mature in the insurance space. The economy and competitive forces will drive these solutions forward. Those insurers that know how well they do IT today and can compare their own capabilities to potential vendors will be the ones that are able to make the smart choices with respect to what to outsource and what to keep in house. Those that do not will be the “lessons learned” stories over the next several years. (See “Approaching the Boiling Point: BPO, SaaS in Insurance” Celent report, due out December, 2010.)

Is the death of the Insurance CIO possibly around the corner?

Is the death of the Insurance CIO possibly around the corner?

It was during a conversation over a year ago someone raised the possibility of the “best-before-date” of a CIO. He made the point that in 10 years time, IT would be a commoditised service consumed as and when it suited the business. He was really pushing the envelope – he meant all of IT from infrastructure services through to core insurance applications. I nodded sagely, as analysts do, and agreed with him in the principle but not on the time frame. 10 years… surely not.

The conversation was with a UK CIO of a mid-sized P&C operation and it’s been replaying on my mind recently. Against the backdrop of increasingly meaningful conversations about cloud, the idea of an IT organisation being commoditised to the point of removing the necessity of a IT management structure suddenly seems real.

There are two interesting case studies. Firstly, the UK Royal Mail moved from an internally managed mail system for 37,000 users, to an external public cloud by moving all the users to the Microsoft cloud. That’s a significant and meaningful change in strategy for a large organisation such as Royal Mail. The CIO said it was driven mostly by a need for agility rather than cost-savings. The Royal Mail had decided to focus on delivering parcels and letters, and let an external supplier deliver internal email via the cloud.

The second is an insurance specific test case. A UK insurer is testing a policy administration system in the cloud. This in itself is significant – this is a large insurer testing out the idea of a core system in the public cloud. It’s still under test but the insurer is excited about what this can mean for their agility in IT delivery.

With the growth of traditional sourcing models, it’s easy to accept that infrastructure could be moved from a private cloud with a traditional hosting company into a public cloud. What’s much harder to get agreement on is a vision of the world where core systems live in a public cloud. And there is good reason for this. Regulators, customers and insurers alike will have concerns over security and data privacy. There will be concerns about being tied to a large cloud provider with little interest in commercial issues. There will be (and have been in the cases above) some hand wringing over the gap in SLA’s delivered in the cloud versus what traditional sourcing models might offer.

The examples suggest an inexorable move towards the commoditisation of IT. It may well be too early to talk of the death of the CIO, but there is little doubt that the responsibilities of a CIO could shift towards supplier management as cloud offerings mature and become a viable solution to new outsourcing models.