Stop implementing software systems, chase business outcomes instead
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 had a target architecture four years ago — which we all believed in. And I guess we are half-way through implementing it. 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….”
We are distracted by new technology and solutions.
Stop trying to implement a system — it is distracting us from our original goal
Most IT discussions at enterprise level focus on what kind of system or architecture is required to achieve all the business goals that they have set out for themselves. The dialog then quickly moves to what software one should use, or how fast the target architecture can be implemented, or even what the right mix between commercial and custom built software should be.
One never gets to discussing what 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 — moving constantly because the needs and demographics of the customer is continuously morphing. Designing a system is an in-house discussion — a discussion that is easier to have — without stepping out of the office.
Therein lies the conundrum: How does one develop software for a goal that is changing constantly?
Some successful endeavours in the financial and retail industry over the last 12 months show promise — but the patterns that emerge are quite contrarian.
Invest in winning teams, not in promising projects
Winning teams who chase constantly 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 continuously achieving success looks like. Except that designing software for this new way of working goes against the grain of everything that we have been taught till date on what good software engineering should look like.
Move away from projects & programs to a continuous-state-of-achieving
Such winning teams constantly spawn ideas and go from one victory to another. A smart enterprise should fund such ideas and track each idea’s 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 guess upfront what projects one should sponsor. There are multiple patterns from the venture capital industry that one can learn from to implement this way of funding and releasing capital.
A large retailer in Europe has moved to this new way of working — and continuously implemented micro solutions in the market. Each “micro-solution” gets funded in stages after it demonstrates that it can move the needle on a business KPI. With this, the team is forced to go beyond just going live successfully with a system to actually demonstrating a success in the market.
Enterprise Architecture is an exercise in constant learning
Well meaning enterprise architects have been trying, over years, to capture the essence of an organisation into neat boxes called capabilities, and designed and mapped these capabilities to software. But this is ignores the fact that we are creating an architecture for a moving target, and using solutions that have not yet taken the latest technology platforms into consideration. Five years ago, one would know about containerisation only if one were a Google employee. In the light of such technology changes, can one really hope to capture all that one needs 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 morphing architecture. And enterprise architecture is then about the art of building this architecture as it evolves, rather than guessing what one would need.
Focus on delivering benefits, instead of a system or scope
Good software is a process, not a deliverable. Let us 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.
Let us instead learn how to find and enable winning teams with full-stack responsibility without needing to change the organisation structure. Let us learn to live with the redundancy in solutions that comes as an unavoidable cost while chasing three simultaneous business outcomes. Let us focus our architectural talents instead on learning to deal with an evolving solution architecture built on technology that has been shaped by business decisions.
And above all, let us stop looking for systems to implement.
