How do you keep your innovation speed?

[ad_1]

Presented by MongoDB

Success in the digital age is based on the ability to quickly deliver new experiences to customers. That’s why businesses are rethinking not only their company’s front-end, but every level below it as well. They are streamlining their supply chains, optimizing customer feedback loops, keeping less inventory, and applying metrics and AI / ML to generate operational insights. All in an attempt to accelerate.

So when it comes to digital innovation, faster is better. Quite right? Not so fast.

Forward-thinking business leaders know that the decisions they make today will determine their competitiveness for years or perhaps even decades to come. With this relentless push for speed comes the temptation to skip the basics. Cutting corners with security or privacy, blocking proprietary technologies, or racking up a huge tech debt has long-term consequences.

Over time, these consequences add up, leading to an innovation tax that must be paid continuously in the form of inflexible technology, lost productivity and slower time to market. And companies that don’t pay attention to this risk losing their best employees a silent and difficult-to-measure tax that has nevertheless killed some of the most innovative products on the market.

But there is a way for business and IT leaders to exercise both fast-twitch and slow-twitch muscles in this race; think short and long term. At MongoDB, we call it sustainable speed and it starts with making sure the right digital foundation is in place. We believe that the cornerstone of your digital foundation is your data, the raw material of innovation in the digital age. In our work with thousands of customers, we have identified four pillars of sustainable speed, each enabling organizations to accelerate innovation without incurring long-term disasters.

Multi-cloud agility

Not all clouds are created equal and neither are data centers. The fact is that each cloud provider can be the best cloud provider albeit for different users, in different situations. While each provider offers a portfolio of services, they are not the same in terms of functionality or maturity. Developers should be able to use the best technologies across clouds not just for different apps, but for the same application.

Imagine that your developers are able to use AWS Lambda, Google Clouds AI Platform, and Microsoft Azure DevOps within a unified console. Also, despite the energy around the cloud, very few of the large companies I speak to are all-in to the cloud, some plan to move slowly or even never fully move to the cloud due to regulation, compliance or even costs on large scale. Don’t fall into any kind of mantra about all-in on one thing or the other, listen to your business units and listen to the developers in them.

Speed ​​of innovation

If applications are the currency of the new economy, development teams are market makers. Yet despite the relentless strategic emphasis on speed and innovation in the digital economy, these teams continue to be poorly managed and malnourished within companies both large and small. To maximize developer innovation output, companies need to make an effort to understand the fundamental nature of development work, providing the most intuitive and flexible tools on the market and removing time-consuming undifferentiated work, such as database administration. .

Listen to your developers when they talk about wanting to fix the basics of their testing, distribution, or monitoring systems. And invest in the daily workflows of developers, removing barriers and simplifying the process when possible.

Predictability (aka, reliability)

This is where we start thinking about the ability to build fast, but with confidence. Building or updating mission-critical applications is always a high-risk job, with inherent risks of data loss or violation of regulatory requirements. Executives need to be confident that their application development platform will protect customer and corporate data integrity, handle outages without significant impact (internal or external), and adapt to the company’s ambitions.

Build this trust by regularly asking your leaders and their teams to raise areas of concern around the layers of what I call The Requirement Onion.

These are:

Security Durability Correctness Availability Scalability Operability Functionality Performance Efficiency

The first six are the ones that, if you get them wrong, can completely destroy the predictability of your business. In most businesses, you won’t hear about these things as much as you should; why all executives ever ask is a layer of the onion: characteristics. It’s all great until the breach or termination or release you need to withdraw. Builders build buildings that behave predictably, with thousands of years of best practice behind them. Tech teams should do the same.

Privacy and compliance

I can’t tell you how many times I’ve heard things like we innovate quickly, without compromising on safety, compliance and security. It is really difficult to put into practice. We all know that the only way to be absolutely sure that you never have an outage caused by a software distribution is to not distribute the software. Research and my personal experience show that over 65% of downtime minutes are caused by incorrect software distributions.

What happens after an interruption? Executives sow fear of consequences among engineers. But this fear can be a debilitating force in the race to digital innovation. Think of an athlete with incredible speed, holding back because he is terrified of pulling a hamstring or blowing an ACL. This is the effect that cyber attacks, privacy concerns and ever-changing regulatory standards can have on the innovation process.

Security is often seen as a counterweight to innovation. But the opposite may be true. The more secure the data platform, the more tests, the faster the cycle time between development and production. And the more confidence a team has to move quickly, identify problems early and fix them before the damage is done. To achieve this, security must be integrated, compliance testing must be mandatory, and continuous integration and delivery must be a priority.

Much of this work should be automated, because whenever I hear people are doing security and compliance testing in a company, I want to take my business somewhere else.

A Fortune 500 CTO once said that technical debt should be shown on the balance sheet so the CFO can see it. Why? Because tech debt comes with expensive interest payments and the same overwhelming impact on personal debt morale

The same could be said for all innovation taxes: short-sighted, lift-and-move strategies, organizational data silos, vendor lockdown, and a lack of rock-solid testing infrastructure.

Companies that focus on both innovation and rigor can manage these impediments in the long term. They don’t have to choose between the tortoise and the hare. They can be both.

To learn more about this topic, see The Foundations of Sustainable Speed ​​white paper.

Mark Porter is CTO of MongoDB.

Sponsored articles are content produced by a company that is paying for the post or has a business relationship with VentureBeat and are always clearly marked. The contents produced by our editorial staff are never influenced in any way by advertisers or sponsors. For more information, contact [email protected].

[ad_2]