Interesting posts on the "Principles of Cloud Oriented Architecture", and "Cloud Computing Bill of Rights"

I've been reading James Urquhart's blog The Wisdom of Clouds for some time now - a leading thinker in the emergent space of Cloud-based architecture.

In particular, the following recent posts are especially worth reading:

Update: the Cloud Computing Bill of Rights

The Principles of Cloud Oriented Architecture

Generally I agree with James that, since the world is now coasting towards a single common, shared Cloud Oriented Architecture that a set of common principles, rights and responsibilities can and should be drafted (but I would ask by whom?). As with any technological advance, the social and legal effects cannot be thought through soon enough before the impact of the change is felt. The question of jurisdiction will always be hardest - which authorities govern and legislate for data and other services in the (international and potentially off-planet) Cloud? Technology moves ever more quickly than the human population can keep up.

In some ways this "Bill of Rights" reminds me of a political manifesto - there will be diametrically opposing views on privacy and security for example from the governments of many countries, and so the practical question is *how* such a BoR would ever come to realised.

However, another way to look at the BoR is as a requirements spec trying to solve 3 discrete technical problems:

Namely:

• Providing clear ownership of data and avoiding Cloud services providers ever "owning" their customers' data.
• Providing clear accountability (=measurable!) for Cloud service levels
• Providing clear ownership of (patented?) intellectual property underlying a Cloud service
  

James has brought us all a long way by articulating these vulnerabilities in today's Cloud services model - however I personally think that it's more likely that these issues will be addressed successfully (and cheaper!) using technology rather than by the law.

An alternative Microsoft-based Cloud Services Architecture

Just had a read of my friend Matt Smith's blog post from a couple of weeks ago, which covers very similar ground to my last post on the cloud services I've started using. Matt is a Microsoft fanboy - he even once proposed SharePoint as a viable alternative to a girlfriend in a presentation - these things come back to haunt you, you know! ;-) - and so is pretty keen on MS' Mesh services (must take a closer look at these) - I'm mostly using Google at the moment. Compare and contrast at http://blog.mattsmith.co.nz/Lists/Posts/Post.aspx?ID=40.

Integrating Google Calendar and Contacts with Windows Mobile 6 - OggSync

Further to my previous post on an early cloud services architecture model for my business, this week I've had great success integrating two different services: Windows Mobile 6 handheld operating system with Google Calendar and Contacts - this enables me to maintain a "single version of the truth" for both calendar events and contacts - and at the same time carry both around with me on my mobile. After years of being tied into Microsoft's Exchange / Outlook sync model which ties your data to a particular desktop PC, it is pretty liberating to have everything looked after in the Cloud!

After scanning through the web for tools to manage this integration (there are a few - see Jonathan Wilbur's post on the subject at http://www.jonathanwilbur.com/syncing-google-calendar-with-windows-mobile-6/ ), I settled on OggSync (http://oggsync.com/) - version 4.19 beta currently.

Happy to report that US$29.95 buys a 1-year subscription to a fully functional sync service running on my mobile device - enables sync of timezone and multiple calendars and all of my Google contacts. Easy to buy, install and configure - highly recommended.

Cloud services enterprise architecture week 1 - eating our own dogfood

OK, I'm at the end of month 1 of setting up the business from scratch, and have begun operating the business (Memia Ltd) and trading. It's an exciting time!

I thought I'd share some of the initial architectural outputs of this exercise - effectively as time goes on I will provide an ongoing commentary on how Memia is putting together a "Cloud Services Enterprise Architecture" for a small services business (with growth ambitions!). Hopefully the experience and techniques will be generic enough to be useful for others doing the same thing. This is, after all, our core business. ;-)


The diagram below shows the first iteration of Memia's cloud services architecture. (Click for bigger picture).

First off, I have divided the cloud services diagram into two main groupings, with the business in the middle: Output Services and Input Services: basically, the business consumes a set of services, and most importantly provides the "secret sauce" which enables the output services to be provided.

You can see from the Output Services box that the actual revenue-generating services are a pretty small part of the overall operational complexity of running a small business - in addition to earning money doing the day job, the business has to provide marketing, communications, regulatory compliance, day-to-day financial operations, and be set up to look after shareholders as well. These groupings are my first attempt at defining what a generic "baseline" business must do in order to get trading - I am sure there will be plenty more that I come across as the business grows...


The Input Services box illustrates all of the services that I have begun using during the setup over the last few weeks. As a matter of principle (and to eat my own dogfood!) I have used Cloud-based services wherever I can (shaded Green) - luckily(lazily) I have been able to delegate most of the complexity in my Enterprise to Google Apps - for free! - something that wasn't possible even a year ago. If you look at the diagram below, you can see the service providers I have chosen (for a business based in New Zealand).


- Home office space provided by yours truly ;-)

So I'm going to keep iterating this model and add new input and output services according to the business strategy - I'm also going to try to generate some traceability between the output services and the input services - this will be a good way to shake out the dependencies and business processes involved. I haven't followed any formal methodology (because life's too short in the real world) - however, I reckon this "services in, services out" technique is a pretty effective "agile" methodology for small businesses. I'm interested in anyone's comments here...