The digitization of innovation – and why it’s one of your company’s biggest risks

Written by:

Koen Hanselman

If you had asked me 25 years ago about innovation, Gyro Gearloose would have been the first thing that popped into my mind. Although that has partly to do with the fact that I was still a kid back then, times have also changed tremendously since. Innovation used to be largely about tools and products, in the non-digital sense, that is. But when it comes to innovation now, thinking of IT is inevitable. My childhood image of inventing was all about physical products, but invention nowadays likely involves developing software: from your morning news check to your on-demand entertainment in the evening, from your energy bill to your tax returns, the list is endless. Everything needs to be connected and online, and it all needs to be available 24/7.

Due to the amazingly fast developments, possibilities have become almost countless. The innovation game has changed significantly; innovation has shifted towards digital sectors. Due to the nature of digital products compared to physical products, innovation is no longer all about creating something “new,” but now often manifests itself as the evolution of an existing product. That also means that the success of your product is no longer largely determined by its launch, but, rather, relies on its continuous improvements. In this age of internet where “everything already exists,” your ability to innovate and the speed at which you can do so have become key factors in determining whether you are (and can stay) relevant in the market. In practice, this means innovation is no longer primarily determined by creativity and great ideas, but now depends much more on technical challenges. It’s likely that these dynamics are pushing your organization more and more to think about innovation and change.

How the digitization of innovation may be impacting you

Due to the widespread effects of this digitization of innovation and the stakes involved in software development for many companies nowadays, it’s highly likely that the shift affects you and your organization.

Some situations that may sound familiar:

  • Your core business is shifting towards IT (or already has)
    You didn’t (or still don’t) consider yourself an IT business, but software development has taken on an important role in your company’s daily operations. Should your software fail, you would have a serious operational problem. This requires a new mindset regarding the place and importance that software has in your organization – and many companies haven’t yet adopted this new way of thinking.
  • Your competition has become fiercer
    Time to market and the ability to respond quickly to market developments have become much more important for your company in order to retain or improve your market position. And that’s simply because the competition is moving faster as well. Pressure has grown either from the business or market to deliver features faster and has a larger impact on the way the development team operates.
  • Your technical debt is snowballing due to faster development pace and lower capacity
    Technical quality suffers due to increased pressure on the development team to deliver functionality. Maintenance has become mainly reactive instead of proactive. You may have even begun to use low-code platforms to quicken development speed and increase capacity; the increase in development speed, however, may be lower than expected.
  • Your software architecture is no longer fit for today’s requirements
    Software architecture requirements have changed due to changing usage needs and demands, continuous expansion of software and newer technologies. Today, systems must accommodate development teams working independently on various components to push partial releases. Also, connectivity and dependencies on external applications, APIs and databases have become much more common. Problem is, your current software architecture was never designed for this. Given the big risk that comes with architecture renovation, such as moving to micro services, many teams find themselves struggling with how to approach such a project.
  • You’re experiencing a more intensely changing environment for your software
    Even if your software doesn’t have a direct focus on innovation, it’s likely that it’s being affected by all the innovation around it. Software systems rarely operate independently, and a changing environment for your software means that you’ll have to sooner or later change your software as well.

If you recognize any of these scenarios, the digitization of innovation is affecting you and the way you should manage your software.

Understanding this environmental change is essential if you want to stay relevant

To stay relevant in the market and keep up with (or stay ahead of) your competition, it’s essential that you understand the new environment you’re working in. This is absolutely key. At SIG, almost all of our clients are dealing with this in one way or another. They’re either proactively changing their development processes and trying to get on top of their software quality or they already have difficulties dealing with this change and realize that their software or development processes are hindering their business agility.

If it’s not too late yet, you definitely want to be in that first category. The longer you continue in the wrong direction, the harder, costlier and riskier it becomes to change course. Eventually, you’ll get to the point that a change of direction is only possible by completely rebuilding your software. By that time, you’ve not only spent large amounts of money on maintaining software that is no longer viable, but as a result of a lack of agility, your market relevance has likely also decreased.

To sum up, understanding how crucial your software is to your business – and getting a handle on its quality – are the essential steps in controlling your business risks.

Here are five pointers to gain and stay in control of your software quality:

  1. Make quality essential in your development process
    Measuring your code quality is the essential starting point for determining risks, hotspots and improvement directions. In order to get meaningful insight, measure your code quality against a predetermined, consistent and relevant standard. Actively and regularly check your code against this quality standard and be on top of any corrections that need to be made to maintain a high level of quality. This is key to keeping costs and time-to-market low. Any time and effort invested in quality early on will show significant benefits both short and long term.
  2. Automate your development process
    This makes the execution of recurring tasks easy, time-efficient and less error-prone. It also improves the continuity and transferability of your development process. By automating your development process, you free up time to focus on innovation and other things that really add value. Aspects that you should automate are quality control, testing, integration of code changes, and your deployment.
  3. Release often
    Releasing often not only shortens the release time (and thereby increases agility), but also stimulates the development team to adhere to shorter feedback loops in other aspects of its process, e.g. testing and checking for quality adherence. Short feedback loops eliminate waste in the design, development and test phases. Furthermore, adhering to short release periods (e.g. sprints) helps to focus your development effort on the right functionalities, as it pushes teams to prioritize. Lastly, you receive quicker user feedback.
  4. Ensure, document and maintain a clear vision on your architecture
    The risk of having small releases with short development phases is losing track of the bigger picture. In addition, it’s likely that in an agile development process, various team members are working on various functionality simultaneously. It’s therefore important that the development team has a clear, shared vision on the architecture of the system. Ensure that all decisions on both the system architecture and technical design are documented, and that documentation is kept up to date. This is essential for transferability (e.g. onboarding new developers) and helps to prevent unintended deviations from the architecture. By documenting “just enough” and making sure that all written documentation has a clear goal, you prevent making documentation a heavy burden that impedes development productivity.
  5. Continually look for improvements to your development process
    The best investment you can make as a team is one which frees up additional time in return. It’s therefore important to always keep looking for process improvements. How can you increase the team and process efficiency? A good way to do this is by having a process improvement session at the end of every development phase (e.g. retrospective meetings in case of Scrum). Once you’re on top of your development process, regular process improvement sessions help you to stay there.

How many of these measures would you say you’ve got in place? Some of them? All of them? Are you fully in control of your software quality, and is your software an enabler for your organization as opposed to an impediment?

Chances are, you answered “no” to at least one of these questions. And for good reason, as transitioning IT remains an enormous challenge. But to stay relevant and competitive amid today’s digitization of innovation, organizations have no choice but to step into control of their software quality. The organizations who fail to do so will find themselves in a downward spiral of rising maintenance costs, increasing time to market and a deteriorating market position. Those who get their software right will have a solid, agile, cost-efficient and future-proof foundation for their business – allowing it to fuel their strategic objectives.

Experience Sigrid live

Request your demo of the Sigrid® | Software Assurance Platform:
  • This field is for validation purposes and should be left unchanged.