Lessons from the Amazon Crash

I had originally planned to blog on the innovative and environmentally friendly temperature control systems used by cloud computing service providers such as Amazon and Microsoft. These systems are extremely simple and unlike most in house data centres don't rely on traditional air conditioning systems.

However the recent Amazon outage and subsequent revelations have meant that my focus needs to be on a much more fundamental aspect of the services delivered by these data centres. The recent Amazon outage has rocked the confidence of existing and potential cloud computing users to the point that I believe businesses need to re-examine their cloud strategies and the business risks (in particular the business continuity risk) associated with them. Some Amazon customers effectively lost all their data as the email below which was sent to an Amazon customer highlights. There are several such emails circulating on the web currently so this doesn't appear to be an isolated occurrence.
Cloud computing promises and deliver much, however we should all learn from this in terms of taking nothing for granted in relation to cloud services even when from the big players such as Amazon. Ultimately the business risks still lies with the user and our cloud strategies and risk approach needs to take this into account.

Finally, while this was a serious incident that no doubt has set back cloud adoption in the short term I believe and hope that ultimately it will not derail the larger cloud computing movement.


"Hello,

A few days ago we sent you an email letting you know that we were
working on recovering an inconsistent data snapshot of one or more of
your Amazon EBS volumes. We are very sorry, but ultimately our efforts
to manually recover your volume were unsuccessful. The hardware failed
in such a way that we could not forensically restore the data.

What we were able to recover has been made available via a snapshot,
although the data is in such a state that it may have little to no
utility.

If you have no need for this snapshot, please delete it to avoid
incurring storage charges.

We apologize for this volume loss and any impact to your business.
Sincerely,
Amazon Web Services, EBS Support"

A Tale from the Agile Coalface

In Deloitte we have always adopted a very practical approach to agile software development and have developed this over the years into a repeatable approach that we have used with numerous clients. At an internal meeting last Friday a client of ours who had experienced our agile approach for the first time spoke about her experiences. It was very encouraging, and a testament to the quality of our team who worked with her, to see how positive an experience it was. The fact that she was willing to take this time out of her diary at all to do this spoke volumes for the experience she must have had. By way of background the project adopted an agile approach to the building of a self service ordering and customer service portal based on SalesForce.com. In summary the client felt that:

• It was a very refreshing customer centric approach when compared to her previous experiences.


• It produced tangible results quickly that didn't involve dry requirements documents which in itself encouraged more involvement from the business.


• It facilitated change easily without the need for change requests - they even dropped some of their original requirements and added new ones they hadn't thought of as the project progressed.


• It enabled her customers to be a part of the development process (the portal was targeted at them)


• The speed at which a first production version of the software was available (8 weeks) was amazing (she quoted previous experiences where you would be lucky to have environments available after 8 weeks). In addition, at this 8 week point they had one of their most strategic customer live on the beta version.


• The speed to market facilitated by the agile approach and the salesforce.com customer portal provided them with a competitive advantage that has since enabled them to win a number of very significant contracts.

We Need More IT Graduates and Now!

I read with dismay in the Irish Independent lately of Intel's decision to move a project apparently earmarked for Ireland to Romania because of a lack of IT graduates in Ireland. Apparently this is not the only case of this happening. It is also reflective of what I have been seeing during our latest graduate recruitment drive in Deloitte.



A constant supply of quality IT graduates is a necessity for businesses generally but most especially for software development companies and IT services organisations. Graduates are the lifeblood of these organisations in terms of expanding, getting the work done and developing the next generation of senior IT professionals. There is no doubt that their long term growth and the development of the smart economy is inhibited by a lack of these graduates.



In an era of such high unemployment it seems crazy to be complaining about a lack of staff but that is the actual situation that companies are grappling with at the moment. Unfortunately there is no quick fix to the problem as it takes three to four years to educate an IT graduate. Nevertheless there are actions that we can start to take now:



1. Immediately establish a working group consisting of individuals from the IT industry, academia and any relevant government agencies to tackle the problem. The members of the group must be chosen carefully and it must be an active, outcome driven group with an ability to make things happen. It should not waste any time producing reports or fancy strategy documents but should instead focus on outcomes and what actions need to be taken to achieve them.



2. Actively Promote IT as a career. For too long IT has been suffering from poor PR. We need to actively promote IT as a career in secondary schools, highlighting the benefits and rewards of a career in the sector. The industry needs to support this by attending and hosting career events, supporting work experience initiatives etc.



3. Encourage Post graduate qualifications in IT. The third level sector is producing a large number of graduates with non IT degrees who are finding it impossible to find jobs. We need to encourage a greater number of these to do post graduate degrees or diplomas in IT. The third level sector may need to consider increasing capacity in this regard.



I don't pretend to have to have all the answers. However I believe that the steps above will serve as a good starting point to addressing what is becoming a critical problem and a lost opportunity.

Software Testing is easy and Other Myths

A colleague of mine recently published a paper Software Testing is Easy and Other Myths (http://tinyurl.com/28aymok) which makes for a great read.

This caused me to reflect on a recent assignment I completed for a client where I assisted them in developing an operating model, business case and implementation roadmap for a testing center of excellence. The engagement was challenging and ultimately successful and for me once again proved that some of the often repeated critical success factors for consulting projects such as these are true:

1. Executive sponsorship. We had great executive sponsorship which allowed us to cut through a lot of the 'noise' associated with projects such as these quickly. I can contrast this with similar engagement I undertook a couple of years ago in the same sector where this wasn't the case and the project was consequently less successful.

2. Staff buy-in. The creation of the CoE is going to mean a lot of change for existing testing (and non testing) staff. We recognised this early on and decided that we needed to make testing a recognised and supported career path and make people feel that they were part of a team/community. Some of the things we did in this regard included making communications a key component of the rollout plan and defining a testing career model with associated training and external certification. The idea was to make testing an attractive and valued career path in the organisation. Without this why would staff engage with the programme at all?

3. Understand the as-is situation. Ultimately the Testing Center of Excellence was being created for two reasons - to improve efficiency and quality. However to measure the success of the CoE it is important to understand and measure the current situation so that progress can be objectively assessed. This is often easier said than done as many of the metrics or KPIs that you would like to track often do not exist today and need to be created or estimated. We certainly had to do this on this engagement but clearly called out where we had extrapolated and committed to start building more accurate as-is metrics as the CoE was rolled out.

While there were many other critical elements to the success of this engagement the three above once again proved the most critical. We are just about to start the first phase of the rollout of the center of excellence which no doubt will prove just as challenging, interesting and successful. In either case I'll let you know!

Productivity in the Cloud - A Practical Example

I have blogged previously on cloud computing and its benefits. Consequently I thought it would be worth sharing a real world example of its benefits.

I work for Deloitte in Ireland where I am a director in our technology consulting practice. Recently we have been undertaking more and more projects for clients based on software as a service. One project in particular serves as a great example of how much more efficient software development in the cloud is to more traditional methods. The goal of the project was to automate a sales and fulfilment process for a major commercial client and thus significantly reduce the time it took to both take and fulfil a customer order. Some of the members of the current team had built a key part of the existing solution over 10 years ago. At the time the design phase alone of that project took somewhere between 3 and 4 months. Using a SaaS based solution combined with agile techniques we managed to build and deploy into production the new solution in just over 10 weeks and that included functionality (such as mobile) not available in the current solution and was undertaken by a smaller team. This is a truly huge saving in IT time and effort, let alone the time to market gains made by the client. Internally we have reflected on what a win this is for our client and ultimately for us but you can't help but ponder on what this ultimately means for the systems integration business model.

Enterprise Architecture Blueprinting

The soon to be published results of the Deloitte 2010 CIO Survey suggests that Irish IT organisations are beginning to emerge from the worst of the recession and look to the future. The question for these organisations is what does this future like and how do they get there. Enterprise Architecture Blueprinting is a technique for helping organisations to answer this question. The diagram below provides a high level overview of the blueprinting process.
The first step in the process is to develop a high level view of the current business and technology landscape. They key items to identify are the current organisational capabilities (sales, backoffice, marketing, manufacturing etc.) and the business processes, people and organisational structures that deliver these capabilities. Supporting IT capabilities (systems, people, process) should then be mapped to this model.

The next step is to decide what the future should look like. They key input to this process is the Business strategy (in whatever form it is available). This is used to identify the organisational capabilities required and the business processes, people, organisational structures and projects required to provide these capabilities. Based on this the required IT capabilities (systems, people, process, information) can be identified and mapped to this model.

Undertaking a gap analysis to identify the IT capabilities that should be retired, built or bought is the next step. This leads to the final step where a roadmap for the delivery of the future state architecture is developed and ultimately implemented.

This in turns leads back to the first step where the architecture is maintained and governed on an ongoing basis.

This simple process can scale from individual projects to large scale entire enteprise programmes and provides IT organisations with a fraemwork in which they can attain (the often elusive) goal of IT/Business alignment.

Up Close & Personal with Vendors' SaaS Plans

I am currently assisting a client in the definition of their strategy for the next three to five years. As a part of the process I have engaged with the vendors of the key applications in my client’s application architecture. There is a good variety of applications from ERP systems to finance, HR and payroll as well as a few other nice products. It was particularly interesting to get up close and personal with the vendors in terms of their SaaS plans. A couple of things struck me in this regard.

Firstly there was a strong move towards Software As a Service amongst ‘traditional’ software vendors for whom SaaS threatens traditional license and professional service fees. All of the vendors to a greater or lesser extent were planning cloud based versions of their applications. While for many this was not necessarily a great commercial proposition it was clear that customers were demanding SaaS offerings and that the vendors were beginning to respond.

Secondly, it was clear that while SaaS versions of the applications were being planned, for many vendors the multi tenant model demanded by SaaS was going to mean a significant change to the technology platform and data models underpinning their applications. Given this customers should consider carefully when it is the right time for them to migrate to these offerings!

Thirdly, all the vendors I met were planning to begin by delivering point or module based SaaS solutions that could be used standalone or in some cases interfaced with on premises versions of their applications rather than starting by completely rebuilding their current application.

Finally and perhaps most importantly I suspect that the vendors, while outwardly committed to SaaS based offerings, were unsure how it would really impact their business and that of their customers. Nevertheless given the variety of applications and vendors I met I became even more convinced that SaaS is going mainstream.