This pattern is part of “Patterns of Legacy Displacement”
Create Town Plan
Identify stable parts of the organisation to structure teams and software around
This page is a stub. We intend to fully expand it in later revisions of this material. However we are still in the middle of developing these patterns, so it's likely that patterns will be renamed, split, or merged as we continue to learn how best to frame and explain these ideas.
We are often involved with the development and maintenance of a software system for many years and then when faced with the task of displacing the system it can be difficult to chunk up to see the wood for the trees. What are the big chunks of business functionality that the system delivers?
We have found that a really useful way to identify the big chunks of business functionality is to think in terms of the different capabilities the software participates in providing to the ongoing function of the business. For reference we will take this as our working definition:
A Business Capability is the collection of people, processes and tools that describe a stable boundary within a business.
Usually the existing legacy system will have a mixture of different capabilities depending on the system itself. For example, a core banking platform may have payment processing, the general ledger and settlements, customer accounts etc contained within the existing system. These capabilities become key seams that we can target as we look to incrementally deplace the legacy safely.
Once these have been identified, the next step, or so you might think, would be to go into more detail on each of them but therein lies the trap. One classic failure mode of legacy displacement activities is to spend ages trying to understand in excrutiating detail what we are going to build. It's a classic form of analysis paralysis and one which arguably gave SOA a terrible name. “We'll just go off for two years and design all the services that you'll need to displace the system. Then we'll build them.”. We hope we've learnt better than that by this point!
So what do we do instead? The authors like the metaphore of town planning1 to describe the level of detail we should be striving for before getting going.
1: The authors must credit Erik Doernenburg with the Town Planning metaphore. James first heard Erik use it at the end of the naughties and it became a key plank on which the idea of microservices was based. Chapeau Erik!