All Posts by Bob Lewis

|In: Organizational Effectiveness|Last Updated:

In the mid-1990s I managed PCs and networks for a mid-sized enterprise. We managed maybe 10 gigabytes of networked storage (I’m working from my personal carbon-based memory, which isn’t all that reliable), which in round numbers might have cost us $10,000.

That’s when I participated in a Computer Associates focus group. CA was trying to sell the participants … sorry, it was trying to gain insights from the participants … about how to market its new LAN storage management solution.

The solution in question would supposedly give me the same capabilities my mainframe counterparts had – when a processing job ran low on storage it would spin off some jobs to tape backup in order to free up storage so the job could complete.

Privately, I was embarrassed – we weren’t running any batch processes on our network that might run out of storage, but I didn’t want to admit we were so unsophisticated. So I asked how much this marvelous technology might cost us. $50,000, the CA representative proudly told me.

Then I asked why spending $50K to manage 10 GB of storage made more sense than spending it to quintuple our storage so it would never run low in the first place.

And, as Arlo Guthrie said in a different situation, they all moved away from me on the Group W bench.

In 2006, Amazon launched AWS’s predecessor, the Amazon Elastic Compute Cloud. If there was a magic moment when cloud became a thing, that was it.

In rough, round numbers, between then and now, the cost of IT processing plummeted, from about $10/GFLOP to $0.1/GFLOP, a hundredfold decline.

The cost of storage experienced similar declines. In 2006, across all kinds of memory, IT spent about $10/GB. Today the number is $0.1 per GB, a remarkably similar decrease.

In 2006, cloud economics seemed to make sense to the various IT punditries who pundited about such things. But between then and now the cost of computing infrastructure has, it appears, declined by two orders of magnitude.

In case you’re wondering, yes, I did try to track down cloud pricing trends between 2006 and the present but wasn’t successful. At a guess, reductions in cloud computing costs have probably been commensurate with those of the underlying processing and storage they provide. And anyway, for this week’s purposes, I’m not sure it matters.

We’re not exactly revisiting FinOps and last week’s question of whether it’s important or just one more case of solving a five buck problem with a fifty buck solution.

The point: As the underlying costs of computing infrastructure continue to shrink, the value of carefully managing them shrinks in proportion.

Which gets us to this week’s more general question: Do the costs of governance, controls, and oversight of all kinds deliver enough value to warrant their cost?

It’s like this: Boards of directors aren’t free. Directors are compensated for their time, much of which consists of reviewing reports written for their consumption, which production also isn’t free.

The process of producing, reviewing, negotiating, and producing budgets takes immense amounts of management time and effort, not to mention the time and effort involved in comparing actual spending to spending budgets. Budgeting isn’t free either.

Stripped down to their essence, what governance and controls should be about is encouraging good decision-making (governance) and effective business action (controls).

For example, an IT Steering Committee will generally decide which of all possible projects IT will actually undertake (governance) and, when IT undertakes them, that the projects are properly managed so they deliver their intended results (controls).

What governance and controls too often become are stifling, choking bureaucracies whose primary purpose is to put managers on the defensive.

No, wait, that’s their secondary purpose. Their primary purpose is, as is the case with all bureaucracies, self-perpetuation.

So this week’s advice is simple and straightforward: Hold all governance and controls bodies to the same standards they hold everyone else to: They must be as efficient as possible and only solve problems that are important enough to be worth solving.

Bob’s last word: Researching this week’s column, surely, I said to myself, someone must have researched the very simple and basic question of whether organizations benefit from a positive return on their investments in governance and controls.

Maybe someone has, but if so I was unsuccessful in tracking down anything relevant.

Makes you wonder, doesn’t it?

Bob’s sales pitch: I’m widening the net. If you’re aware of any research along these lines, pass it along and you’ll get credit, plaudits, and kudos from the KJR community for your act of public service.

Comments

|In: App Dev Methodologies|Last Updated:

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.

Comments