Recently IDC predicted that IT spending will drop by 5% due to the COVID-19 pandemic. Last week, Gartner went further by predicting that IT spending would drop by 8% or $300 Billion. (Expect a prediction bidding war.) Both were consistent: highest hit areas would be devices, followed by IT service and enterprise software.
The predicted $100 billion drop, in those last two categories, should send chills through those of us who make our living in those two categories. And keep in mind, this drop will occur in the latter half of this year. To date, here have been very few cuts.
But I’m seeing the glass half full here. Half full of lemonade.
Here is my thought process:
- For at least five years, we have been advocating to abandon the senseless implementation of application after application. (You know: the silo making industry.) We have made a strong case for avoiding the application centric quagmire in Software Wasteland.
- And yet spending on implementing application systems had continued unabated since 2015.
- With the need to slash budgets in the latter half of 2020, the large application implementation projects will be the easiest section to target.
- Indeed, the IDC article says that “IT services spending will also decline, mostly due to delays in large projects.”
- Furthermore, “some firms will cut capital spending and others will either delay new projects or seek to cut costs in other ways.”
- Gartner reported that “some companies are cutting big IT projects altogether; others are ploughing ahead but delaying some elements of their plans to save money.”
- Hershey has halted sections of a new ERP system and will drop IT capital spending from the budgeted $500 million to between $400-450 million.
- Gartner also stated that “health care systems [are] pushing out projects to create digital health records by six months or more.”
This would be a terrible time to be an application software vendor or a systems integrator. The yearly 7% reductions in both categories are still in front of us. Any contract not yet signed will be put on hold. Even contracts in progress may get cancelled.
Massive IT Budget Cuts a Good Thing
Why do I think this will be a good thing?
For several years now, executives (well some executives) have heard the message that the application centric approach is deeply flawed. However, they have not had the conviction to act and to reverse course. Inertia is a powerful force. There is a large ecosystem that depends on maintaining the status. As Vinnie Mirchandani points out in SAP Nation, there is an interlocking web of intermediaries that depend on the status quo continuing, and actively enable it.
But now, that inertia is put on pause. Some of these massive projects are being put on hold. Executives will begin to discover they were not as essential as once thought.
This creates space and ironically, a budget. When you need to cut $30 million out of your budget, and the easiest target is the $50 million application implementation project. And suddenly your budget isn’t down by $20 million, but rather up.
When the franticness and death marches of application implementation projects cease, there is time to think. To think about the alternative.
And that alternative, of course, is “data-centric.”
If you are a regular reader of this column, you know that the data-centric approach turns the relationship of applications and data on its head. For the last fifty or so years, applications owned their data. The application defined the data model, named all the fields and forms, controlled all the access. The net result was that large firms ended up with thousands of application databases, each with their own idiosyncratic view of what is mostly shared data.
For a long time, starting with an Enterprise Data Model was just too hard. Some firms tried building an EDM and most gave up after two to three years. These models were incredibly complex and generally were the union of hundreds of already complex models. Part of the problem was that the modelers were going into agreement with the many arbitrary decisions that the application modelers had adopted (most of whom didn’t work for the company (they worked for the packaged application vendor.) In fact, many didn’t even work in the same industry. The implementation team had dutifully force fit the application into the enterprise, and then the EDM team adopted many of those transplanted idea.
The other difficulty with the EDM was that people tried to implement it with the technology of the day (that is, relational), which is notorious for promoting complexity and rigidity.
Those few who persisted and managed to build an EDM (and we have seen a few) were unable to get their sponsors, who were hell bent on implementing yet another packaged application system (which of course had no resemblance at all to the EDM), to comply.
However, something has been quietly shifting in the background. The Semantic Web, which was perhaps overhyped and then summarily pooh-poohed, has gradually come into its own. Google’s Knowledge Graph is a direct descendent of the Semantic Web based Knowledge Graph which was obtained with the acquisition of Metaweb. Have you noticed over the last several years the difference in what Google serves up? It used to be key words from documents (their key innovation being the page rank algorithm). Now, it is the answer to your question, not a document that happens to have the key word.
Most of the digital native companies (Facebook, LinkedIn, Twitter and the like) are powered by Graph Databases.
We have found a couple of unexpected benefits in leaning into the Graph DB + Semantic Technology approach:
- It is possible to build an Enterprise Model (an Enterprise Ontology) in a few months. These models are orders of magnitude simpler than their predecessors. They are flexible and extensible. They resemble conceptual models, but they can be directly implemented (there is no transform to logical, transform to physical, it is just model and go).
- It is relatively easy to bring existing databases into alignment with the Enterprise Ontology. There are a number of open standards (R2RML) as well as open source tools (TARQL) that make turning relational data into triples a simplified task.
- There are existence proofs on what can be done to integrate unstructured data with structured data, using graph technology. For the longest time this was the holy-grail of integration. But go to DBpedia and see what they have done. They have extracted natural language from Wikipedia and put it in an RDF Graph Database. It is available for free querying at their SPARQL endpoint. Just learn a bit of SPARQL (another W3C standard) and you’re off to the races. Alternatively, you can read Bob DuCharme’s exemplary introduction Learning SPARQL.
Speaking of existence proofs, check out the Linked Open Data Cloud. There are hundreds of billions of triples all conforming to the Semantic Web standards. Many of the 1200+ datasets are open source, and “linked” with one another. This is two things in one:
- It is a vast resource of data, ready to be integrated with your own data. All you must do is follow the standards, and learn how to resolve identifiers
- It exemplifies what can be done within the enterprise. Whether you choose to use any of the free data or not, look at what they have done. Hundreds of organizations have aligned thousands of datasets without a top down command and control infrastructure. Imagine doing something similar across the divisions and departments of your firm. It is possible.
- There is life after data warehouses, data lakes and data analytics. While all those approaches were helpful in combining data from many disparate sources, each was a dead-end road. You can bring data into your warehouse/lake/analytics platform, but it is essentially read only data. These platforms are designed to not be operational/transactional systems platforms, and therefore they cannot replace legacy systems. They can only be an add onto them. Conversely, RDF Graph Databases can perform both as an analytics platform (and this is where most companies start), but then can gradually start taking on online transaction processing capabilities to replace the burdensome maintenance money sucker tie legacy systems have to IT budgets.
What to Do When Your Budget Gets Whacked
First round up the budget that got spared. There will always be some.
Put together a council to consider how you might take advantage of these changed economics. There will be some investment to be made, some new approaches to learn and some new technology to master. But all of it has been well proven now for over a decade. It is based on standards and therefore avoids vendor lock in and greatly delays technical obsolescence.
You will need to launch some pilots. We recommend pilots and not proofs of concept. A proof of concept is to show that the technology works in general. Vendors will be happy to do this for you for free or for nominal charge, but it is a distraction that does not need proving. The technology works. Just ask Alphabet shareholders.
The need a pilot is because most of the people in your organization have trouble thinking abstractly and will rapidly revert to what they know and how it relates to them. A pilot uses real data on a real business problem, but does it in a sandbox. Users and sponsors understand the power of this approach when they see their own data, expressed in ways they have never seen before. They understand the business value when they see queries revealing data being blended that couldn’t be posed previously to answer complex business questions. After this step, adoption becomes much easier.
The pilot gives common language and shared understanding to plot your course forward with confidence. The pilot, and even the subsequent follow up projects as you begin to build this out for real, will be a fraction of the cost of a single major application implementation project that was just cancelled.
And to think, as odd as it sounds, you have the coronavirus
to thank for clearing your path to the future. Now, go make some lemonade!
 For a few good “life gives you lemons quotes” see https://shakejump.com/funny-when-life-gives-you-lemons-quotes/