The 'Solution Architect' Conundrum
One of the lessons I learned from a brief stint as a “Cloud Solution Architect” is that it’s easy to get away with murder! And murder being the (anti-)pattern of providing a quick cloud-native ‘solution’, using the latest and greatest (read: what the cloud vendor want you to sell) out there — and then not being there to face the music, when things go awry!
Of course, this varies from one organisation to another — but this is a general pattern observed in organisations that present (or make you perceive) cloud-native solutions as the knights in shining armour for the gullible damsels in distress organisations. The latter belong to two main categories:
Technical organisations who were doing great in the past, but their stacks have become stale over time, and hence want to join the cloud bandwagon, and,
Non-technical organisations, who have been sold the idea of cloud being a cheap and quick answer to a “happily ever after”!
In both these cases, sadly, by the time they realise that the picture is far less rosy than what it was sold for, it’s already too late! But the original intent of my post was more about the individuals who are bestowed with the responsibility of creating (and selling) their solutions. Often, the people at the receiving end are not savvy enough to understand the common pain points pertaining to cloud-based applications, to name a few:
the hidden costs (e.g. bandwidth usage, fringe services, storage costs, etc.)
the cost of maintenance (e.g. upgrading the instance types, vulnerability fixes, etc.)
other convoluted arrangements — e.g. a little birdie told me about a public cloud vendor trying to sell a
Java-based solution, where a simplenode.jsbased application would do the job. Reason being: Java-based solution consume more compute!
So, then, the integrity of the solution architects in-charge becomes crucial! Are they true architects or mere salespersons? Ethics and authenticity define their role beyond mere sales. A few things that could characterise it are:
seeing the solution through, and then taking a pulse after about three months or so of the solution going into production about how things are
doing their due diligence before recommending the shiny new service on the cloud to your customers, and,
asking about the non-functional requirements, and seeing that those are met in the solutions that they present. These should definitely include the running cost of the cloud-based application under peak load.
Now, since 'solution architects' may have limited influence on contracts and other legalities, the organisations engaging these cloud solution providers should ensure that their contracts include clauses expecting the following in a crisp and unambiguous language:
A post go-live warranty period, and then follow-ups at regular intervals for pulse-checks and course-corrections, if required
Agreed cost predictions, and then clauses on how much threshold breach would require the cloud solution provider to bear the cost
Agreed performance expectations, and well-defined SLAs for breaches
Bringing accountability would definitely minimise escape routes and raise the bar expected of cloud solution organisations and indirectly, their architects. This, in turn, would pave the way for more reliable agreements!