FIGURE 10.2
These utilities are written in different languages, with different computational models and frequently incompatible data structures, developed by programmers of varying levels of experience, training, and professionalism. They were never designed to work together. Few, if any, were written to commercial programming standards. Most have not proven commercially viable and the source code has been contributed to the “open source” community. You can think of the open source community as a kind of superstore in the cloud with a growing collection of hundreds of computer source code programs available for anyone to download, modify at will, and use at no cost.
“Do It Yourself” AI?
Just like relational databases, just like ERP, and just like CRM, the knee-jerk reaction of many IT organizations is to try to internally develop a general-purpose AI and IoT platform using “free” open source software with a combination of microservices from cloud providers like AWS and Google.
The process starts by taking some subset of the myriad of proprietary and open source solutions and organizing them into the reference platform architecture that I describe below.
The next step is to assemble hundreds to thousands of programmers, frequently distributed around the planet, using a programming technique called structured programming and application programming interfaces (APIs) to attempt to stitch these various programs, data sources, sensors, machine learning models, development tools, and user interface paradigms together into a unified, functional, seamless whole that will enable the organization to excel at designing, developing, provisioning, and deploying numerous enterprise scale AI and IoT applications. How hard can this be? The truth is, if it’s not impossible, it is close. The complexity of such a system is two orders of magnitude greater than building a CRM or ERP system.
FIGURE 10.3
Many have attempted this, but to my knowledge no one has succeeded. The classic case study is GE Digital that expended eight years, 3,000 programmers, and $7 billion trying to succeed at this task. The end result of that effort included the collapse of that division and the termination of the CEO, and it contributed to the dissolution of one of the world’s iconic companies.
Were someone to succeed at such an effort, the resultant software stack would look something like Figure 10.4. I refer to this as the AI Software Cluster.
FIGURE 10.4
There are a number of problems with this approach:
1) Complexity. Using structured programming, the number of software API connections that one needs to establish, harden, test, and verify for a complex system can approach the order of 1013. (Putting this into perspective, there are an order of 1021 stars in our universe.) The developers of the system need to individually and collectively grasp that level of complexity to get it to work. The number of programmers capable of dealing with that level of complexity is quite small.
Aside from the platform developers, the application developers and data scientists also need to understand the complexity of the architecture and all the underlying data and process dependencies in order to develop any application.
The level of complexity inherent in these efforts is sufficiently great to assure project failure.
2) Brittleness. Spaghetti-code applications of this nature are highly dependent upon each and every component working properly. If one developer introduces a bug into any one of the open source components, all applications developed with that platform may cease to function.
3) Future Proof. As new libraries, faster databases, and new machine learning techniques become available, you will want to make those new utilities available within your platform. In order to do so you will likely have to reprogram every application that was built on the platform. This may take months to years.
4) Data Integration. An integrated, federated common object data model is absolutely necessary for this application domain. Using this type of structured programming API-driven architecture will require hundreds of person-years to develop an integrated data model for any large corporation. This is the primary reason why tens to hundreds of millions of dollars get spent, and five years later, no applications are deployed. The Fortune 500 is littered with these disaster stories. The systems integrator makes out like a bandit, and the customer is left with his or her pockets inside out.
The Gordian Knot of Structured Programming
Structured programming is a technique developed in the mid-1960s to simplify code development, testing, and maintenance. Prior to structured programming, software was written in large monolithic tomes replete with APIs and “go-to” statements. The resultant product might consist of millions of lines of code with thousands of such APIs and go-to statements that were difficult to develop, understand, debug, and maintain.
The essential idea of structured programming was to break the code into a relatively simple “main routine” and then use something called an application programming interface (API) to call subroutines that were designed to be modular and reusable. Example subroutines might provide services like complete a ballistics calculation, or a fast Fourier transform, a linear regression, an average, a sum, or a mean. Structured programming remains the state of the art for many applications today, and has dramatically simplified the process of developing and maintaining computer code.
While this technique is appropriate for many classes of applications, it breaks down with the complexity and scale of the requirements for a modern AI or IoT application, resulting in a Gordian knot described in Figure 10.4 above.
Cloud Vendor Tools
An alternative to the open source cluster is to attempt to assemble the various services and microservices offered by the cloud service providers into a working seamless and cohesive enterprise AI platform. As you can see in Figure 10.5, leading vendors like AWS are developing increasingly useful services and microservices that in many cases replicate the functionality of the open source providers and in many cases provide new and unique functionality. The advantage of this approach over open source is that these products are developed, tested, and quality assured by highly professional enterprise engineering organizations. In addition, these services were generally designed and developed with the specific purpose that they would work together and interact in a common system. The same points hold true for Google, Azure, and IBM.
FIGURE 10.5
The problem with this approach is that because these systems lack a model-driven architecture like that described in the following section, your programmers still need to employ structured programming to stitch together the various services. A reference architecture for a relatively simple predictive maintenance application is shown in Figure 10.6. The time to develop and deploy this application is 200 person-days at a cost in 2019 dollars of $600,000. The result of the effort is 83,000 lines of code that need to be maintained over the life of the application. The resulting application will run only on AWS. If you wanted to run this application on Google or Azure, it would have to be completely rebuilt for each of those platforms at a similar cost, time, and coding effort.
By contrast, using a modern model-driven architecture described in the next section, the same application, employing the same AWS services, can be developed and tested in 5 person-days at a cost of approximately $2,000. Only 1,450 lines of code are generated, dramatically decreasing the lifetime cost of maintenance. Moreover, the application will run on any cloud platform without modification, so you would not incur the additional effort and cost of refactoring the application should you want to switch to a different cloud vendor.
FIGURE 10.6
Model-Driven Architecture
Developed at the beginning of the 21st century, you can think of a model-driven architecture as the knife used to cut the Gordian knot of structured programming for highly complex problems.
Central to a model-driven architecture is the concept of a “model” that serves as an abstraction layer to simplify the programming problem. Using models, the programmer or application developer does no
t have to be concerned with all the data types, data interconnections, and processes that act on the data associated with any given entity, e.g., customer, tractor, doctor, or fuel type. He or she simply needs to address the model for any given entity—e.g., customer—and all the underlying data, data interrelationships, pointers, APIs, associations, connections, and processes associated with or used to manipulate those data are abstracted in the model itself. This reduces the number of elements, processes, and connections of which the programmer or application developer needs to be aware from an order of 1013 to 103, making the intractable now quite tractable.
Using a model-driven architecture, anything can be represented as a model—even, for example, applications including databases, natural language processing engines, and image recognition systems. Models also support a concept called inheritance. We might have a model called relational database, that in turn serves as a placeholder that might incorporate any relational database system like Oracle, Postgres, Aurora, Spanner, or SQL Server. A key-value store model might contain Cassandra, HBase, Cosmos DB, or DynamoDB.
The use of a model-driven architecture provides an abstraction layer and semantics to represent the application. This frees the programmer from having to worry about data mapping, API syntax, and the mechanics of the myriad of computational processes like ETL, queuing, pipeline management, encryption, etc.
By reducing the number of entities, objects, and processes the developer needs to understand from an order of 1013 to 103 and by freeing the developer from wrestling with all this minutiae, a model-driven architecture decreases the cost and complexity of designing, developing, testing, provisioning, maintaining, and operating an application by as much as 100 times or more.
The optimal design for an object model to address AI and IoT applications uses abstract models as placeholders to which a programmer can link an appropriate application. The relational database model might link to Postgres. A report writer model might link to MicroStrategy. A data visualization model might link to Tableau. And so on. A powerful feature of a model-driven architecture is that as new open source or proprietary solutions become available, the object model library can simply be extended to incorporate that new feature.
Another important feature of a model-driven architecture is that the application is entirely future-proofed. If, for example, you began developing all your applications using Oracle as your relational database and then later decide to switch to an alternate proprietary or open source RDBMS, all you have to do is change the link in your RDBMS meta-model to point to the new RDBMS. Importantly, all the applications you deployed previously using Oracle as the RDBMS will continue to run without modification after the replacement. This enables you to immediately and easily take advantage of new and improved product offerings as they become available.
Platform Independence
In my professional experience I have never seen anything like the adoption rate of cloud computing. It is unprecedented. As recently as 2011, the message delivered by CEOs and corporate leadership worldwide was clear: “Tom, what don’t you understand about the fact that our data will never reside in the public cloud?” The message today is equally clear and exclamatory: “Tom, understand that we have a cloud-first strategy. All new applications are being deployed in the cloud. Existing applications will be migrating to the cloud. But understand, we have a multi-cloud strategy.”
FIGURE 10.7
Wow. How did that happen? I am not certain that I can explain the 180-degree turn at global scale in the span of a few years, but there is no question it happened. And as discussed previously, it is clearly reflected in the revenue growth of the leading cloud vendors. It is also clear that corporate leaders are afraid of cloud vendor lock-in. They want to be able to continually negotiate. They want to deploy different applications in clouds from different vendors, and they want to be free to move applications from one cloud vendor to another.
So this becomes an additional requirement of a modern model-driven software platform. When you develop your AI application, it needs to run without modification on any cloud and on bare metal behind the firewall in a hybrid cloud environment.
The final requirement for the new AI technology stack is what I call polyglot cloud support—the ability to “mix and match” various services from multiple cloud providers and to easily swap and replace those services. The cloud vendors are providing the market a great service. Today they provide instant access to virtually unlimited horizontally scalable computing capacity and effectively infinite storage capacity at exceptionally low cost. By the time these aggressive competitors are through with one another, I believe the cost of cloud computing and storage will approach zero.
FIGURE 10.8
The second important service cloud vendors provide is rapid innovation of microservices. Microservices like TensorFlow from Google accelerate machine learning. Amazon Forecast facilitates deep learning for time-series data. Azure Stream Analytics integrates with Azure IoT Hub and Azure IoT Suite to enable powerful real-time analytics in IoT sensor data. It seems not a week goes by without another announcement of yet another useful microservice from Azure, AWS, Google, and IBM.
Polyglot cloud support is, in my opinion, an essential capability of the New AI Technology Stack. This capability not only allows application portability from one cloud vendor to another but also affords the capability to run your AI and IoT applications on multiple clouds simultaneously. This is important, because as these vendors continue to out-innovate one another, you can pick and choose microservices from multiple vendors to optimize the capability of your AI applications. And when a new and more powerful microservice becomes available, you can simply unplug the old microservice and plug in the new one. Your applications keep on ticking but now with greater performance, precision, and economic benefit.
FIGURE 10.9
Chapter 11
The CEO Action Plan
Greater Stakes, Greater Threats, Greater Rewards
Consider these facts: The average lifespan of an S&P 500 corporation in the 1950s was 60 years; by 2012 it was less than 20 years.1 Half of the companies that composed the Fortune 500 in 2000 are no longer on the list today.2 From 2013 to 2017, median CEO tenure at large corporations dropped by one full year, from six to five years.3 Acquisitions, mergers, privatizations, and bankruptcies have decimated the status quo.
I expect these trends will accelerate. The technologies driving digital transformation are now robust, mature, and widely available. Digital leaders will emerge across industries, harnessing AI and IoT to achieve step-function improvements in their business processes and outcompete slower rivals.
At the same time, capital markets become more efficient every day—adding to the pressure on underperforming companies that will be treated ruthlessly. Hawk-eyed hedge fund and private equity professionals constantly search for opportunities to acquire, merge, demerge, and liquidate corporations that show traces of vulnerability. The private equity industry manages $2.5 trillion, with nearly $900 billion in “dry powder” waiting to be deployed.4 This capital will not only be used in takeover bids—it will also be used to fund rapidly growing digital-native competitors. If history is any indicator, these funds will back growth enterprises that leverage modern technologies and will mercilessly exploit, dismantle, and destroy companies that do not. Companies that fail to digitally transform will be prime targets.
Competitive threats on the digital landscape can come from any and every direction, in unexpected ways. In January 2018, Amazon, Berkshire Hathaway, and JP Morgan Chase announced a joint venture into the health care industry. In a single day of trading, $30 billion of market capitalization was erased from the 10 largest U.S. health care companies, with some dropping by as much as 8 percent.5 This example may seem extreme. I assure you, it is just the beginning.
Although the threat of extinction is great and the need for action urgent, companies that succeed will be richly rewarded. Every significant study of the potential eco
nomic impact of digital transformation—by leading researchers like McKinsey, PwC, BCG, and the World Economic Forum—shows that organizations have the opportunity to create trillions of dollars of value through AI and IoT.
This is as close to a winner-take-all situation as I’ve seen. Companies that transform will be operating on an entirely different level from their lagging competitors. This will be tanks versus horses.
Digital transformation is the next do-or-die imperative. How CEOs respond will determine whether their companies thrive or perish.
The Transformative CEO
As we’ve noted previously, digital transformations are both pervasive—touching every part of the organization—and go to the core of the enterprise, the capabilities and assets that define and differentiate the business. For those reasons, digital transformation—to be successful—must be driven from the top down by the CEO, with full support from, and alignment across, all senior leaders and business functions.
In fact, digital transformation has completely inverted the technology adoption cycle that prevailed in prior decades. Previously new technologies frequently came out of research labs, new companies were formed to commercialize the technologies, and over time they were introduced to industry through the IT organization. And eventually, after gradual adoption, they gained the attention of the CIO. Only after years (if ever) did they reach the CEO’s desk—and this was usually only in the form of a brief or a budget approval requiring the CEO’s signature.
Today, CEOs initiate and mandate digital transformations. This is a big change—it is an entirely new paradigm for innovative technology adoption, driven by both the existential nature of the risk (transform or die), as well as the magnitude of the challenge. Whereas the CEO was generally not involved in IT decisions and strategy, today he or she is the driving force.
Digital Transformation Page 21