I just read a white paper about an agile approach to a legacy system (prompted by StranglerApplication by Martin Fowler). The team developed an application that started by delivering a small bit of needed functionality to address a problem with a legacy system. They integrated at the database level. This small offshoot from the legacy application then grew and grew. The success stems from not trying to re-write the existing system, but to implement business value specified by real users. The legacy system was always left running, but people just stopped using it as a compelling alternative was available.
Semco have no policies. This means that every team are open to do their job however they want. As long as the goals are achieved, who cares how you got there. By allowing variation in the approach taken, people are open to try things and see if they work. This reminds me of how evolution works. Mutate the best known solutions and see if they perform any better than their parents.
Why can't architecture be like this? We have several teams at work all blocked waiting for the ultimate 'architecture' to be put in place to allow us to develop. What is the worst thing that could happen if each team developed their application differently? They may have incompatible architectures! So? as long as they integrate with each other, and present themselves to the customer with a very similar interface, who cares if they are different?
I believe that through inter-team communication you would find that teams would start to cross pollinate ideas and so end up with much better solutions that any would have come up with alone. It would definitely allow us to start development, and not sit around wondering if the current proposition is the best solution.
No comments:
Post a Comment