Quick wins are an illusion

I wish that we could get rid of Quick Wins in programs and projects. In the past I experienced that many projects were legitimated by calculating a business case with a few quick wins. And based on that business case a steering commitee would then decide to start the project. And the first goal would be to harvest the low hanging fruits...

But in almost as many cases the projects were re-scoped after realizing the quick wins. Everyone happy: project finished in time, some financial benefits realized. But real progress, building a well structured foundation, based on the original requirements and designs, with decent quality assurance, will never be made.

Quick wins are an optical illusion for steering committee and project management. They are counter productive. You better subtract these wins from project benefits in the business case, because they make finishing a project after the starting phase so much harder, if not impossible!

Continuity as a service

(this post is not really about Identity, just a translation of my article from november 2009)

Nowadays everything is turning AAS: software, infrastructure, platform, security, identity, storage. More and more the traditional IT gets more foggy, we are more and more in the clouds. What remains of the old IT profession is to design and manage new things that have not yet been migrated to the cloud. That is no fiction: many companies transfer their legacy applications to the cloud. Even 'legacy' processes occur in the cloud, just think of HR and CRM processes. The cloud reminds me of that old Blob, the science fiction movie, cloud is becoming so pervasive that it seems to take control of everything. And just admit it, we find that exciting, scary and fun at the same time. But if everything disappears in the fog, how do we know that business is as usual?

The critical reader will, however, say that cloud is nothing new. It is nothing less than what we used to call ASP or Grid computing and so far we could reasonably well cope with that. Actually, cloud computing is a form of outsourcing and hence we do have a lot of experiences, both in a technical and a functional way. We know about the definition of requirements, managing contracts and we know how to deal with risks. We are in control.

In my opinion however, that is too simplified a representation of the problem. There is more to the cloud than just to call it a form of outsourcing. Let's make a distinction between between the cloud and the cloud. Not everything is opaque.

There are cloud variants that resemble regular ASP or outsourcing solutions. If you arrange with a provider to host specific services, that is just outsourcing, although not via leased lines, but via the Internet and that is not very exciting. It only becomes exciting if the same provider does the same for other parties and even more exciting if that provider in turn will outsource part of his business to yet another cloud provider. And that happens as we speak. Already CRM providers offer CRM services, hosted somewhere in the cloud on third party hosted cloud platforms. Just think of Amazon's Elastic Computing (EC2). Who knows where the real iron is? It seems so simple, you use a CRM service but the only specific part of the service is your personalized bill.

There are many security related questions. How about privacy, access control, change management procedures of the application, operation?
Fortunately, most of these questions are similar to the traditional outsourcing environments. Most of the problems are handled in contracts: agreements relating to ISO certifications, audits, SAS70's and TPMs are common.

But the core of the AAS problem is that contract partners are not always the parties who offers the actual service. You can try to mitigate risks in contracts, but the fact of the matter is that you want to move to the cloud, because of the positive price / performance ratio of multi-tenancy and the (re)use of standard applications. Long term subcontractor relations in the real world don't exits in the Cloud. If one platform provider is too expensive, our service provider just moves to another. This means that we are victims of the arbitrariness of our providers.

Back to the risks. Most risks are well known. Using standard operating procedures, access control and audits we can identify and mitigate problems relatively easy. And already there is a lot of information about security in the cloud. But one area of risk is not yet completely clear, the risks of business continuity.

The cloud is in many cases seen as a solution for business continuity. The cloud consists of virtualized, web based services in environments that are accessible via the Internet. This means in turn that the availability of iron is no problem (simply moving images), and scalability and performance are just issues of more iron and the availability of the Internet is the limitation of accessibility of the service. All fine. But the Cloud is not just a solution for business continuity. There are specific problems and there are no solutions to these problems yet. Indeed, even parties like Gartner have no ready-made opinion.

In this article I will briefly introduce some some specific cloud related security problems and indicate solutions to address the problems. I would like to stress that this is not a scientifically sound enumeration. It is astonishing how little is published about Cloud (SAAS) and BCM.

• The service provider drops out: can we address this as a regular contract deal, like ASP outsourcing? Unfortunately no. In a regular ASP outsourcing deal we are aware of the underlying application landscape and the underlying data models. You can for example, create a periodic copy of the environment and information and rebuild the landscape if needed. In many cases it once was your own... This is not possible in SAAS. If the provider fails, all knowledge about the apps and landscape may fall away. Apps and data structures belong to the SAAS provider and you can´t uses these if the provider fails. The minimal solution is to periodically dump data (both transactions and management and data logging) in an understandable file format. You should make this a contractual right.
• Traditionally Escow is a business continuity measure, but since changes on SAAS applications landscape may be so frequent, Escrow is not a real option anymore. At this moment there is no ´Cloud Escrow as a service´, this should be considered as a giant gap in the market.
  Gartner indicates the interesting idea to ask the cloud provider to open source the application code in case of a bankruptcy...
  An other alternative is the contractual agreement whereby you have the right to run the application in your own environment in the event of a disaster at the cloud provider's.
• It is not the SAAS service provider, but the underlying infrastructure or the platform supplier that drops out.
  Can you rely on the traditional subcontractor relations to help you into operation again? Is it enough to trust your SAAS provider to abide the contract? No way, it would take too much time to transfer the application landscape. In the cloud-epoch we also need cloud measures. Securing both data and code is vital, so it should at least be contractually arranged that a fallback in case of the SAAS failure can take place. It is not enough to claim responsibility of the SAAS provider. A switch to another SAAS provider, as a preventive measure, should legally be a realistic option.
• You need to define what can be called an incident or an emergency up front, in order to create a contractually sound escalation path.
• Of course your employees must always able to access your own application. You should therefore take care for a reliable Internet connection and thus a reliable connection to your cloud environment for your own employees. Availability is not expensive, but make sure that the coworkers can connect to the right cloud environments. Arranging for alternative connections, such as UMTS-like channels, has to be considered.
• Availability outside the regular network mean that you not only have to take technical measures, but you also need to realize functional measures. And that brings a management burden entail. Especially Identity Management in the cloud is at least as important as it is in the physical world. Identity 2.0 and federation will be very important. Ensure that these processes work as well.
• The latter does give rise to ensuring that SAAS solutions are not embedded in a chain of business processes. If such a SAAS process solution collapses, the whole chain of business processes may fail. There is more than this reason not to integrate Saas in your process chain: until today, there are still no industry standards to enable parts of business processes to make side steps to other processes and back again, like to Saas solutions in the cloud. So far, cloud solutions are point solutions. From the perspective of continuity that need not be bad at all.
• And of course all standard management security measures apply. Think of sound purchasing procedures, performing penetration testing and requiring SAS 70 Type 2 statements.

The uncertainty surrounding continuity is high at this moment. The question is whether for business-critical applications sensible solutions in the cloud exist today. An assessment around the continuity and security risks and safeguards in place seems to be appropriate. The issues described in this article should help to answer the question.