(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 architectural 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, many things will 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 a lot of time, and there are a lot of risks in trying to put everything back together. Which is precisely why we need “parallel.”
What is parallel?
As the name implies, this technique is about building the new with the old. Routing the existing stuff to use the latest 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 are built. Then the new lanes, bridges, etc. are made, the traffic is detoured to the new infrastructure while the old one is also fixed/changed, and then the new interchange is opened. 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 requirements change, so the architecture that needs to support the new requirements must also evolve. In many cases, it isn’t worthwhile solving the ultimate problem at the onset; it would just cost too much (time and money) to do so. Parallel eases the pain of making significant architectural changes when the time is right rather than over-engineering when other concerns are more important.
Is parallel just a technique without architectural implications? Well, yes and no. For one, it can be used as a general technique regardless of what the architecture is. However, you can make changes easier by designing for evolvability; SOA, REST, and EDA (or a combination) are all architectural approaches supporting evolvability. Investing in building on architectural styles that make integration easy helps a lot when things change. Services and modules also help localize changes within defined boundaries (e.g., within the scope of a single service). 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, we’ve made significant changes using Parallel on a project I worked on. The company made a business change, which had the technical ramifications of having to increase the scale of the database the solution had to handle from hundreds of items to millions. To support these changes, we had to change the back-end database from files to Cassandra; change how we distribute the work from centralized to distributed, and many other changes. Luckily, 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 had to work with it – and we were able to isolate that from the rest of the system. The distribution was handled in the infrastructure by changing the distribution policy of the events, 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 deploying the interim results into production – apropos the interchange analogy mentioned above, the product had some performance degradation 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 even leaps – We need several tools in our tool-set. We can’t afford just to 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 of 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.”
