Back to Tech: Forward

The digital butterfly effect: The big impact of small decisions

Many organizations make architecture-system decisions without knowing they will create serious implementation issues. To avoid incurring tech debt, companies should follow five principles.

By Sven Blumberg, Dave Kerr, and Henning Soller

Poor system architecture is a common problem across organizations. Among senior management, it is often seen as the consequence of bad strategic decisions. Business leaders may have chosen a certain vendor for their core-platform replacement or opted for an agile setup versus a more traditional release option, and the results just didn’t turn out as expected.

The outcome of these choices is a considerable amount of tech debt—that is, organizations invest a significant amount of unplanned time and resources into implementation. IT departments, for instance, may be burdened with refactoring code that was written to expedite a process or create a shortcut. (For more on managing tech debt, see “Tech debt: Reclaiming tech equity.”)

Organizations that incur significant tech debt typically lack technical understanding and transparency due to skills gaps and opaque, outdated processes. As a result, they make decisions that can be cumbersome to reverse, such as whether to use a synchronous or asynchronous communication application for data sharing.

Companies whose leadership is conversant in technology matters and has a foundational understanding of what to look for in system-architecture builds can avoid unintentionally accruing tech debt. Furthermore, involving senior management and subject-matter experts at the outset helps address critical IT considerations up front. To make better decisions about modern architecture, organizations should observe the following five principles.

Understand technology and make better business decisions

Too often, management views IT decisions as purely technical considerations. Instead, business objectives and technology decisions should be integrated to maximize the return on potential investments.

One company, for instance, had a tech-savvy management team that knew the best way to build software was with automated security-enforcement mechanisms and application programming interfaces (APIs). Most companies opt for manual security mechanisms, however, which introduce human error and slow implementation. But because the management team understood the technical and business implications of choosing automation over manual security, the company could scale the underlying platforms and even offer them as a service to others. In addition, the senior management and tech team openly communicated about key management decisions, which helped get everyone involved on the same page.

Takeaway: Organizations must train senior management in both the concepts and technical aspects of technology. This training can take the form of bootcamps but should also encompass continuous-learning formats. This knowledge will empower leadership to better communicate technology decisions to the broader organization.

Value good architecture decision making over business-led architectural decisions

Technology decisions are often made based on presentations led by vendors and business stakeholders, for example, that speak only to the business function. Leaders will make a quick decision, overruling (or not contemplating) important architectural considerations, such as how to structure data. As a result, challenges often arise during project execution.

A bank required that technical-platform presentations be given with both business and IT personnel present; it even banned vendors that did not comply. As a result, the institution avoided pursuing three major platform implementations that would have led to significant sunk costs.

Another way to promote good decision making is to align gamification and incentive structures with the best possible decisions. Doing so can motivate developers and architects to speak up when they identify challenges or opportunities during implementation. For example, one leadership team awarded prizes to the developers who found ways to integrate systems using only API-based standards, removing the need for other patterns, a minor investment that can result in a major technology improvement.

Takeaway: IT and business functions should work together to make better decisions and collaboratively address implementation challenges. These challenges can be addressed through both a new way of working and clear governance. Organizations can also require the team that builds the system architecture to run it as well.

Invest more in hiring and training the best people

Traditionally, IT departments are steered by the estimated amount of time it will take one novice employee or a team of average workers to complete a day’s work. However, hiring expert architects and developers can boost productivity. Advanced architects can alleviate the consequences of poor strategic decisions by automating testing; implementing security by design, or DevSecOps (where security is built into a product from the beginning); and relentlessly focusing on quality. McKinsey research suggests that an expert developer is eight times as productive as a beginner. In general, focusing on hiring people with expert skills in decision making and assessing context is only possible for pure technology organizations; we therefore recommend aiming for a deliverable compromise approach, where companies find the mix of talent that works best for them, balancing cost with productivity.

A bank set up a new process focused on consistently hiring and training the best talent. It evaluated all its IT personnel and employed concepts such as the Dreyfus model, where learners acquire skills through a combination of practice and formal instruction, to support skill building.

Takeaway: Evaluate your employees, through technical tests and management evaluations, to find areas for improvement, identifying the skills they need to develop. When hiring, invest in people who have more advanced knowledge, as they will help the organization arrive faster at better solutions.

Consider automated checks over manual governance

We find that many companies avoid automated infrastructure environments in favor of manual ones. This is often due to a mistaken belief that automation can circumvent controls during deployment. In fact, manual infrastructure environments and controls often hinder risk management because they are prone to human error. Automated deployment pipelines with controls as security checks and integrated risk tests enable enhanced security and faster deployment.

Tools that control code quality can also help identify typical challenges. A developer might create continuous copies of a code or even exclude certain code standards, but the automated control, using advanced analytics, can identify those issues and make recommendations to fix them.

A bank implemented automated controls to avoid common risks such as inadvertently making data public by failing to encrypt sensitive data. These safeguards can also help teams get cloud environments up and running in a few hours and avoid delays to fix broken code or security features.

Takeaway: Create a continuous integration and deployment pipeline that includes automated controls and checks to ensure the architecture, coding, and security are correct. The automation of such controls is often directly possible within the tools or through small scripts.

Explore a two-speed delivery model over ‘headless’ agile

The general notion in business and IT is that an agile approach is best. Yet this way of thinking does not consider how components, such as a core banking system or an enterprise resource planning (ERP) system, operate within the agile landscape.

Instead of going agile, some companies might opt for a two-speed architecture model differentiating between core and auxiliary systems. Using this approach, companies can decide which processes require quick, flexible solutions (those that affect customer experience), while back-end functions (such as payments processing) can be solved via a rigid release-management process.

Open-source platform Kubernetes, for example, releases bug fixes extremely rapidly, while the platform itself has a well-defined and -planned quarterly release cycle. As a result, the company has reduced incidents or failures in production by more than 70 percent.

Takeaway: Technical-evaluation committees consisting of business and IT should discuss their options to make sure the best possible governance models are implemented based on how the platform works.

To start making better decisions along these five principles, companies must make immediate changes to how they operate, including the following:

  • alter senior management’s mindset regarding IT processes, decision making, and training
  • assess and reskill the IT workforce
  • implement a clear governance model and automate controls within the delivery pipeline

These changes can help companies function more effectively, set the course for better implementation and decision making, and avoid tech debt.

Sven Blumberg is a senior partner in McKinsey’s Istanbul office, Dave Kerr is a senior expert in the Singapore office, and Henning Soller is a partner in the Frankfurt office.