12 Secrets of Digital Transformation: Part 3

In this 12-part blog series, Dr. Jim Walsh (CTO, GlobalLogic) explores how businesses can effectively embrace digital transformation. Read "Secret #2: Define and Become the Competitor You Fear Most" here.

Secret #3: Be Flexible About the End Goal and the Means; Look for the “Unexpected Upside”

Having just made the argument that you should begin by visualizing where you want to end up, I’ll also stress the contradictory point that you should not be too rigid about achieving it in detail. If you do transformation right, you will learn at every step of the way—and each step should inform the next.

In particular, having seen a lot of initiatives, I’ve come to believe that it’s a myth that brilliant business strategies are invented out of whole cloth and then executed mechanically. Successful strategies emerge in the course of execution, as one phase of work unveils additional possibilities and opportunities. There is no law against claiming that the end state was your secret idea all along—and many careers have been based on this kind of retrospective brilliance.  But the truth is that by-and-large the best strategies are discovered, not conceived of from the outset. The key is to get moving in generally the right direction, and then to stay alert and adapt.

In the course of your transformation work, entire new business models may present themselves—and you need to be alert to that kind of “unexpected upside” if you’re going to take advantage of it. For example, exposing your APIs or data to a 3^rd party developer ecosystem can—and likely will—result in your systems being used in ways you would never have imagined. This can uncover new revenue streams, if you stay alert for them. Also, you and your team may develop additional insights as each step forward potentially reveals more opportunities. This is not wishful thinking. In the course of executing a transformation project, additional business opportunities are almost always exposed. This happens whether you are consciously trying to enable a “pivot” to a new business model or whether you’re simply being alert to possibilities as they come along.

On the technical side, companies emerging from a classic IT mindset often have a great fear of failure overall—and sometimes even a great fear of being wrong step-by-step. We have one client who wanted to take months to decide between two competing containerization technologies, both of them leaders: one the established leader, and the other emerging. While it’s good to give these technology choices critical and intelligent thought, in a transformation project the choice between leading open source technologies should take, in general, at most one or two calendar weeks of effort. If you are working with an already-experienced person, it can often be done effectively in days or even hours—again, assuming you are choosing between the leaders.

In almost every case today there are at least two or three good options for each technology choice, each of them a “market” leader (I say “market” advisedly, because many of these technology leaders are actually open source and free). You are almost always better off thoughtfully picking one of the leaders and moving forward than you are going through a traditional rigorous months-long procurement-oriented selection process. The key goal of your research should be to uncover who the leaders are in a particular technology area—those driving innovation in their space, with wide or rapidly growing adoption, and with a vigorous community of support or “momentum” behind them. All the leading systems tend to be highly “competitive” and features that one lacks will often be added in very short order—often weeks or months. The key is innovation leadership, momentum, community interest and support—as well as a fit with your architecture, and the “philosophy” or direction of your development approach.

The optimum technology selection process has changed radically in part because the technologies themselves evolve so rapidly and in part because there are so many good and widely used options available. Much of this new software is free, all of it is easily available to developers, and much of it has a broad community of talent and support—including proof points in very large-scale projects, some of it most likely in businesses similar to your own. In this environment, what is “best” today is unlikely to be “best” eighteen months from now. This is not because the current best suddenly becomes “bad”, but because something even better will emerge. This constant stream of technology improvements is unlikely to let up for many years, if ever. It is therefore far better to plan for change than it is to spend critical months of your project looking for the ideal solution.

Similarly, your end-state architecture will also evolve as you move ahead. This should not be because you compromise it, but rather because you’ve learned there’s a better and simpler way to do it than you originally thought. You might also learn that the original business goals have themselves shifted—again, because you have learned more. If you accomplish only one thing in a transformation project, it should be to throw away the notion once and for all that “change is failure.” Change is not failure if it captures a business opportunity, simplifies or otherwise improves your system, and makes it more extensible and robust. Failure is being too rigid to meet the opportunities that present themselves.