The Best Digital Transformers Choose When to Choose

Bob Ross got it. The American artist used a couple of brushes and a handful of colors to churn out an endless series of landscape paintings on his show, The Joy of Painting. He didn’t waste time on the show deciding what tools to use. Rather, Ross voluntarily embraced a set of constraints up front and got down to business. He focused on what mattered: painting “happy little trees.”

The same goes for companies embarking on a “digital transformation.” Smart business leaders recognize the excessive number of options in today’s technology landscape, and the chaos it creates in IT departments. These leaders don’t fall victim to that chaos. Instead, they make a handful of key technology choices, empower their teams, and then direct their full attention towards the customer.

 

The Chaotic Landscape

Life was simpler when I started my tech career 20+ years ago. I spent most of my time building software, not choosing tools or platforms. When I started building web apps, there were only a few choices to make. For web frameworks, I picked among Java Server Pages, Classic ASP, Cold Fusion, PHP, or raw HTML with JavaScript. I had a couple of relational database options in front of me. At deploy time, I put code on physical machines.

But times have changed. Today, each programming language offers multiple web frameworks to sift through. I then have a dozen different options for hosting my software in public clouds like AWS and Microsoft Azure. To get that software running on one of those hosts, there are an endless set of deployment automation tools to pick from. Database engines? Don’t get me started. And then I still have to choose among on-premises, cloud-hosted, or managed offerings, followed by dozens of ancillary choices to make before calling my software complete. They include logging frameworks, monitoring tools, message brokers, networking services, and mobile notification services. The Cloud Native Computing Foundation paints an exciting, but overwhelming picture of today’s landscape.

That's a LOT of software.

 

The Paradox of Choice

This new technology is amazing. You and I can do things with software that we wouldn’t have even dreamed of 20 years ago. But there’s a problem: choice gives us freedom and flexibility, but also causes what author Barry Schwartz calls the “paradox of choice”. There’s a cost to all this choice: it delays decision making, causes distress, and it leads to post-decision regret.

  1. It delays decision making. With so many options available at the supermarket or car dealership, we agonize over what to choose. “I’ll just look at just one more.” It’s the tyranny of small decisions. You keep adding more items to consider.

  2. It causes distress. Loss has a higher psychological impact than gains. When we worry about making the wrong choice, it stresses us out. And because our concern for status among our peers leads us to always stay alert for the “next big thing,” we can never relax.

  3. All this choice results in post-decision regret. Even after we made a choice, we feel worse. We take longer to make a choice in order to minimize regret, but the nonstop deluge of opportunities that arrive after our choice keeps us from enjoying our decision. Our pleasure is short-lived.

 

Where to Have Opinions

If you don’t want to fall victim to the paradox of choice when making your digital transformation, the key is to establish some opinions. The below opinions can ensure you stay focused on outcomes, and not waste time endlessly debating things that won’t matter in the end.

Choose opinionated technologies

When I say “opinionated,” I mean technologies that steer you in a particular direction. They have default behaviors based on best practices. They integrate a set of components in a certain way for you to use them. Contrast that with unopinionated technologies, which offer a blank canvas.

Both have their place. For developer frameworks, something like Spring Boot is opinionated. When you choose this, you get a set of default behaviors (that can be overridden) oriented around time to value. Spring Boot is about limiting the choices you have to make around undifferentiated infrastructure configuration and putting your focus squarely on the software itself. See Matt Curry’s tweet:

Have opinions about the technology that runs your platform, too. Pivotal Application Service (PAS) has opinions. Run all sorts of software there, and embrace the guardrails. Instead of asking your team to assess, debate, and choose among an incrementally different set of application runtimes, pick one. And stick with it. This removes one more choice that gets in your way. Find opinionated tech that bundles together lots of micro-decisions into more macro ones.

Create an opinionated services marketplace

What database, messaging, machine learning, and app monitoring tools should you use? All of them? One of them? You could literally spend a year evaluating tech in each category, and are the endless bake-offs between products worth losing market share to competitors? Former Pivot Josh McKenty advises people that for mature categories (like relational databases), pick 2 options, stop there, and stick with them. Emerging technology like artificial intelligence? Loosen your restrictions. Read more on this topic in this whitepaper from Josh.

Instead of creating a Wild-West scenario where everyone can choose any tech they want, have opinions, and make it easy to self-service those choices through a marketplace. The Open Service Broker ushers in that reality. You choose the handful of products for each category, add them to your platform, and let developers loose. As new categories emerge or dissatisfaction rises with existing choices, reassess your opinions.

Establish opinions about app modernization

The software you have got you where you are today. Celebrate that. But now it’s time to figure out how to unlock new value, or prepare that software for more intense usage or uptime demands. App modernization isn’t a project, it’s a lifestyle. You’re never done.

To be successful here, you need a repeatable way to assess and execute. What does it mean to make something cloud-ready? Does every team follow the same approach? What’s “must have” versus “nice to have” when replatforming to a new stack? Pivotal’s App Transformation practice teaches your team the needed skills, while leaving behind a monster set of recipes for your team to deliver on over, and over again.

Our happiness and success are often driven by our ability to choose our own adventure. At the same time, I think we sometimes want decisions made on our behalf! When plotting out a successful digital transformation, you need less choosing, and more doing. Find technologies, approaches, and partners that you trust, and form opinions that help you stay focused on what matters most. If you want help with the “doing,” you know where to find us.

About the Author

Richard Seroter

Richard Seroter is the VP of Product Marketing at Pivotal, a 12-time Microsoft MVP for cloud, an instructor for developer-centric training company Pluralsight, the lead InfoQ.com editor for cloud computing, and author of multiple books on application integration strategies. As VP of Product Marketing at Pivotal, Richard heads up product, partner, customer, and technical marketing and helps customers see how to transform the way they build software. Richard maintains a regularly updated blog (seroter.wordpress.com) on topics of architecture and solution design and can be found on Twitter as @rseroter.

Follow on Twitter More Content by Richard Seroter
Previous
Say Hello to Pivotal Postgres
Say Hello to Pivotal Postgres

Pivotal aims to help organizations move off proprietary databases with a new self-managed offering of Postg...

Next
BOSH Fundamentals for PKS Administrators
BOSH Fundamentals for PKS Administrators

You don’t need to have a PhD in BOSH to have it be a useful tool in your toolbox. Learn more about BOSH and...

SpringOne Platform 2019 Presentations

Watch Now