At this point, we’re all very familiar with the idea that “every company becomes a software company”.

But the meaning behind it is rooted in the fact that innovation in the digital age – app development – ​​is a driving force for creating new business and gaining competitive advantage. The speed of deployment and the amount of innovative functionality in a new application has a direct correlation to business success.

If applications are the currency of the new economy, development teams are the market makers. However, these teams continue to be misunderstood, mismanaged, and marginalized within organizations large and small. And companies pay a tax when they don’t understand the nature of developers’ work or don’t provide them with a safe and productive environment in which to do so.

Define DIRT

The innovation tax, like income tax, is real. Imposed organizations see their pace of innovation suffer as people and resources are locked into sustaining rather than innovating.

Another way to define this tax is DIRT. Why? Well, it’s rooted in data (D) because it so often stems from the difficulty of using legacy databases to support modern applications that require real-time data access to build user experiences rich. This affects innovation (I), because your teams have little time to innovate if they’re constantly trying to figure out how to support a complex, rickety architecture. It’s recurring (R), because it’s not like you pay tax (T) once and be done with it. Rather the opposite. DIRT makes every new project even more challenging as it introduces many components, frameworks, and protocols that need to be handled by different teams of people.

Clearly, technology leaders recognize this tax and immediately understand the extent to which it is caused — or cured — by their data architecture. Data is sticky, mission-critical, heavy, complex – and the heart of the modern digital business, and modern applications have much more sophisticated data requirements. Obviously, there is more data, but it is more complicated than that: companies are supposed to react faster and smarter to all the signals contained in this data. Legacy technologies, including rigid, inefficient, and hard-to-program single-model relational databases, are not enough.

daily DIRT

If it was rare, it wouldn’t be so bad. But large enterprises may have hundreds or thousands of applications, each with its own data sources and pipelines.

Over time, as data stores and pipelines multiply, an organization’s data architecture begins to look like a plate of spaghetti. The variety of technologies, each with its own frameworks, protocols and sometimes languages, makes scaling extremely difficult, as each architecture is bespoke and fragile. Teams spend their valuable “flow” hours doing integration work instead of building new apps and features that business needs and customers will love.

In many cases, the innovation tax manifests itself in the inability to even envision new technologies because the underlying architecture is too complex and difficult to maintain, let alone understand and transform. It is clear that organizations are ready for a new approach.

Start in the dirt

Start by better understanding how DIRT could hold your team. Are your developers struggling to collaborate because the development environment is so fragmented? Do schema changes take longer to deploy than the application changes they are designed to support? Struggling to create 360 ​​degree views of your customers? And if so, why ?

By starting to dig into the DIRT, you can better understand all of your applications and their data sources. It will also allow you to understand what it would take to move your data onto an Application Data Platform. That’s not to say it’ll be easy and it may feel like starting from scratch, but tech leaders have worked on issues like this before, so they know what progress looks like. And what success means for the organization. Start by calculating your innovation tax bill and you’ll be on your way.

About the Author

Mark Porter is the chief technical officer (CTO) of MongoDB, where he is responsible for shaping the long-term technology roadmap and vision for the company. Prior to MongoDB, Mark worked at Grab, the Southeast Asian super app that provides everyday services such as ridesharing, food, packages, grocery delivery, mobile payments and financial services to people. millions of people. Mark has also worked at AWS, NewsCorp and Oracle. He’s been coding professionally since he was 16 and founded and ran his own e-services integration business.

Featured Image: ©maxxyustas