All Posts in Organizational Effectiveness

|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

|In: Organizational Effectiveness|Last Updated:

I wasn’t in the mood. I’ve been writing about shadow IT in recent columns, and discovered what follows from 21 years ago. It delivers some messages I’ve been wanting to cover without my having had to put fingers to keyboard.

Hope you like it.

– Bob

# # #

System changes are like Mexican butterflies.

For decades, we’ve been migrating functionality from applications to infrastructure. We used to choose the best application and bought whatever platform it ran on, congesting our data centers with a hodgepodge of incompatible systems. We’re smarter now … we understand that eliminating redundancy is as important in the platform layer of our technical architectures as in our data designs, so we establish technology standards and require new business applications to be compatible with them. In doing so, we’ve moved the physical interfaces, especially network and DBMS compatibility, into the technical architecture — we’ve moved functionality into the infrastructure.

With OO we create a library of reusable objects. Before OO we created subroutine libraries and COPYLIBs. These libraries are part of the infrastructure, too.

Have you installed an ERP suite? If you do, it has an API that turns it into a platform. By acting as a platform and not just an application, ERP has also moved functionality into the infrastructure.

Enterprise application integration (EAI) has the same result. It turns data and logic interfaces, which used to be part of your applications, into yet another part of the infrastructure.

Every time you move something into the infrastructure you improve maintainability, integration, consistency … all good things. Unfortunately, you also lose flexibility, because with all of these benefits comes interconnectedness. Like the butterfly of chaos theory, which supposedly messes up the weather in New England by flapping its wings in Mexico, even tiny application changes can have unexpected and significant consequences.

That’s a problem, because while we’re busily moving everything in sight into the infrastructure, increasingly sophisticated business leaders, workgroup supervisors and individual end-users spot endless opportunities for improving the business through information technology. Maybe it’s a Macintosh in marketing. Maybe it’s a tracking system for the trade-show team, a contacts database for public relations, or thought-mapping software for strategic planning.

Whatever it is, it represents a business improvement opportunity for some small community of interest in the company and another headache for you. They get the benefit, you have to maintain it, make sure it continues to operate when you upgrade hardware and operating systems, integrate it … and then it becomes part of the infrastructure, too.

It’s easier to just turn down these requests, because approving them all feels like being smothered by a swarm of Mexican Chaos Butterflies.

There is a third alternative to rejection and asphyxiation: Recognize that moving everything into the infrastructure is the equivalent of creating a centrally planned economy — in this case, an information economy. As we learned by watching the eastern bloc fall apart, when it comes to economies, central planning has its limits.

Not everything belongs in the infrastructure. Create a space outside the infrastructure for beneficial uses of information technology that just don’t fit, and don’t have to fit.

Create a multilevel support framework that establishes the ground-rules. A standalone system can be pretty much anything. If it needs to run on the network you need a traffic analysis; if it needs read-only access to existing databases you need volume estimates and adherence to security standards. If it needs to update core data … sorry, that’s a Mexican Butterfly.

For projects fitting the framework, the requestor is free to contract with an outside company — you’ll recommend one — and you’ll work with the contractor to make sure the results fit into this framework.

Don’t create the framework on your own. Develop it with key business users and ask your Systems Steering Committee to endorse it — it can’t succeed unless the rest of the business accepts responsibility and accountability for the information systems they ask for. Not everyone does. Sometimes, people asking for your help want you to turn them down. That way, they get credit for trying without the pain of change; you get the blame for being an obstacle to progress.

Turn the tables. Give them the worst thing anyone can get: Exactly what they’ve asked for.

Comments