Mark Porter at MongoDB explores the tax on innovation that rigid processes and a focus on maintenance rather than agility impose on businesses
We’ve all heard the now overused adage of the digital age: “Every company is becoming a software company.” What this trope is trying to convey is that innovation in the digital space – application development – is a major force in driving new business creation and competitive advantage. The speed with which a new application can be deployed, coupled with the quantity of innovative features in it, is a direct lever on the success of a business.
If applications are the currency of the new economy, then development teams are the market makers. However, despite the relentless strategic emphasis on speed and innovation in the digital economy, these teams continue to be misunderstood, mismanaged, and marginalized inside both large and small companies.
It’s not rational. Worse, it’s incredibly costly. Think about this as a tax on the amount of innovation that a company can produce. Companies pay this tax when they fail to understand the nature of the work developers do, or provide a safe and productive environment for them to do it. And if you don’t get that right, you’re not going to be in this game for very long.
Is your Innovation Tax DIRT cheap?
The innovation tax, like income tax, is real. Of course, this saps morale (with resulting attrition and churn), but it also has other financial and opportunity costs. Taxed organizations see their pace of innovation suffer as people and resources are locked into maintaining rather than innovating.
Another way to define this tax is DIRT. Why? Well, it’s rooted in data (D), because it so often springs from the difficulty of using legacy databases to support modern applications that require access to real-time data to create rich user experiences. It affects innovation (I), because your teams have little time to innovate if they’re constantly trying to figure out how to support a complex and rickety architecture. It’s recurring (R), because it’s not as if you pay the tax (T) once and get it over with. Quite the opposite. DIRT makes each new project ever more difficult because it introduces so many components, frameworks, and protocols that need to be managed by different teams of people.
It’s clear that technology leaders recognize this tax and immediately grasp the degree to which it’s caused — or cured — by their data architecture. Data is sticky, strategic, heavy, intricate — and the core of the modern digital company. Modern applications have much more sophisticated data requirements than the applications we were building only 10 years ago. Obviously, there is more data, but it’s more complicated than that: Companies are expected to react more quickly and more cleverly to all of the signals in that data. Legacy technologies, including single-model rigid, inefficient, and hard-to-program relational databases, just don’t cut it.
What does this look like in the real world?
If this were rare, it wouldn’t be such a big deal. But large enterprises can have hundreds or thousands of applications, each with their own sources of data and their own pipelines.
Over time, as data stores and pipelines multiply, an organization’s data architecture starts to look like a plate of spaghetti. The variety of technologies, each with their own frameworks, protocols, and sometimes languages, makes it extremely difficult to scale, because every architecture is bespoke and brittle. Teams spend their precious “flow” hours doing integration work instead of building new applications and features that the business needs and customers will love.
It’s clear that organizations are ready for a new approach. They know they need to simplify their data architecture, but many postpone this work – indefinitely – because it is just too daunting.
In many cases, the innovation tax manifests as the inability to even consider new technology because the underlying architecture is too complex and difficult to maintain, much less understand and transform. This is why a lot of senior people at enterprise companies are sitting with their fingers in the transformation dike, waiting for retirement — they think they can’t modernize.
Where do you start?
Start by getting a better understanding of just how DIRT might be holding your team’s back. Do your developers have trouble collaborating because the development environment is so fragmented? Do schema changes take longer to roll out than the application changes they’re designed to support? Do you have trouble building 360-degree views of your customers? And if so, why? These are all good places to start digging in the DIRT. You might also take a hard look at your applications and data sources, as well as what it would take to move your data onto an application data platform.
None of this will be easy and for many technology leaders you have spent most of your career working on problems like these. But that also means that you know progress when you see it, and starting with figuring out how to clean up your DIRT will put you on the right path.
Mark Porter is CTO at MongoDB
Main image courtesy of iStockPhoto.com
