Over the years I have witnessed, proposed and implemented a wide range of AWS use cases; and few of them actually belong in the sexier cutting-edge, containerised, hyper/auto-scalable, serverless micro-services realm. I mostly find a certain level of pragmatism - rooted in both tactical and strategic choices - involved in the adoption of Cloud:
- Proof of Concept development and testing
- Development of new products and services
- Off-premise backup, archival & storage
- Offload external website traffic
- Licencing and support shortfalls; in particular for relational databases
- End-of-life and out-of-support hardware and software replacement
While the business use case in the above-mentioned examples is generally relatively clear-cut I have witnessed less obvious use cases too - in particular in mature organisations.
Mature organisations are often entrenched in a particular market segment. There is often a focus on execution and operation; change doesn’t come easily for fear of business disruption - or due to budgeting constraints. Sometimes there may also be an outsourcing element to IT operations where only the operational aspect is well defined and covered by Service-Level Agreements. Therefore, development and ongoing improvements (including technical debt) often take the back seat and is addressed on a best-effort basis; sometimes resulting in projects logging requests and waiting for requisite new resource - or change - for weeks or months at end. In more extreme cases for well over half a year.
In situations like this, Cloud would seem the obvious choice; Solution & Technical Architects and Developers can get on with proof-of-concepts and development while waiting for operations to catch up. The obvious risk here is that of disparity of development versus production deployment platform, which has frequently caught out development and operations teams in the past; often late in the project at pre-production and even production stages. The other risk is that of what has been coined “shadow IT”; the adoption of Cloud services in order to “get the job done” and therefore no awareness - nor governance, monitoring or support - from an operational perspective. Finally - and often more crucially - there’s the organisational risk of obsolescence, i.e. disruption by other organisations because change is costly and comes so hard and slow.
Oftentimes, cost of Cloud is also used as a reason for not adopting Cloud. Organisations may already have sufficient existing on-premise or leased infrastructure to meet demands; something often enabled by virtualisation - the precursor to Cloud that we know today. There are even (infrequently) organisations that prefer CapEx over OpEx. However, one could argue that cost doesn’t really matter if rate of change and execution - and therefore competitiveness - increases; and therefore reduces organisational risk.
Agility is therefore not so much a question of technical prowess but rather an organisational and cultural mindset. The adoption of Agility often comes down to finding a common middle-ground between two organisational and market forces: change versus execution. This is especially true today where countless start-ups are vying to disrupt even mature markets like banking and insurance.
Ignoring this fact comes at great peril in terms of organisational success and life expectancy.
In conclusion, Cloud is a tool that can help facilitate organisational Agility to meet change and disruption head-on. But ultimately, that Agility must be culturally entrenched. This undoubtedly also adds more fun and job diversity for many employees.