Good golly Miss Molly!

It was bad enough when folks thought the original version of DevOps … developers and IT operations actively collaborating … was an original idea.

Note to everyone in the IT universe: No matter what your context is, and who you’re working with, you didn’t invent collaboration. If you want credit for originality, COME UP WITH SOMETHING ORIGINAL!!!!

Whew. I feel much better now.

As for DevOps, at least it evolved into something reasonably original, or at least something reasonably radical. To save you a few minutes of googling, in its current form DevOps has contributed two important ideas. The first is that development teams should always leave software in a deployable state (the deployment part of “Continuous Integration / Continuous Deployment”).

The second, which is foundational for all things Digital, is that automation should be the default no matter what process or practice you’re dealing with.

So far so good, and even better after Dave Kaiser and I layered in the idea of BusOps – that the collaboration between IT Operations and business Operations is just as important as the various collaborations IT developers should involve themselves in. (Want a more complete account? Oh, c’mon, you can afford the book).

But then someone had to invent DevSecOps. And CloudOps. MLOps (machine learning).

And now (drumroll) … we have FinOps, as in, someone should pay attention to a company’s cloud expenditures – “Cloud financial management,” in the words of the FinOps Foundation, which suggests that somewhere along the line, “Ops” and “Cloud” became synonyms.

Rather than just fixing the name (CloudFinOps … CFO for short?) let’s start right in on critiquing the FinOps Foundation’s six guiding principles:

Principle #1: Teams need to collaborate.

KJR perspective: Well, yes, that is the definition of “team.” Not original. Not even interestingly unoriginal.

Principle #2: Business value of cloud drives decisions.

KJR perspective: The business value of something should drive business decisions? No kiddin’ Dick Tracy. Not original. Not even interestingly unoriginal.

Principle #3: Everyone takes ownership of their cloud usage.

KJR perspective: Sure, if you want to slow everything down to a crawl. Certainly, those who consume cloud resources of any kind shouldn’t treat them as free. Yes, everyone should have enough awareness of what cloud stuff costs that they don’t make stupid decisions. But implementing technology-enabled business change is hard enough without worrying about nickel-and-dime stuff every step of the way.

Principle#4: FinOps reports should be accessible and timely.

KJR perspective: Oh, now we need FinOps reports? That means we need an organization to produce them. Which means … see Principle 3, because who’s going to own the costs of staffing and provisioning this new, emerging bureaucracy?

Principle #5: A centralized team drives FinOps.

KJR perspective: Of course it does. See the KJR perspective for Principle #4. Plus, this ignores a fundamental rule of organizational dynamics, which is that while centralization drives efficiency through economies of scale, decentralization is what drives innovation, by removing organizational barriers to rapid decision-making.

Principle #6: Take advantage of the variable cost model of cloud.

KJR perspective: We covered this ground a long time ago (“A cloud spiral of death,” 11/5/2012). If your demand for computing resources varies enough that being able to add … and shed … capacity as the situation calls for it matters, the public cloud’s variable cost model is downright nifty.

But costs that are variable are only useful when demand is variable. If your demand is steady and predictable, owning your own computing infrastructure might be more economical because you don’t have to tack on enough margin to turn a profit.

Bob’s last word: No question – organizations that operate without discipline usually end up collapsing under their own bloat. That doesn’t mean discipline should be imposed by layer upon layer of outside reviewers. All that does is create a high-friction enterprise.

An effectively disciplined organization, in contrast, comes from establishing a culture of discipline.

Culture is an organization’s lane markers. Governance and controls are, or at least should be, its guard rails.

If you hit them, something is already very wrong.

Bob’s sales pitch: Want practical guidance on how to engineer your organization’s culture? You need (here’s a surprise!) a book. Namely, you need Leading IT: (Still) the Toughest Job in the World. Chapter 8 will provide you with all the techniques you need to make this happen.

The Cloud is, too often, a solution in search of a problem. For many IT shops it is no longer a tool to be used in achieving a goal – it has become the goal.

Exacerbating the problem are the IT strategists who talk about the cloud without explaining which of cloud’s many definitions they’re talking about.

As always, KJR is here to help. And so, the next time the subject of “moving to the cloud” comes up, make yourself annoying by asking which cloud definition the speaker wants to move to. Among the possibilities:

Public cloud: A wholesale hosting solution, where IT can provision and de-provision (if that’s a word) virtual computing resources quickly and easily by just filling out a form.

Private cloud: A retail hosting solution, where IT can provision and de-provision virtual computing resources quickly and easily by just filling out a form, so long as IT has enough spare capacity on-line in its data centers to provision them.

Hybrid cloud: Public plus private cloud computing resources, seamlessly combined to use private cloud resources until they’re exhausted, then supplementing them with public cloud resources.

Software as a Service (SaaS): Commercial Off The Shelf Software (COTS, and no, I don’t know why the acronym only has one “S” in it) hosted in a public cloud.

Cloud as panacea: A version of public cloud that’s the driving force behind conversations that begin, “We don’t want to be in the data center business.” Sadly, like all acts of delegation, when IT outsources its infrastructure to a public cloud provider, the vendor is merely responsible for hosting IT’s applications. IT remains accountable however it hosts them.

Cloud as architecture: Establishing and enforcing the use of a standardized set of virtualized computing resources, so that all applications have identical hosting configurations.

Cloud discussions that don’t include cloud-as-architecture are likely to be pointless; also needlessly long.

Cloud-as-panacea discussions while even more likely to be pointless, will, in contrast, be mercifully brief.

Which brings us back to the SolarWinds fiasco.

An old but reasonably accurate critique of management consulting has it that management consultants will, if your organization is decentralized, recommend you centralize it to achieve efficiencies from economies of scale. If, on the other hand, your organization is centralized, we’ll recommend that you decentralize to encourage innovation by shortening decision chains and cutting down on bureaucracy.

The arguments in favor of IT’s collective move to public cloud computing is, for the most part, little more than an assertion that centralization is all upside with no downside – a panacea.

My concern: Not only isn’t it a panacea, but it creates enormous risks for the world economy. Why?

First: Public or not, without cloud-as-architecture it isn’t cloud. With cloud as architecture all computing resources a cloud provider delivers are, through the miracle of standardization, identical. While this certainly makes scaling much easier, it also means everything they host shares the same vulnerabilities.

Which in turn means public cloud providers will be more and more attractive targets because the very factors that make them appealing to IT make it easier for malicious actors to scale their attacks.

Bob’s last word: As SolarWinds-type breaches become more common, IT organizations will have to become increasingly sophisticated in performing cloud due diligence – not only on the cloud provider itself, but on its entire supply chain as well.

Bob’s sales pitch: What I’m selling is fame and fortune. Well, not exactly fame, but sort of; not fortune at all because I’m not going to pay you anything.

What’s the subject? ManagementSpeak is the subject. My supply is running low, and the demand is the same as always (one per KJR if I have any in stock that fit the subject).

So how about it? Keep your ears open and your translator engaged, and send in your juicy management euphemism … translation optional but appreciated. And make sure to let me know if I can give you credit as the source or you need to remain anonymous.