5 ways to achieve business outcomes instead of building software systems

Creating a better business outcome should always be our top priority, but how do you get there? Here are five recommendations...

Stamp with five stars showing excellence

You could have heard a pin drop in the room. We were debating the target architecture of a large program. Someone in the room had said: “We created a target architecture four years ago, which we all believed in, and I guess we are half-way through implementing it. So, why is this not helping us achieve the outcomes we are chasing now? It’s because everything is morphing – the business, the situation, the customer, the outcomes, etc. We should stop guessing the future.”

Creating a better business outcome should always be our top priority, but how do you get there?  Here are my top five recommendations:

1. Stop trying to implement a system – it distracts us from our original goal

Most IT discussions at an enterprise level focus on what kind of system or architecture is required to achieve the business goals. The dialog then quickly moves to “what software should one use?”, or “how fast can the target architecture be implemented?”, or even, “what is the right mix between commercial and custom-built software?”. We are being distracted by shiny new technology and solutions.  

The discussion never focuses on the business outcomes the company was trying to achieve in the first place. Why is this such a hard discussion to have? Probably because it is easier to talk about how to design a system than to chase the elusive business outcome. Business outcomes are a moving target as the needs and demographics of the customer are continuously morphing. Designing a system is an in-house discussion that can be had without even stepping out of the office.

Therein lies the conundrum: How does one develop software for a goal that is changing constantly? Some successful endeavors in the financial and retail industry over the last 12 months show promise, but the patterns that are emerging are quite the contrary.

2. Invest in winning teams, not in promising projects

Winning teams who chase moving targets and achieve continuous business outcomes do not plan large programs. A partnership with a new startup, a deal struck between two companies, an idea for a campaign in Denmark – this is what success looks like. The teams need the ability to design software for this new way of working, even though it goes against the grain of everything that software engineers have been taught.

3. Move away from projects & programs to a continuous state-of-achieving

Winning teams constantly spawn ideas and go from one victory to another. A smart enterprise should fund such ideas and track the path to victory. This turns program and portfolio management on its head. Suddenly it is much more about investing in ideas that work, rather than guessing what projects one should sponsor. Patterns from the venture capital industry are already demonstrating how to implement this way of funding and releasing capital.

For example, a large retailer in Europe has moved to this new way of working – and continuously implemented micro-solutions in the market. Thirty teams worked in parallel to produce a stream of business outcomes – the first of which was visible within four months of the start date. Each micro-solution was funded in stages after it demonstrated that it could move the business KPI needle. With this, the teams were forced to go beyond going live with a system to actually demonstrating a success in the market. Eighteen months later, the initiative shows a string of successes to justify its spend.

4. Enterprise architecture is an exercise in constant learning

Over time, enterprise architects have been trying to capture the essence of an organization into neat boxes called “capabilities", and have designed and mapped these capabilities into software. This ignores the fact that we are creating architecture for a moving target and are using solutions that have not yet taken the latest technology platforms into consideration. In the light of such technology changes, can people expect to capture everything they need over the next five years in a target architecture?

Instead, we should focus on how the constant stream of solutions that create business outcomes evolve within a constantly changing architecture. Enterprise architecture would then be about the art of building the architecture as it evolves, rather than guessing what is needed.

5. Focus on delivering benefits, instead of a system or scope

Good software is a process, not a deliverable. We should not allow technology and process to distract us, nor allow decades of software architecture experience to blind us to the more agile way of achieving business outcomes. Instead, learn how to find and enable winning teams with full-stack responsibility without needing to change the organizational structure. We should learn to live with solution redundancy that comes as an unavoidable cost while chasing multiple business outcomes simultaneously. As software engineers, we need to focus our architectural talents and on dealing with an evolving solution architecture built on technology that has been shaped by business decisions.

Simply put, stop looking for systems to implement.

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

NEW! Download the Winter 2018 digital edition of CIO magazine