The idea is that you create independent building blocks for of your automated works and have them conform to a common layout of the API which means that it is easy to join to blocks together due to the well defined API. A typical example which goes hand in hand with what I have written here before is one tool to add test data to the system, one tool that performs actions on the system and one tool that validates performed actions. On these three tools you build a new block which use the test data tool to load data, use the action tool to perform actions and the validation tool to validate the actions. That tool is very similar to full scale test automation tool. If also have a software provisioning tool, you add that block also.
There are two major advantages with this method. One is that when the product changes you only need to change one tool rather than in many parts of one monolith. The second is that is can still benefit from the tool even if you do not use the full scale automation. The first part one could argue that it is just good design practice to develop tools that way, and to that I agree, but that are two nuances to this. One is that all test automation tools that I have worked with have never been designed in this way in a truly decoupled way, and the other is that this LEGO idea also means that you can let different groups be responsible for the different tools. For instance can the developers be responsible for the action tool since when they change the interface they also update the action tool to fit the new interface. Which means loads when it comes to keeping the test automation up to date, one of the major arguments against test automation. With this method you can also reuse parts much better between products and organizations because the differences can be contained in some parts locally and the common parts handled in some common function.
It also makes future development of the tools easier since one can easily replace a old tool with a new one or update tools with a greater flexibility.
