(This is part seven of a series. You might want to check the previous parts first)
Parallel and Simplification are the yin and yang of architecture evolution. Simplification, as mentioned previously, is about having foresight and thus provides for,relatively, easy evolution (i.e. architectural additions and not changes). Parallel is about reacting to changes in requirements as they come (no foresight) and making architectural changes.
But wait, architectural changes are hard by definition* – if we make a change to the architecture a lot of things are going to break – starting with the build (or the continuous deployment if you have one) and things will just deteriorate from there. An architectural change will take, relatively, a lot of time and there are a lot of risks in trying to put everything back together. Which is exactly why we need “parallel”.
As the name implies this technique is about building the new by the old. Routing old stuff to use the new and then removing the old. An analogy to help visualize this is the building of a new interchange. In most cases, when a new interchange is built, the traffic isn’t completely stopped. Instead some detours with temporary assignment of old lanes is built. Then the new lanes, bridges etc. are built, then the traffic is detoured to the new infrastructure while the old one is also fixed/changed ans then the open the new interchange. Sure, things slow down while the work is in progress but it doesn’t stop. The same is true for businesses – nobody would be willing to halt the business while you get organized to make architectural changes that weren’t foreseen.
Parallel is needed because no matter how good our initial designs are, business requirement change and with them the architecture that needs to support them. Additionally in many cases it isn’t worthwhile solving the ultimate problem on the onset, it would just cost too much (time and money) to do so. Parallel eases the pain of making significant architectural changes. Remember software is there to serve the business not the other way around :)
Is parallel just a technique without architectural implications? Well, yes and no.For one it can be used as a general technique regardless what the architecture is. However one thing you can do is design for evolvability, SOA, REST and EDA (or a combination of them) are all architectural approaches that support evolvability. If you make the investment to build on an architectural style that is makes integration easy it helps a lot when things change. It also helps localize changes within defined boundaries (e.g. within the scope of a single service) and lastly they help in the interim stage where you have both the old and the new in place as you keep the old integration boundaries (events, contracts etc.) intact while adding the new ones.
For instance, in a project I worked on, we’ve made significant changes using Parallel. The company made a business change which had the the technical ramifications of having to increase the scale of the database the solution had to handle from hundreds to millions of items. To do that we had to change the back-end database (from files to Cassandra), the way we distribute the work (from centralized to distributed) and what not. The product architecture was built on Event based SOA using context based routing**. Changing the database for example was a localized change within the components that actually has to work with it keeping the rest of the system intact. The distribution was handled in the infrastructure by changing the distribution policy of event again without affecting the existing event stream. Adding new events and components wasn’t a problem either. routing events to new subscribers is a built in feature in event driven architectures, and the same goes for removing old subscribers when they are no longer needed.We did halt on deploying the interim results into production – apropos the interchange analogy mentioned above, the interim product had performance problems while the work was in progress but we did have everything working while we made a significant change and we were able to make it gradually while keeping everything connected and working
Lastly note that in real world scenarios you probably use a mix of simplification, parallel and yes even leaps – We need to have several tools in our tool-set. We can’t afford to just have a hammer since after all, not every problem is a nail – right?
* Architecture definition as it appears in the first post of the series :
“Software architecture is the collection of decisions affecting the system’s quality attributes; which have global effects and are hardest to change. Software architecture provides the frame within which the design (code) is built.”
** The context based routing was added as part of a previous architectural change. I mention this here as it is an example for a simplification – an architectural element that was not part of the original architecture but was added later when the actual need arrived (when we had to support both internal operations as well as 3rd party integration)“Software architecture is the collection of decisions affecting the system’s quality attributes; which have global effects and are hardest to change. Software architecture provides the frame within which the design (code) is built.”
*** illustration source newson6
