All Posts in Industry Commentary

|In: Cognitive Enterprise|Last Updated:

It’s time for businesses to think.

The Cognitive Enterprise (Bob Lewis and Scott Lee, Meghan-Kiffer Press) has been released into the wild. The questions of the hour: (1) What makes an enterprise cognitive? (2) Why does it matter?

There seems to be a strong negative correlation between the size of an organization and its ability to respond in sensible ways to changing circumstances. And this lack of good organizational sense seems to be independent of how smart the organization’s leaders and staff are.

It’s as if there’s an impenetrable barrier that prevents the considerable intelligence available in a business from influencing the behavior of that business.

Superimposed on this is the industrial model of business management — the notion that businesses should be “designed by geniuses to be run by idiots.”

This is the driving philosophy of most business process design: Simplify, simplify, simplify. Which, depending on the process and its goals, often is the best answer. In truly industrial situations — manufacturing and its analogs, where the goal is to create large numbers of identical work products — simplification and standardization make all kinds of sense.

But (you know “but” was just floating in the air, waiting to be uttered …)

With a few exceptions, business is first and foremost a game. It’s about winning and losing. In the short term, it’s pretty close to a zero-sum game, where one company selling more products to more customers means some other business will find itself selling fewer products to fewer customers.

There just aren’t that many games where success comes from streamlining, simplifying, and standardizing. In football, the winning teams aren’t the ones with the skinniest playbooks. In baseball, pitchers don’t throw every pitch exactly the same. If they did, they’d get shelled.

If you don’t like athletic metaphors, consider chess. Think a grandmaster is going to win by always playing the same opening?

* * *

Business designers follow a well-worn formula: People, process, technology.

Except it’s really PROCESS, Technology, people. No, it’s worse. People are an actual impediment. Carefully designed processes, written standard operating procedures, and automation are all established to overcome the limitations of we pesky human beings.

This worked just fine in the past because of a key and rarely explored metric — the stay-the-same to change ratio.

That business cycles are compressing isn’t a new insight. What’s often missed: Establishing well-defined and (more important) well-practiced business processes, supported by optimized automation, takes an investment of time, effort, and money. Having invested, businesses need a long enough period of stability to recoup that investment.

Business cycles are compressing — the stay-the-same piece of the ratio is shorter — but the change side of the ratio hasn’t compressed anywhere near as much.

Same investment, less time to get a return from it.

Which is why Scott and I are proposing a new framework. Instead of people, process, technology, cognitive enterprises will emphasize customers, communities, and capabilities.

Start at the end: A capability is anything an organization can do, independent of whether it’s doing it right now. Capabilities are what let an organization adapt to changing circumstances.

Communities next. More and more, the men and women who contribute their efforts to an organization’s success have less loyalty to their employer. (Employers, of course, jettisoned the quaint idea that they owe their employees any loyalty long ago.)

Supplanting, or perhaps augmenting employees’ relationship with their employer is their relationship with their profession and their peers in that profession. Developers, for example, constitute a thriving community, whose members are better at their trade in proportion to their community participation.

And their employers benefit from this by getting better programmers with a smaller investment in training.

Communities build capabilities.

And then there are customers. It might seem strange that customers need mentioning, but they do. Industrial businesses have a strong internal focus — so much so that most of the business considers other parts of the business to be their customers. This internal-customer focus is the source of untold mischief.

In a cognitive enterprise, everyone has the same customer — the real, paying customer who makes buying decisions about the company’s products and services.

And, understanding what these customers want, cognitive enterprises are able to marshal their capabilities to deliver it, whether or not they have a well-define process in place to do so.

Is this all there is to it? Of course not. If it was, Scott and I wouldn’t have had to write an entire book.

And we wouldn’t be asking you to read it.

Comments

|In: App Dev Methodologies|Last Updated:

I’m writing this the day after Thanksgiving. Yesterday, I was thankful when Da Bears implausibly beat the Packers. This led to a spiritual reflection on the limitations of the so-called golden rule, namely, that it only applies to like-minded individuals.

I reached this conclusion because of my wife’s family, which hails from within hailing distance of Lambeau Field and didn’t appreciate my enthusiastic response to the game’s outcome. Nor, to be fair, have I always appreciated theirs when faced with the more common result of Bear/Packer encounters.

What’s this have to do with DevOps, the subject we’ve been exploring in this space the last couple of weeks?

Not much. Except that applying DevOps to internal IT has golden-rule-like flaws (okay, it’s a stretch): As has been mentioned in this space from time to time, the similarities between developing commercial software or customer-facing websites and what IT needs to do are quite limited.

The big difference, as if you don’t already know what’s coming: Both waterfall and any of the popular Agile variants — Kanban, Scrum, xTreme, Test-Driven Development, and the strangely acronymed Lean Software Development — are designed to develop software.

And DevOps, in case you aren’t already aware of this, is built on top of one of these Agile variants, most often Scrum.

DevOps is a fine way to create software products, as Microsoft reportedly does. For that matter it’s a fine way for advanced retailers to constantly test new selling approaches on their websites. But … while the number of deploys per day is a frequently touted benefit in articles extolling the virtues of DevOps in retail, what these deploys are for is usually left to the imagination.

Which gets us to the questions raised last week about DevOps inside the enterprise, and an Agile methodology mentioned in this space several times but … and I apologize for this … never fully explained: Conference Room Pilot (CRP).

The question: Can DevOps be based on CRP instead of Scrum, and if so what would the result look like.

But first: What is CRP and why does it matter?

Answer: CRP is the only Agile variant designed from the ground up to implement commercial off-the-shelf software (COTS) and, by extension, Software as a Service (SaaS) solutions as well.

Here’s how it works.

First, IT installs the new COTS package to create the development environment. If the COTS system is supposed to replace one or more existing legacy systems, as is often the case, IT also converts the legacy data — a logically waterfall effort that shouldn’t be made Agile because what would be the point?

Next, whoever is in the best position to do so collects a few hundred or thousand test transactions, in the form of actual business conducted using the legacy systems over the past few weeks or months. These are staged as paper or electronic forms, whichever makes the most sense for use in exercising the new system.

One more preparatory step: IT trains a few developers in the new application — the ones it plans to turn into its gurus, because IT shouldn’t ever implement any COTS package without developing gurus for it — along with a training professional.

Now it’s time to lock the team, composed of business managers and users plus the newly anointed COTS gurus, in a conference room, to pilot the new system (hence the name).

Locked? Metaphorically — bathroom breaks are allowed, and pizza and beverages (caffeinated) are provided on demand.

The business users enter randomly chosen transactions into the new system. They’ll experience one of two outcomes: The new system will either:

  • Handle the transaction cleanly. Result — add it to the system’s automated test suite, for use later on to make sure changes don’t break what’s fixed.
  • Handle the transaction clumsily or not at all. Result — discuss it with one of the gurus, designing enhancements that don’t violate the integrity of the COTS system and do handle the transaction smoothly and efficiently. When the enhancements are finished and satisfactory, the transaction is added to the automated test suite.

Note that neither of the outcomes is “handles the transaction the way it’s currently handled.” There’s no intrinsic value to that, and that this is the case is a critical point, with which all team members are familiarized before being locked in the conference room.

By the time the team has plowed through the complete stack of prepared transaction and the resulting system passes the accumulated automated test suite, it’s ready for deployment.

Now it’s time for the magic question: What would the marriage of CRP and DevOps look like?

* * *

Sadly, we’re out of space, which means you’ll have to wait until next week for the magic answer.

Comments