Some high level stats:

• 71% of organizations say employees are using apps not sanctioned by IT
• 72% say they have need to allow cloud app access to non-employees
• 43% say they still use “sticky notes” or spreadsheets to track passwords
• 78% of respondents plan to increase their use of cloud apps
• Staggeringly, 34% share passwords with their co-workers for applications
• 20% of organizations experienced an employee still being able to login after leaving the company
• 48% of respondents are still not able to sign in to cloud applications with a single set of credentials

So, where to start on this one? Well, for a start it’s truly bizarre that such a high proportion of organizations admit the existence of rogue IT – clearly the barriers to sanctioned adoption are simply too high and that’s what is forcing people to access via work arounds. it is heartening to see that trend balanced by an organizational intention to roll out more cloud applications which will, in time, reduce the occurrence of rogue IT.

But it’s the password management responses that had me cringing. Nearly half of organizations use the fabled “sticky note approach” to password management? As an industry we really have a problem if this is the case. Sure complex password management is just that, complex. Sure integration with enterprise services like Active Directory can sometimes be something of a burden – but to resort to such an inherently dangerous way of managing password is simply bizarre. Doubly so when one considers the main reason enterprises often give for not adopting cloud solutions is the perceived security risk burden they’d have to accept.

While security is a complex and difficult subject – password security should not – single sign-on, integration with enterprise systems of record and the ability to collaborate with external parties around application should be the starting point for organizations and not some pie-in-the-sky aspirational goal.

It’s actually a pretty complex question. Moving to the cloud isn’t simply a case of rip and replace. Over on the Forrester blog, Vice President and Principal Analyst James Staten recently wrote a great post that dispelled some of the common cloud myths, at least when it comes to moving applications to the cloud. Staten focused on the fact that, in the same way that cloud is very different to a traditional hosted environment, so too is it wrong to think you can put any old app straight into the cloud and expect “cloud-like” performance. As he said:

…you shouldn’t be thinking about what applications you can migrate to the cloud. That isn’t the path to lower costs and greater flexibility. Instead, you should be thinking about how your company can best leverage cloud platforms to enable new capabilities. Then create those new capabilities as enhancements to your existing applications… you have to think differently as you approach cloud development. There’s far more power in application design and configuration once you free yourself from assumed reliance on the infrastructure. The end result is new degrees of freedom for developers – if you embrace the new model

All valid points. Another way to look at this cloud application problem is to use the metaphor of peeling an onion (bear with me on this).

This is an analogy I often use in distinct ways to talk about moving workloads to the cloud.

From the vanilla to the hyper-differentiated, think of your organization’s different applications as being like an onion with the inner layers being highly-differentiated applications, which are a true core-competency for the business. As you go out further, the applications become more and more generic and hence similar between your organization and your competitors. At the very outside of the onion is the “vanilla apps,” those that are standard across all organizations – the typical example being email or office productivity. When thinking about a staged move to the cloud, approach your applications working from the outside in. As you become used to the way cloud works, and the opportunities and challenges it brings for your organization, you’ll be more ready for more complex and differentiated applications.

The other way I use the onion metaphor is to talk about organization porosity and outside involvement. At the very inside of the onion are those applications that only get exposed within the organization itself, and possibly only within one or two offices within the organization. As you go out further, the outer layers have much more need to interact with other parts of the organization (perhaps branch offices or whatever). On the outside are applications that have significant interplay between the organization and the outside world (be it suppliers or customers). Clearly the outer layers have much more validity as initial cloud projects; partly because there should be less security risk with these applications, but also because the agility and integration requirements of these applications makes them good candidates for cloud deployment

I don’t preach an “all or nothing” cloud approach. Cloud is a sliding wedge and existing organizations should look at taking baby steps and slowly increase the breadth and depth of their cloud usage.

For those who haven’t spent much time thinking about the term, BYOD describes the new paradigm where individuals within an organization supply their own devices (mobile, laptop, iPad, whatever) that they need to perform their jobs. The theory goes that by following a BYOD approach an organization will spend less on hardware; employees will be more productive since they’re using the gear they want to use; better care will be taken of expensive devices; and overall productivity and efficiency will rise.

Much time has been spent (and rightly so) looking at the security implications of an organization moving from one or two different form factors and operating systems to a paradigm where there could conceivably be a wide variety of device types, sizes, operating systems and software. All of which provides numerous new and frightening vectors of vulnerability. Often, however, the security argument is used as a proxy for an organizations yearning for lock down, for control.

Looking past the security debate, there is a bigger, and more exciting change occurring in the work place; one that points to some realities around the adoption of cloud computing.

Almost 20 years ago I wrote a paper while studying about my vision for the organization of the future. I used the term “organic business” to describe what I foresaw happening – this modern organization would have a small permanent central hub, but beyond that it would make use of a vast array of different individuals with specific skills.  These people would flow in and out of the organization on an ad hoc basis depending on the particular project being worked upon. Think of it like cells in the human body where a local infection (specific project) generates the attention of many different cells and systems in the body (project specific teams). These cells and systems sometimes work directly at the site of the infection, but also work in other areas of the body connected by a complex series of nervous and bio-chemical connections. This complex relationship between local and remote systems, permanent and temporary involved systems and complex communication channels perfectly mimics this modern organization that I prognosticated.

If this is the way the future looks, then how can we possibly expect an organization to control device types? This is fundamentally impossible, as a company will no longer have a hard edge between employees and the outside world. Rather it will have a massive selection of operatives who come and go regularly, but who all need to be kept in contact with their other team members – often times in vastly different time zones, geographies and working paradigms. The future then is about open architectures; the adoption of broad API strategies that allow every possible device to interact with core organization data; and an acceptance that everyone related to an organization will be working in a place, with a method, within a time zone and on a device that differs from those working alongside them.

A new startup out of Australia is looking to attack those perceptions head-on. Sentinus is a consulting company that specializes on short engagements helping to plan and review the security around cloud projects. It’s a high growth area – the success of new age consulting companies like Appirio shows that despite cloud being a key driver to self-service and end-user adoption – there is still a significant opportunity to add value in helping with the process.

Anyway – as part of their launch Sentinus developed the Sentinus Toolkit, a document which helps organizations with standards assessment, best practice guidelines and vendor selection when moving to the cloud. The toolkit is designed to help an organization find a cloud vendor they can trust. It uses best-practice in cloud security, service quality and architecture to expose hidden weaknesses.

Sentinus actually has a number of downloads which help organizations assess and review their readiness and their vendor’s suitability for purpose. One of these is the Sentinus 80 point safety check that goes through a bunch of different measures: features, service, policy architecture etc, to help customers get a rough assessment of a prospective supplier.

The rationale for what they’re doing (beyond, of course, gaining a bit of attention) is simple. Says Damian Bramanis, the Sentinus Director of Advisory Services;

We’re seeing a wealth of choices in cloud services, it’s like visiting a supermarket. The difference is, at the supermarket we’re protected with standards for food quality and labeling, but in the cloud it’s far too easy to end up with a rotten egg.

I have to say that much of what Sentinus is trying to do would be well delivered by an independent code of practice. As an aside I was heavily involved in creating what was the first of this kind of national codes of practice when a group of people, backed by a local industry watchdog and with buy-in from a number of vendors, created the New Zealand Cloud Computing Code of Practice.

I like the guides that Sentinus has developed, and having their content will only help to educate the market at large, I would say however that these sort of things are sometimes best delivered in a vendor neutral way and it would be great to see the Australian industry develop or adopt a broad CoP for themselves.

I’ve been a part of, or at least a witness to, a huge number of battles about what constitutes the “real cloud.” These battles seem to generally be fought on a Sunday afternoon U.S. time – that kind of suits me fine because it means the Monday mornings in my time zone have enough entertainment value to get me up and going.

Beyond the obvious entertainment value however is some pretty serious dogma that goes something like this:

• The public cloud purist’s argument goes something along the lines that only the public cloud can deliver the scale that drives the economies of scale to really make a difference. They also argue that private cloud is just about traditional legacy vendors selling more tin and the software that goes with it isn’t sufficiently robust for real world needs.
• The private cloud aficionados, on the other hand, say that the public cloud is a security nightmare with risks at every turn, it’s more expensive than traditional IT and that it simply isn’t reliable enough to be trusted

Obviously there are other nuances but this is the general thrust of the debate. As I say, it’s entertaining, but it’s ultimately damaging for those who are simply trying to articulate a value proposition that can deliver benefits for organizations.

Given this adversarial status quo, it was refreshing to open my RSS reader last Sunday and see an awesomely pragmatic post on GigaOm by Mark Thiele who, apart from being one of the thought leaders in the cloud, is also vice of data center tech at Switch Networks, the company that operates the seriously impressive SuperNAP in Las Vegas (if you ever get the opportunity be sure to take a tour there – amazing).

In his post, Thiele posited the concept of the “actual cloud.” He advises that when someone asks an organization what sort of cloud they’re using, the stock response should be “who cares?” Rather, people should be looking for achieving outcomes. As he points out:

When you’ve created a cloud oriented organizational model, then the technology that supports it is but an enabler. If you can solve the problem most effectively by cobbling something together yourself with all commodity and opensource then you should. However, if you can reach your objectives more quickly or cost effectively by buying a pre-packaged “cloud” offering or using a global public cloud service, then that’s where you should go.

Beyond fuel for the Sunday afternoon debate club, the technology you chose doesn’t really matter. What does matter is whether or not it’s delivering the speed, agility, efficiency and flexibility that your organization needs – and that’s where the actual cloud comes in.

In the post, the IT practitioner said that:

I’ve been involved on the periphery of several RFP responses, Statements of Work etc. that relate in one way or another to government agencies and large corporations outsourcing their infrastructure hosting to a provider. I’m not talking here about equipment co-location, but rather scenarios where the hosting provider owns the tin and truly delivers the Data Centre Infrastructure as a Service, including the storage. No doubt this is a growing trend both here in NZ and globally.

Nowhere during my involvement, which as I said has not been in-depth, have I come across descriptions, or requirements for that matter, on the “exit approach”

So I’ve been sitting here pondering, when the relationship between the customer and provider comes to an end after say, three, five or 10 years, and the customer has 100, 200, 600 TeraBytes of data sitting on the equipment (a SAN one would expect) owned by the incumbent provider; how on earth would they go about migrating this to the new infrastructure or archiving it off for later access?

Keen to hear people’s thoughts on this.

It really is a valid point. We all spend a lot of time worrying about getting our organization to start using a cloud service, but what happens when we amass vast quantities of data on that service and want to shift? Network limitations are such that this can cause real issues. It’s interesting to note that many cloud vendors allow customers to send data on tape or drive to the vendor as the fastest practicable way to migrate data across – if this approach needs to be taken at the start of a cloud relationship, imagine how much more important it is after a period of usage.

I’d be keen to understand whether organizations are thinking about this issue and, if so, what they’ve done to resolve any potential issues. Feel free to comment below.

One of the key points RackWare is trying to ram home is that of mobility – as users face increasing concerns about being locked in to one cloud vendor, RackWare automates cloud mobility by supporting any type of infrastructure – not just cloud but also plain virtualized and physical. They also provide that holy grail, a push button automated mechanism to move existing workloads between data centers and on to cloud infrastructure. Another aspect of this mobility is elasticity and RackWare is promising seamless cloud bursting potential using its tool. RackWare describes it’s product line over three distinct areas as shown in this diagram:

MyPOV

Today, and into the mid-term future, there is an obvious need for tools that automate the wildly heterogeneous variety of resources as organization have a wide infrastructure footprint across physical, virtualized and all flavors of cloud. I suspect however that over time the tendency will be to manage traditional infrastructure with traditional tools – and lump all the virtualized and cloud infra into one pool This speaks to a core point of contention in the community – that of whether existing legacy workloads will be left in situ or organization will try and forklift them onto new infra. I tend to be in the camp that believes that, most of the time, forklifting will be just too problematic and organizations will leave legacy stuff where it is. That being the case, a product that is mainly differentiated by the mobility it brings to enterprise workloads will lessen in importance.

This is especially so given the promise that initiatives such as OpenStack and CloudStack (and, to a lesser extent, Eucalyptus cozying up to AWS) bring – the ability to move workloads between different cloud vendors, and between public and private, quickly and easily. RackWare concedes this point, in my briefing they admitted that their mobility offering will be commoditized over time, however they were adamant that tying policy and automation into the equation gives them an increased degree of stickiness. In their view they’re a “RightScale for enterprise” – that’s a valid differentiator given the landscape right now.

RackWare has a difficult job to do – on the one hand they need to sell enterprise on the idea of shifting workloads while on the other continue to articulate a message that reduces enterprise appetite to simply go “all in” on the cloud – that’s a difficult balancing act and one which introduces conflicts at every turn, it’ll be interesting to see how RackWare deal with that.

Basically Sonsini talked about the massive opportunity he sees for PaaS providers to be the curators of services for their customers. To put it bluntly, Sonsini predicts a future where PaaS vendors will differentiate the rubbish add-on services from the solid ones, and deliver up the solid ones to their customers in some kind of marketplace. So far so good right? Well maybe, but it misses the point around cloud services.

In the infrastructure space we’ve reached a fairly common acceptance (well at least those not wedded to a “single vendor for everything” strategy) that the future will be heterogeneous with organizations leveraging the services of different cloud stacks, different hypervisors and different fundamental approaches depending on the needs of the particular business unit or workload in question. This is summarized by my contention that if we know anything, it is that the future is heterogeneous.

So let’s look at that for a second. Core infrastructure, delivered by seasoned IT practitioners who have the time and skills to wrangle solutions to fit a particular type of plumbing, will be heterogeneous in nature. Well if we accept that fact, how on earth do we expect one PaaS solution to meet the needs of every different use case and business unit within the organization? The fact is, the further one goes up the tack, the less likely it is that one solution will meet all the organizational needs. By extension, and logically following that thesis, clearly PaaS, like IaaS will be heterogeneous in nature.

If that is in fact the case, is it really either appropriate or effective for the PaaS vendor to be the gatekeeper to the services the applications on the PaaS uses? Or the management of the PaaS workloads? It seems to me not. In the same way that an organization’s infrastructural management is ideally managed by a third party service such as enStratus, so to are an organization’s PaaS assets, the services that plug into those PaaS’ and the different instances of all the different PaaS’ that the origination uses most ideally delivered by a third party provider.

It’s something I’m actually quite passionate about – not using management tools that force business units to adopt a particular solution that may or may not really meet their needs. It makes no sense and actually hampers the ability for cloud to deliver the benefits it promises.

Which brings me around, a little reluctantly, to Appsecute. I’m always loathe to write posts that seem to be self-serving to companies I invest in. But on the other hand I invest in companies precisely because I believe they solve a real problem. Appsecute clearly fits into that bucket. I have a couple of very strong beliefs as articulated previously:

• PaaS is the medium to long-term future of cloud services
• That future will be wildly heterogeneous

Put those two things together and what do you have? A requirement for a solution that gives an IT organization a broad management layer across multiple PaaS’ and multiple services that can be used with those PaaS’. Sonsini was so right in so many ways, but so wrong in so many others. Yes PaaS is a fantastic deliverer of different functional services – as it should be. But individual PaaS providers should not be the arbiters and managers of those PaaS services, rather a broad management layer is required to fulfill this need.

All of which makes using a single descriptor very difficult – if I call myself an investor only, there’s a whole bunch of stuff that misses out, similarly with other titles like “analyst”, “evangelist” and “commentator”.

So that being the case, today marks the simplification to the catch-all Diversity Limited, the organization under which I do all the different things I’m involved in. This makes things easier in terms of avoiding any confusion about my role and conflicts that it might cause, but more importantly it allows me to define a new type of role – one that brings together lots of different facets and in doing so creates significant value. So… since this post is all about clarification, here’s what Diversity Limited does;

• Commentary – over the past years I’ve written many thousands of blog posts and built a large following as a commentator covering general technology and cloud in particular. This isn’t going to change, I’m still going to be opinionated, call out bad behavior and generally say it how I see it. I’ll still be attending a number of vendor conferences and will cover vendor moves in the way I always have.
• Consulting – I’ve spent a lot of time in the last few years with large organizations helping them navigate their way in the cloud. I spend time with buyers advising them on technology strategy, I spend time with vendors and create awesome programs like CloudU. I’m going to continue doing this sort of work since it proves so valuable to organizations to have someone give an external perspective. Much of my work with end-user organizations is done on an ad-hoc basis. I enjoy sitting down with companies, looking at their technology mix and giving them some ideas on areas for improvement or general trends
• Advisory Work – I sit on a number of boards, both formal and informal, and do a lot of advisory work with startups. Sometimes this is paid, less frequently this involves equity and often it is simply done for the price of a cup of coffee (or a skype call). I do this because I love helping startups get to market and grow to scale. I enjoy it and love to make a difference, this sort of work will likely increase – from the work I’ve done across the dozen or more companies I’ve helped, this is something that I’m good at and drives real value for the companies I engage with
• Investment – I’m an investor in a number of different companies (a full list is here). Primarily I invest because these companies are doing something that all the work above identifies as a big opportunity of real value – in their different ways Appsecute, Cloudability, Connect2Field and the others deliver on my vision of technology making a difference in the real world

So what will change? Well I’ll stop using the analyst moniker since it doesn’t really describe what I do. I’m also mindful that my investing and advisory work has in the past caused sensitivities due to particular expectations of what the word “analyst” actually means.

Over the next little while I’ll be writing some more posts about the services I offer including some awesome things that I’m working on in concert with my friends Krishnan Subramanian from Rishidot Research and Alex Williams from TechCrunch. In the meantime however I’m hoping this clarifies my position, and now I’ll get back to work…

For a few years now I’ve noticed a convergence in the different areas I write about. Almost 20 years ago I wrote a paper about the dawn of a new type of organization, one that was organic and which morphed depending on the situation it was in from week to week and month to month. That was a great concept, but in the past technology was a barrier to this – staff couldn’t work remotely, infrastructure couldn’t be spun up (or down) quickly, and collaboration across multiple projects and departments was only a pipe dream.

Over the past few years however we’ve seen some seemingly disconnected changes in the way we work, and in the way technology works for us. The rise of mobile data and the ability to work via the Internet from anywhere; the increasing adoption of solutions that are built with a view to collaboration; and the ascendency of cloud infrastructure with the ability to spin up servers at will. All of these things, powered to a greater or lesser extent by the cloud, allow organizations to compete like never before, to react to changing situations like never before and, most excitingly for me, allow smaller organizations to absolutely “punch above their weight.”

The other day I read of an example of this in action. Tuihana café is a small café in Auckland, New Zealand. I’ve been involved in the hospitality industry and know that generally it’s a case of eking out a living and working on cost reductions to improve the bottom line. Tuihana, however, had the luck of being co-owned by a software developer, Nate Dunn. Dunn, being something of a tinkerer, decided to combine his love of tech with his new business. He created what is, essentially, a very simple system. Patrons text, email or tweet an order to the café where it is outputted to the barista to complete. The technology is simple – a GSM modem connected to a receipt printer; a script to automate collection of messages; and some search parameters within email and twitter. Nothing really out of the ordinary, and nothing, at first glance, to do with “the cloud.” I disagree, however. In my mind the cloud stands for a lot of things, one of the most important of which is the democratization of technology. The fact that a tiny café can leverage technology in order to introduce an innovative solution that meets its customers’ needs … well, that’s democratization in action.

I’m always keen to hear little anecdotes about technology being democratized in action – drop me a line if you have any…