10 things CIOs must absolutely know about their software

With the right kind of software intelligence, CIOs can keep risk low while modernizing systems for future success.

Binary stream passing over rows of monitors, each also displaying binary streams.
Loops7 / Getty Images
Current Job Listings

Software is becoming more and more complex, and as a result, it’s become increasingly difficult to have a true, real-time grasp of what’s actually in software portfolios. From undocumented features, to unknown security vulnerabilities to code libraries used, CIOs and their teams are making big decisions in the dark every day. And, unintentionally of course, this lack of informed decision making puts the organization at great risk.

As software complexity and the sheer amount of code continue to increase, this risk will only grow. To put things in perspective, the average car today (excluding self-driving cars), has more than 150 million lines of code. This is more lines of code than a F-35 fighter or a Boeing 787.

A recent expose in The Atlantic pinpoints exactly why CIOs need to think about software differently:

“Car parts were once purely mechanical. They now, as often as not, come with millions of lines of code. And while some of this code—for adaptive cruise control, for auto braking and lane assist—has indeed made cars safer, it has also created a level of complexity that is entirely new. And it has made possible a new kind of failure.”

As CIOs, we must get our arms around this complexity. Not only to improve application security and cost efficiency, but to ensure the basic supportability and stability of the systems that could put our lives at risk, like in medical systems or cars, self-driving or not.

The good news is that we now have improved tools that give us a much deeper insight into what’s actually inside software to identify strengths, weaknesses and opportunities for improvement. This new Software intelligence is equipping CIOs to be more proactive in managing software complexity and protecting business operations.

In your search for software intelligence, here are the top 10 characteristics I believe CIOs must absolutely know about their software:

10. Source code inventory

First things first! Get a complete inventory of all source code with proper version control in secure and backed up repositories. Often, we have not done our homework in this area. Understanding the code base and assessing software quality is essential to simplify complexity and establish a baseline for modernization, maintenance and transformation efforts.

Maintaining a current software repository not only helps teams manage binaries, simplify cross-platform functionality, build tools and deliver packaging formats – it also enables the CIO to run real-time analytics on software health and performance for more effective reporting and faster incident response rates.

By beginning with a baseline of what you have within your portfolio, you will be able to gain the more relevant intelligence around what your applications are doing, any redundancies and how they all fit together.

9. Architecture compliance

Architectural compliance is a very telling measure of an organization’s ability to enforce security, reduce risk and keep efficiency high.

Blueprinting application architecture accelerates learning for new developers and helps architects understand the structure of applications so they can work faster and make changes with less re-work. It also speeds modernization because component interdependencies are already established, and high areas of potential risk can be flagged before the work is begun.

In my own experience, assessing architectural compliance has been incredibly useful to understand complexity, technical debt and where more effort should be focused. It also helps inform an IT Risk Score that aligns architectural compliance with the overall safety and soundness of systems.

Key aspects of the architecture that I personally like to check for system stability and performance include exception handling, data access performance and data management, input validation, secure architecture design compliance (especially avoiding the use of hard-coded credentials) and compliance with initial architecture design.

8. Data privacy and compliance risk exposure

CIOs must also be able to look for and identify specific characteristics of software in a timely manner to respond to precise requirements, like certifying against GDPR compliance, for example. After a data breach or incident, CIOs are often called upon to report on system security and reliability.

The rise in regulations and stricter rules around data privacy, are also forcing the CIO to report on issues like how they’re protecting customers’ social security numbers, or even hard coded IP addresses. Such requests generate a significant amount of discovery, research and effort.

Having access to methods and tools that help you answer such questions quickly, comprehensively and with certainty will make a big difference in CIO perception and long-term success.

7. Open source and IP license risk

Although it was once predicted that the rise of open source software (OSS) could help improve software security and overall quality, that has not become our reality (at least not in 2019). The use of OSS components has spread like wildfire, and with good reason. It helps teams get projects off the ground faster, save money and leverage a technology that’s been validated by others.

For example, “the explosion of data and the need to effectively use it has been a major factor driving the increased adoption of open source across the public sector,” says Shaun Bierweiler of Hortonworks.

But OSS can also expose an organization to unnecessary and unpredicted risk. Recent data shows that open source breaches are up by 70%. Many open source components can be poor quality with multiple holes for hackers to exploit, and once a hacker has found a way into part of OSS, they're then able to hack every IT systems who uses that component.

To prevent this, CIOs must know the components and artifacts within their software, whether they are still supported and the licensing liabilities they carry with them. Open source and license risk must be handled more proactively than what we’ve historically been able to do, or we risk becoming the next Equifax.

6. Technical debt

Technical debt can be a significant impediment to system maintainability. Year after year, release after release, new features after new feature, it’s easy for technical debt to grow overnight if you’re not careful.

Often calculated as 100% High-Severity Violations + 50% Medium-Severity Violations x Need to Fix Violations x Cost of Development, expressing technical debt priorities to senior-level management can oftentimes help CIOs secure more budget for maintenance and modernization activities. In fact, I would argue that using technical debt to help allocate budget for maintenance activities is an essential step to ensure activities are focused on the right things to improve overall software quality.

As Myles F. Suer wrote in his Adaptive CIO column, “reducing technical debt needs increasing focus. It isn't wasting money. It’s about replacing brittle, monolithic systems with more secure, fluid, customizable systems. CIOs stress there is ROI in less maintenance labor, fewer incursions, and easier change.”

5. Application portfolio rationalization

Tools exist today to analyze transaction patterns and compare them across multiple code sets providing the CIOs with the data they need to rationalize their application portfolios more effectively. Retiring applications is always a challenge and such tools now give us the data we need to assess and prioritize our effort and ensure that we can truly retire an entire application and move safely the associated business transactions to a more appropriate set of systems.

The value? Reducing costs, obviously, but more importantly reducing overall risks from an operational perspective, with less incidents and less surface area to attack. Today, most of the analysis used to make rationalization decisions is based on features we think are used, leaving gaps in the decision-making process. With modern tools, we can see actual transaction patterns to identify the code with highest usage, code that needs to be modernized, and even wasted code that can be retired for more efficient and secure applications.

4. System-level analytics

Most CIOs continue to lack visibility into their overall system architecture, interdependencies and how software quality issues impact the broader system, beyond just individual applications and components. Traditional code scanning tools don’t provide a system-level view, and therefore generate mounds of false positives and findings that aren’t always useful at the CIO level.

Gaining an understanding of software health across the entire system gives CIOs a much more accurate picture of software quality and flaws that impact security and performance. System-level analysis enables the CIO to set fact-based expectations for business counterparts and give more practical direction to developers on where to focus their effort and how to plan integrated tests across data flows with upstream and downstream systems.

How many times do CIOs not test the impact of an upstream application thinking it won’t be impacted? System-level analysis takes the guesswork out of this and helps teams avoid such embarrassing situations.

Many system-level solutions now on the market have also added visualization aspects to pinpoint unexpected dependencies, compliance gaps and architectural vulnerabilities quickly and with clear direction for speedy remediation.

3. Cloud readiness of applications

Public cloud spending is expected to reach $200 billion this year, so it’s no surprise that cloud migration is becoming a bigger priority for CIOs. But knowing cloud is a priority and understanding which applications should be migrated to the cloud are two different matters entirely.

This requires application portfolio rationalization – determining the inner structure of applications – to model and predict how each app will perform and function in a cloud environment before it’s re-platformed. The rationalization effort should consider things like business impact, security, quality and technical debt as priority.

To further refine these measures, stepping through the 5 R’s of cloud rationalization and identifying primary outcomes for each R is an essential step to success in the cloud. These are:

  1. Rehost - typically chosen to reduce cost and secure quick wins.
  2. Refactor - typically chosen to foster faster delivery cycles and greater efficiency.
  3. Rearchitect - typically chosen when existing apps are not compatible with cloud platforms.
  4. Rebuild - typically chosen when existing apps cannot support business demand and faster innovation is required.
  5. Replace - typically chosen when apps are outdated or are scheduled to be retired.

2. Prevalence and criticality of application security vulnerabilities

Latest research shows that security is the number one priority for CIOs in 2019. Security issues keep CEOs up at night, and the responsibility to protect mission-critical systems often falls on the CIO, even if a CISO is present within the organization.

To protect the business, CIOs should direct efforts towards reducing vulnerabilities and the potential surface area of attack. This means reducing technical debt, rationalizing application portfolios and prioritizing security violations with tools that offer SAST, DAST, IAST and more frequently, Software Composition Analysis (SCA). In a blog late last year, Forrester analyst Amy DeMartine reported that rushed features often result in sloppy security.

One major challenge to focusing security effort is sorting through the sheer number of violations these tools often flag. It’s difficult to focus a team’s effort on fixing critical issues when they are being bombarded by hundreds of new notifications every day. To prevent this, CIOs should look for tools that offer system-level analysis – meaning a comprehensive, architectural view of violations based on component interdependencies. These are the issues that have the biggest impact on company and data security if exploited.

1.  A standards-based view of software health

With the ever-increasing complexity of systems, CIOs must monitor their overall software health and be armed with real-time data about potential risks and hot spots. Taking a portfolio-level view of software health will help CIOs better understand if their organization is ready to start a digital modernization project, if there are baseline quality issues or if there are security holes in their applications, etc.

Basing this portfolio-level analysis on industry standards, such as CISQ, CWE, NIST, OWASP, PCI, STIG and others will help foster more productive conversations with business and developer teams based on facts related to software manageability, performance and security, and will help modernization efforts get off the ground more rapidly.

In my own experience, using software health metrics to prioritize investments and resources also helps reduce conflict and align cross-functional teams for faster delivery with higher quality that produces more productive business outcomes in the near-term. These factors are all essential to the success of the CIO.

To succeed in the digital future, CIOs must make the intangible features and functions of software and make them visible to the naked, untrained eye. With these 10 characteristics, CIOs can make more productive, well-informed decisions about their technology while bringing teams and senior leadership along the right path.

This article is published as part of the IDG Contributor Network. Want to Join?

Copyright © 2019 IDG Communications, Inc.

How do you compare to your peers? Find out in our 2019 State of the CIO report