Notes

Underneath a successful piece of software lies a vast array of compute infrastructure like data centers, global networks, servers and storage, software delivery pipelines, monitoring and failover mechanisms, synchronizing data stores, backup and disaster recovery, and regulatory compliance reporting. Those aspects can consume a large portion of a software project’s timeline and budget before the first line of application code is ever delivered.

Platform 

A platform’s value isn’t just defined by what’s inside, but also by how easily its functions can be accessed. This is where cloud platforms shine

cloud computing has fundamentally transformed IT—from months of infrastructure planning and provisioning to running an automation script and waiting a few minutes.

Many organizations aim to shield developers from the specifics of the base cloud platform, driven by the desire to reduce vendor lock-in and also boost productivity. Sadly, more often than not, those platforms end up restricting developers’ choices and hinder productivity— clearly the opposite of what a platform should do.

in-house platform teams might lack the capacity to provide feature parity across web consoles, command lines, and APIs.

“When there is a gold rush, sell shovels,”

success with platforms rarely results from an IT department’s effort alone. Bridging both IT and business strategy is a key aspect of a successful platform strategy. Any gaps in this area can become the source of expensive failures.

Platforms enable, for example, base platforms and in-house developer platforms enable faster software delivery, whereas marketplaces enable the exchange of goods. 

For one, to fully benefit from modern base platforms, such as cloud platforms, an organization has to fundamentally change—or transform—the way it is working. Otherwise, you get the same old problems just in more modern packaging.

Strategy 

A strategy doesn’t imply climbing the hill in a straight line

Meaningful strategies must connect the dots between long-term vision and short-term tactics, between business and IT, and between quantifiable success metrics and beliefs.

When working in consulting, I found the term “strategy” frequently applied to justify actions that eluded any rational argument:

A strategy seems difficult to argue against: it lays out a compelling vision that might materialize sometime in the future and therefore can’t be proven or disproven so easily.

Although some amount of speculation can’t be avoided when predicting the future, that shouldn’t be a license to disregard current reality. Good strategies “think big” but are meaningful only if they can lay out a credible path starting from the here-and-now.

Organizations are hardly carbon copies of one another, so their strategies also shouldn’t be. A strategy should amplify your organization’s success as opposed to becoming like XYZ Silicon Valley company

IT and Business Strategy Form a Two‐Way Street, 

In traditional organizations, the technology strategy derives from a business strategy because the role of technology is to support the business. 

Document Strategy 

Aim for Emphasis Over Completeness

complex topics require abstraction, omitting details to amplify the important aspects.

You will see the forest only if you don’t concern yourself with every single tree.

Show the Path and the Terrain

A good strategy covers three dimensions, perhaps in the figurative, not the purely mathematical sense (see Thinking Strategy? Add Dimensions!):

1) A point: Where do you want to go?

2) A path: How will you get there?

3) The Terrain: What happens when you step off that path (or the ground

shifts underneath you)?

What not to do 

Including a seemingly endless and arbitrarily arranged list of strategic elements, each described in excruciating detail but in complete isolation, will make your strategy look more like a legal text and vastly reduce its audience.

helping people know and understand is something a strategy must do. To do so, complexity—the greatest enemy of that objective— has to be tackled with models that clearly communicate concepts without losing essential information.

The Yardstick. At the Singapore government we developed several simple models to help us make more informed platform decisions. A particularly effective one was “the yardstick” that visualized which part of a problem has already been solved, what needs to be built as a common platform, and what’s left to individual teams. Despite, or perhaps because of, being about the simplest model you can imagine, it proved immensely useful in our IT decision boards.

Some strategies stop at the first item and aren’t strategies at all—those are the mere wishes cited earlier. Actual strategies must lay out a path that will take the organization from here to there.

When reality doesn’t match the plan, we blame reality.

structuring your strat- egy document into four distinct but connected layers can help you steer clear of the IT Hourglass:

Context

describes why you are following a platform strategy in the first place. This part assures the aforementioned alignment with the business strategy. If this part isn’t clear, executives will stop reading right there.

Objectives

are business benefits that your strategy is intended to deliver. Reducing costs or speeding up innovation are worthwhile business goals. This section should place a clear emphasis on the top objectives instead of listing all possible benefits—too many items will weaken your strategy.

Mechanisms

are well-known techniques that help deliver your objectives. Increasing code reuse or enabling team autonomy are suitable mechanisms. The strategy needs to explain how these mechanisms support your objectives. Poor strategies look like an hourglass by falling for buzzwords like DevOps or microservices instead of elaborating.

Design decisions

denote specific trade-offs that you need to make during implementa- tion.For example, you might mandate that all developers use the same

programming language to make it easier to reuse other teams’ code. Alternatively, you might look to achieve the same by wrapping all code assets behind standardized service APIs—more complexity but also more choice. A good strategy describes these more “technical” considerations such that they can be followed by all stakeholders.

Transformation can’t be understood from the end product.

US manufacturers subjected each car to “quality assurance” at the end of production. This phase was essentially a euphemism for rework. Japanese manufacturers, led by Toyota, followed a very different philosophy: they re- alized that quality must be built-in, not added on at the end. It makes little sense to replicate a systemic defect 50,000 times over on the production line. They therefore did what would have been unimaginable in US plants: when they encountered a problem, they would stop the production line (using the famous “andon cord”) to investigate, so that they could correct it once and for all. Quality was built in, not added on. This fundamental shift cannot be seen nor understood by looking at the finished product.

Don’t Burst the Boiler

Companies that try to replicate other companies’ success without seeing how those companies in a fundamentally different manner are subject to the “burst- ing the boiler” 

Disruption means that someone has changed the rules of the game. Those who play by the old rules have already lost.