All Posts in Industry Commentary

|In: App Dev Methodologies|Last Updated:

Not that I’m skeptical or nuthin’ …

The number being bandied about, and cited here last week, is that Amazon releases new software to production every 11.6 seconds.

It appears Amazon employs roughly 3,000 web developers, which means it’s arithmetic time. Let’s see: 86,400 seconds per day, 11.6 seconds per release, and that gets us to … carry the one … about 2.5 releases per day per web developer.

Does someone in earshot know enough about the situation to clarify exactly what each programmer is releasing 2.5 of to the wild every day at Amazon? Because never mind DevOps, and for that matter never mind some awfully fast coding. With developers this fast, who comes up with enough ideas to keep them busy, and how?

While the exact number seems suspicious enough to warrant skepticism, let’s give everyone in the DevOps public relations supply chain enough benefit of the doubt to accept that whether the actual number is 7,500, 750, or 75, Amazon releases a lot of new code to production every day.

When the new releases are going to a website or mobile app, as they are with Amazon, nobody has to worry about training or organizational change management. Amazon’s shoppers expect to figure out what they’re supposed to do next based on what they see on their computer or smartphone screens. They’re shopping, not engaged in mission-critical activities.

And what you see on Amazon, while it’s quite a bit more complicated than Google’s legendarily spare user interface, is still quite simple compared to what business users see when looking at a screen from one of the company’s enterprise applications.

Also: While there is, as has been pointed out in this space ad infinitum, not to mention ad nauseum, no such thing as an IT project (they’re all about business change or what’s the point? In case you haven’t been paying attention) when it comes to enhancing the company’s website, or mobile app, or, for that matter, software products like operating systems and office suites, for all intents and purposes the business change is done when the software hits the production servers.

That’s in contrast to any change you’d be likely to make to the company’s ERP, CRM, supply chain systems, or what-have-you. The whole point of changing or enhancing the company’s internal systems is to support a change in how we conduct business around here.

DevOps for internal applications is, that is, qualitatively different from DevOps for customer-facing applications.

Which brings up another thought: When it comes to customer-facing systems, faster is very often better. Even if it isn’t truly “time to market” in the sense of being able to sell “new and improved” before your competitors can, when interacting with Real Paying Customers, novelty has intrinsic value.

But when it comes to employee-facing applications, slip-streaming application changes mostly means confusing employees, disrupting an established business process with no clearly defined process change in view.

Internal releases aren’t just software changes except for those that do nothing but fix bugs or modify algorithms hidden from the view of the employees who see their results.

Internal releases are business change releases. Otherwise they’re just releasable builds — dots to be connected when the actual release is ready for deployment.

Releases that are business changes call for communication, retraining, sometimes changes in the metrics the company uses to gauge its effectiveness, and occasionally something even more extreme, like changes in reporting relationships.

There are situations when changes to business processes can be just as iterative and incremental as Agile makes software changes and enhancements.

But just as often, and especially when regulatory and compliance issues are involved, bundling business changes into controlled releases really is the better choice.

Business change like this isn’t necessarily better for being faster.

DevOps still might have a place here, but its place is more likely to be releasing a continuous stream of small changes to a sandbox environment than true continuous integration and delivery.

There’s little value in IT dramatically outpacing the natural pace of change in one or another part of the business. Unless, that is, the natural pace of business change is slower than it ought to be because everyone expects IT to be the bottleneck, and adjusts their velocity expectations accordingly.

Blowing up those expectations? It can do wonders for a business culture steeped in the perverse pleasures of slow.

Comments

|In: Cognitive Enterprise|Last Updated:

We’re waiting on the proofs for The Cognitive Enterprise (Bob Lewis and Scott Lee, Meghan-Kiffer Press). It should be available in a week or two. To whet your appetite, here are some excerpts from the Introduction:

People, process, technology.

When running a business we have to think in these terms, or so we’re told by those who tell us such things. We’ve said such things ourselves.

But while they say “people” first, most often these business experts actually put process in first place. Technology comes in second, playing an important supporting role.

People, when they finally make an appearance … mostly represent irritating contributors to organizational change resistance. Something that must be overcome.

It’s really PROCESS, Technology, people.

While dehumanizing, this perspective worked pretty well for the industrial age of business …

Organizations “designed by geniuses to be run by idiots” was pretty much the game plan for the industrial age. Instead of operating through practices that were as smart as the smartest practitioner, businesses operated according to processes designed with a focus on simplification and standardization. These aren’t bad things in themselves, but they’re unfortunate in how they encourage employees to disengage their brains when they enter the building.

Businesses built to this model — call it the “industrial model” — are anything but cognitive. They’re nothing like an entity that pays attention to the world around it, evaluates itself and its changing situation, and continually adapts …

Even companies that aren’t in the Industrial business of creating lots of identical copies of things have, to their detriment, adopted practices designed for companies that are, because that’s “best practice” — a phrase that should, in your loyal authors’ opinion, be taken out and shot …

For more and more businesses, the industrial perspective and the hidden assumptions it rests on are obsolete. A constellation of forces are making them an impediment to success …

Before we get to that, there’s one hidden assumption that has to go by the wayside immediately. It’s the assumption that businesses are just like people only bigger …

They aren’t. Nor are they merely the sum of the individual human beings who work in and for them, any more than you are merely the sum of your intestines, spleen, brain, and so on …

Human beings are more than their component parts. Businesses are, too. They’re an artificial life form, created by human beings but non-human in their anatomy, physiology, and behavior. Among the differences, two stand out:

  • Humans are presumptively moral. Businesses are demonstrably amoral. We rightly assume most of the people around us, most of the time, aren’t going to behave in ways that are excessively nasty … the systems set up to enforce [our laws] are scaled to the assumption that people who violate them are the exception.

Businesses, in contrast, have as the bedrock principle of their moral code their fiduciary responsibility to their shareholders …

  • Human beings think before making decisions. Businesses, in contrast, aren’t intrinsically cognitive entities …

The closest equivalents to human-style thinking businesses have are the governance mechanisms that in principle make some business decision-making independent of the foibles of the individual human beings involved.

But governance is often window-dressing, with actual decision-making the result of horse-trading among the human beings who are supposed to be acting in the corporation’s best interests. It’s also commonly slow and cumbersome, unsurprising given that the fundamental building block of most governance is the committee …

But enough of that … our goal isn’t to bore you to death. It’s to provide practical guidance on making an organization behave more like an intelligent, purposeful organism and less like a directionless ecosystem.

Consider the difference between an organism and an ecosystem and it will be clear. Organisms act as a whole. As entities they make decisions, whether they’re as simple as an amoeba or as complex as Homo sapiens.

Ecosystems are just as complex as organisms … more … but don’t act with purpose … any “decision” an ecosystem makes is the accidental direction set through the “invisible hand” of all the plants and critters that live in it.

Most large enterprises are more like ecosystems than organisms, hence the old phrase, “It’s a jungle out there” …

A cognitive enterprise is one that acts more like an organism — one where business decisions are about the success of the business in its environment.

The point and purpose of this book is … to make the business, if not truly cognitive in the sense of being an entity capable of human-style thinking, at least an entity that mimics it in rudimentary but useful ways.

That’s what this book is about: How the hidden assumptions that led to the wholesale dehumanization of large enterprises are less and less valid, what the new circumstances are that are supplanting them, and what to do about it all.

* * *

Sorry. I know book excerpts don’t make for the best reading. But my wife and I took a road trip this weekend and I didn’t have time to write a real column.

Comments