Business Goals and Digital Transformation
- Digital Transformation: What Is the Goal?
- Why Software Goes Wrong
- Your Enterprise and Conway's Law
- (Re)Thinking Software Strategy
- Are Monoliths Bad?
- Are Microservices Good?
- Don't Blame Agile
- Getting Unstuck
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
The most outstanding business achievement is to create a product that is needed by a great number of consumers, is completely unique, and is optimally priced. Historically, and in a general sense, the realization of such an accomplishment has depended on the ability to identify what is essential or highly desirable for a key market demographic. This is reflected in a maxim captured by the writings of Plato: “Our need will be the real creator.” Today, this statement is better known as “Necessity is the mother of invention.”
Yet, the most profound innovators are those who invent an ingenious product even before consumers realize it is needed. Such achievements have occurred serendipitously, but have also been born from those daring enough to ask, “Why not?”1 Perhaps mathematician and philosopher Alfred North Whitehead struck on this notion when he argued that “the basis of invention is science, and science is almost wholly the outgrowth of pleasurable intellectual curiosity” [ANW].
Of course, the vast majority of businesses face a stark reality: Breakthroughs in product development that lead to far-reaching market impact aren’t an everyday happening. Inventing entirely unique products that capture whole markets might seem as likely as aiming at nothing and hitting the center of a pot of gold.
As a result, the predominant business plan is to create competition. The uniqueness is seen in pricing the replica rather than in creating the original. Hitting such a large target is entirely ordinary and lacking in imagination and is not even a sure means of success. If creating (more) competition seems to be the best play, consider Steve Jobs’s advice: “You can’t look at the competition and say you’re going to do it better. You have to look at the competition and say you’re going to do it differently.”
Imitation is not a strategy. Differentiation is.
Differentiation is the strategic business goal that must be constantly sought after. If pure invention seems nearly impossible, continuous and tenacious improvement toward innovation should not. In this book, we have undertaken the task of helping readers achieve strategic business differentiation through relentless improvement in digital transformation.
Digital Transformation: What Is the Goal?
Understanding that the making of the unordinary is a major feat should not dissuade anyone from taking small, scientific steps with ongoing determination toward actual innovation. No matter the complexity in reaching Z, performing the science of experimentation to arrive at B when starting from A is a realistic expectation. After that, reaching C is doable, which then leads to D. It’s a matter of keeping our lab coat and pocket protector on, and acknowledging that unique products that can capture new markets have likely been staring us in the face all along.
Whether Microsoft Office was considered a worker-productivity innovation from the outset, it certainly has been the most successful suite in that market. With Office 365, Microsoft didn’t have to reinvent the word processor and the spreadsheet to innovate. It did, however, add a new delivery mechanism and capabilities to enable full teams to collaborate, among other features. Did Microsoft win yet again by innovating through digital transformation?
Digital transformation is left to the eye of the business innovator, but commonly businesses lose sight of the innovation part of transformation. Transformative innovation requires that the business understands the difference between changing infrastructural platforms and building new product value. For example, although taking business digital assets from the on-premises datacenter to the cloud might be an important IT initiative, it is not in itself a business initiative in innovation.
Does migrating your software to the cloud qualify as a digital transformation? Possibly, but more so if the move supports future differentiation. It best qualifies if the cloud delivers new opportunities to innovate or at least to unburden the extremely high cost of digital asset operations and channel those funds to new products. Think of the cloud as creating opportunities by freeing you from most traditional datacenter responsibilities. It won’t be transformative, however, if the shift to the cloud amounts to trading one set of costs for a different set of costs. Amazon offering its already successful computing infrastructure to the outside world was a digital transformation for the company that resulted in cloud innovation. Paying a subscription to Amazon to use its cloud is not a transformative innovation to the subscriber. The lesson is clear: Innovate or be innovated on.
Just as migrating to the cloud is not an innovation, neither is creating a new distributed computing architecture. Users don’t care about distributed computing, Microservices, or Monoliths, or even features. Users care about outcomes. Improved user outcomes are needed rapidly and without negatively impacting their workflows. For software to stand a chance at meaningful transformation, its architecture and design must support the delivery of better user outcomes as rapidly as possible.
When using the cloud, an improved architecture and design approach (and any additional well-tuned steps that lead to productivity gains) make reaching innovative transformational goals possible. Using infrastructure as a service frees the business to work on innovative business software rather than churning on trying to innovate on its infrastructure. Not only are infrastructure innovations time-consuming and costly, but they might not benefit the business’s bottom line, and developing infrastructure in-house might never address infrastructure and operational needs as well as AWS, Google Cloud Platform, and Azure. Yet, this is not always the case. For some businesses, it would be much more cost-effective to bring operations in-house or keep them there [a16z-CloudCostParadox].
Remember, it’s A to B, B to C, C to D. … Be willing to iterate on any of these steps so that you can learn enough to take the next one. Understanding that going back from J to G before reaching K is expected, and that Z need not ever happen, is liberating. Teams can innovate, but none of these transformational steps can tolerate lengthy cycles. Chapter 2, “Essential Strategic Learning Tools,” shows how experimentation is the friend of innovation and the enemy of indecision.
Software Architecture Quick Glance
This section introduces the term software architecture—a term that is referred to often herein. It’s a rather broad topic that is covered in more detail throughout this book.
For now, think of software architecture as similar to building architecture. A building has structure, and it reflects the results of communication that has taken place between the architect and the owner regarding the design features, by providing the features as specified. A building forms a whole system of various subsystems, each of which has its own specific purpose and role. These subsystems are all loosely or more tightly connected with other parts of the building, working separately or in conjunction with others to make the building serve its purpose. For example, a building’s air conditioning requires electrical power, duct work, a thermostat, insulation, and even a closed area of the building to cool, if that subsystem is to be effective.
Likewise, a software architecture provides structural design—that is, the formulation of many structures, not one. The structural design organizes the system components, affording them the means to communicate as they work together. The structure also serves to segregate clusters of components so they can function independently. The structures must, therefore, help achieve quality attributes rather than functional ones, while the components within implement the functionality specified by teams of system builders.
Figure 1.1 illustrates two subsystems (showing only a fragment of a whole system), each having components that work together internally but in isolation from the other subsystem. The two subsystems exchange information through a communication channel, with the box in between representing the information that is exchanged. Assume that these two subsystems are physically separated into two deployment units, and communicate via a network. This forms a portion of a distributed system.
)
Figure 1.1 A software architecture provides structure within subsystems and supports communication between them.
Another important aspect of both building and software architecture is that they must support inevitable change. If existing components fail to meet new demands in either architecture, they must be replaceable without extreme cost or effort. The architecture must also be able to accommodate possible needed expansion, again without major impact to the overall architecture.