Most people are familiar with the parable of blind men feeling different parts of an elephant. They describe their opinions based on partial experience and their descriptions are in complete disagreement about what an elephant is.
I feel the story relates to the cloud market in two respects - that many people are experiencing a similar partial view, and one particular aspect of the full potential is taking disproportionate attention - just like the elephant’s trunk!
Opinions are divided
For some time, cloud has been categorised into multiple layers of as-a-service: initially infrastructure-as-a-service, platform-as-a-service, software-as-a-service, as well as function-as-a-service becoming a de facto standard term and many vendors having their own thing-as-a-service too.
But would I argue that those categories provide limited guidance about the key characteristics of cloud services.
A recent article in The Register told of a user’s experience with a cloud vendor’s automated support and how he received an email giving just three-day’s notice that services would be removed, including his data. The services deployed and used were claimed to be business-critical. It did not matter which of the as-a-service family were applied.
Moreover, the user concerned felt that the notice period was nowhere near enough time to mitigate the risk by migrating to another service provider.
The importance of compliance
Another aspect of high importance is how a service - both physical equipment and operational support - adhere to local and global legislation such as GDPR. This has mainly been at the behest of lawyers.
These two examples show why I believe the emphasis on explaining as-a-service paradigms must evolve. We now know the key characteristics of elephants - not only trunks but large ears, near-circular feet, and ability to crush people. But we are still establishing how to clearly and consistently describe the most significant characteristics of cloud computing.
I believe the next period will have greater emphasis on whether service components and supporting aspects are publicly shared or private, i.e. degree of dedication to a consuming organisation, and on aspects of management across a full life-cycle.
These aspects clearly relate to core-IT best practices such as SFIA, and it should be for the IT industry, not the legal industry, to step-up. I do not advocate that as-a-service cloud vendors alone should do this, although several such vendors are recognising the need to express clear principles of how they will operate, in particular, relating to client data given episodes that have undermined trust.
Will this be entirely de facto or is there space for a standards body as we have for the internet? - I believe the latter.
Different options and solutions
In some ways such operational standards extend the maturity of technical standards for cloud. With several iterations of portability, mainly at the compute infrastructure layer, organisations can see value in embracing and integrating technology innovations in a standardised manner.
I see much potential at higher levels of the stack, for example, platform-as-a-service technical standards and data interoperability - we should welcome Sir Tim Berner’s Lee’s work about data ownership called Solid.
Why does this matter in the long run of things? Cloud is certainly not one thing and in articulating benefits and risks, professionals will value greater consistency of language, which I would suggest, will not be best if left to lawyers to determine!
Find some assistance
Enterprise architecture - as well as service management - can also help with this. Many EAs are embracing cloud, though they are still working in a bifurcated landscape of ‘legacy’ and ‘digital’ without overall influence: a risk for the organisations concerned and effectiveness of the EA professionals.
Cloud services can simplify or complicate many aspects of an enterprise architecture; certainly, the purist horizontal consistency sought by many for business, applications, and technology layers can be questioned as SaaS deliver without influence of underlying capabilities.
Mostly that should not matter, but EAs should determine which aspects do matter - the privacy and consistency of data being two common examples.
In this respect, cloud is changing EA. Even with clarity about which services differentiate an organisation, price points of mass-market offerings can compel decisions irrespective of worthy ‘city planning’ work. Perhaps fewer aspects should be governed by EAs for which they need to establish stronger rationale.
A rising technique to differentiate important versus commodity capabilities is the ‘mapping’ approach by Simon Wardley of Leading Edge Forum, whose work has risen in the age of as-a-service.
EAs will face other challenges. For example, having so many useful services available as a single integrated platform may not reflect an EA - so who wins, those who ‘plan the city’ or those that deliver?
Iterative innovation has challenged EA before where tactical decisions are rightly made but the throw-away deliverables live longer than intended. The cloud / as-a-service family is becoming so pervasive that it can span both sides of any bi-modal governance.
This test will be for good - EA teams have not been close enough to innovation in many organisations, and now that technical innovation platforms exist (platform-as-a-service), they cannot ignore the space.
Toward a conclusion
Finally, there is significant value that EA and other architects can bring to as-a-service paradigms. A major bank once told me that it felt like a herculean effort to make services live, which of course is a challenge that cloud with DevOps toolchains applied to agile/iterative delivery addresses well.
But the rub was comparing that effort with the time to retire services. While agile may encourage fail-fast and re-factoring, there is a real danger of vendor lock-in from cloud vendors that is generally understood but currently accepted.
In the same way that firestorm issues have made the industry to change in other regards - for example, misuse of social media personal data encouraged vendors to issue privacy policies, and the recent three-day notice of service closure reported by Reddit has raised the profile of durability - it would be regrettable if such an adverse scenario were required to force the issue of lock-in.
An adverse scenario is easy to imagine - namely market dominance leads a vendor to dramatically increase price. Architects should consider this potential carefully, and with standards emerging for most aspects of cloud, there is no reason this cannot be done. Again, a space where terminology could emerge.
The cloud paradigm - meaning the spectrum of as-a-service family - needs to be embraced by EA teams for them to become enterprising as well as enterprise architects; not for the technical features of latest infrastructure-as-a-service. For IaaS - and usually partially-managed IaaS - is surely the elephant’s trunk in my comparison, the thing that most distracts.
But the elephant can also crush people - for EAs this means cloud should be a paradigm not a few environments or services; so is embraced to raise the game of many roles. It will force the issue of who governs and how to do that. It is an opportunity for multi-discipline roles to either come together - which is only possible with clear language and perceptions.
What fascinates me is imagining the future language, techniques and roles to adopt with success.
