Evolving Software Like an Orchardist

Software systems are usually larger, overgrown structures that developers need to bring back into shape after some time. However, creating an overview of the sprawling conglomerate of software components is challenging, let alone developing a clear plan for moving on. This blog post uses analogies from pruning apple trees to show developers how to evolve their software systems using a value-based approach.apple trees 1Everyone is happy if one has a fruitful apple tree in the garden. The blossoms in spring are a feast for the eyes, and the apples you’ve harvested yourself in late summer taste the best!

apple trees2But after some years, when the apple tree gets older, it also gets weaker. The apples don’t shine in red anymore. Some of them are still green or already moldy. It seems that the apple tree is ill somehow.
bare treeThe reason is usually that the tree is simply too overgrown. Many water shoots weaken the vitality of the tree, the strength goes into the leaves, and there is nothing left anymore for the apples.
bare tree 2But the solution is clear: the apple tree must become more vital again! There are many ways you can do this, from removing the water shoots to cutting off entire branches or replanting the whole apple tree. You can also do crazy things, like leaving some bigger branches to attach a swing to it. It all depends on the individual needs one has!
bare tree 3Sure, a pruned apple tree looks a bit horrible at first when you see it after the pruning. But it positively affects it, allowing it to recover and build strength for the spring.
apples againYou will be rewarded with a rich harvest in the summer and again enjoy a vital apple tree with delicious apples!
question markNow at the very latest, you’re asking yourself: What the fiddlestick does this have to do with software systems?
sad treeWe can compare a software system with an apple tree (yes, it was predictable that this blog post would take this direction, but bear with me, it’s about to get more interesting!)
many componentsA software system consists of many components, often tens or even hundreds of tiny little parts at specific places within a system (or a system of systems).
tree-like structureThose components are, of course, somehow interconnected and form a tree-like structure if you look at a system from a certain point of view.
complex(OK, I know, I know. In reality, this tree looks a little bit more complex, so let’s say there are many more connections between those components. Are you happy now? Yes? OK, then we can move on.)
upside downTo make it even better, we, as software developers, like to have a different/special/nerdy view on trees. We like our trees upside down (for whatever reason). So let’s rotate that tree (for god’s sake. But it’s also better for me to get my points across later.)
needsOf course, the elephant in the room is: What are the connections between the components? It could be anything like data flow, protocols, team dependencies and many more! But let’s keep it simple. Imagine you have a user of your system at the top. She needs something to be accomplished. The components below fulfill those needs but also have needs. The components below fulfill those needs but also have needs. The components … I think it’s clear what I want to say: We build a chain of needs from top to bottom.
valueThis view on our software system also gives us an additional hint regarding a component’s perceived value. Because the user at the top sees (more or less) the components at the top (e.g., by interacting with them directly like an app), she understands that those components deliver the things she wants to accomplish. Thus those components are especially valuable to her.
tree of componentsWith this approach, we get our tree of components similar to an apple tree! Similarly, we can discuss possible actions about how we want to evolve our software system. There are plenty of those actions we can think about (look at the end of this blog post for more information).
 software systemBut there is more: we can also see where it is easy to get our software system back in shape. Especially the components that a user can directly recognize are the ones that you can easily get started with. If there are problems in or with those components, business people will give us a lot of money to fix them. But it’s unfortunate when a component far from the user’s perception is problematic. A user (or product manager) cannot see this component directly. Therefore, it is unclear why to invest money here.
awareness zoneBut with our tree, we have a good chance of convincing the business even for those components. We connect the lower components with more visible components of the top by showing the advantageous features of the lower components and how they relate to the upper. By jumping over unnecessary components, we get those lower components in the “awareness zone” of users and product managers because those changes suddenly add value for them too!
PathIf we have found an interesting part of our software system (aka path(s) with components) to evolve, we can think about possible next steps and create and discuss that on a separate plan. This dedicated branch focuses on a specific situation with relevant users, their individual needs, and components that fulfill those needs.
add the stepsSubsequently, we add the next steps that show which components we want to evolve to the plan. This gives us a roadmap-like picture that we can use to communicate our small plan for the value-based evolution of our software system to business people.
evolutionAfter we’ve finished several modernization plans like this, we get a nicely reshaped software system that can thrive, grow, …
new fruits… and provide many new fruits because of our work!

More Information

BTW, actually, I’ve just introduced you to the essence of Wardley Mapping. Here you can find my TOP 5 recommendations that show how to start with this fascinating technique.

Assessing Legacy ERP Systems With Wardley Maps

Let's talk about today's Swiss army knife software systems called "Enterprise Resource Planning Systems" (ERP systems). These are really powerful tools, no question, but in some situations, they can cause more harm than good — especially when they are really old and called "legacy systems." So, I want to tell a fictive story that shows how an organization can get deep into trouble. For this, I’ll try to use Nick Tune’s brand new Core Domain Patterns and Wardley Mapping (if you aren't familar with Wardley Maps, I recommend watching the YouTube video "Investing in innovation").

For understanding the context around ERP systems better, we first take a brief look at the role of IT systems in the past decades: