Channels ▼

Arnon Rotem-Gal-Oz

Dr. Dobb's Bloggers

Evolving Architectures: Part VII

April 15, 2011

Parallel design and simplification are the yin and yang of architecture evolution. Simplification, as I've mentioned previously, is about having foresight, thus enabling evolution (i.e., architectural additions rather than changes). Parallel design is about reacting to changes in requirements as they come (no foresight) and making architectural changes.

Architectural changes are difficult by definition* — if we make a change to the architecture, things are going to break, starting with the build (or the continuous deployment if you have one), and will just deteriorate from there. An architectural change takes considerable time and involves risks when trying to put everything back together, which is exactly why we need parallel design.

As its name implies, this technique is about building the new via the old: routing old stuff to use in the new, and then removing the old. An analogy to help visualize this is the building of a new roadway interchange. In most cases, when a new interchange is built, the traffic isn't completely stopped. Instead, detours are used and old lanes are temporarily reassigned. Then the new lanes, bridges, etc. are built. Once complete, the traffic is routed to the new infrastructure, while the old infrastructure is renovated/removed/changed. Finally, the new interchange is complete. 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 business while you get organized to make unforeseen architectural changes.

Parallel design is essential because no matter how good our initial designs are, business requirements change and with them, the architecture that supports them. Additionally, in many cases, solving the ultimate problem from the onset isn't worthwhile; it would just cost too much (time and money) to do so. Parallel design eases the pain of making significant architectural changes. Remember, software is there to serve the business, not the other way around.

Is parallel design just a technique without architectural implications? Well, yes and no. It can be used as a general technique regardless of the architecture. However, you can design with evolution in mind. SOA, REST, and EDA (or a combination of them) are all architectural approaches that support architectural evolution. If you invest in an architectural style that makes integration easy, it helps immensely when things change. It also localizes changes within defined boundaries (e.g., within the scope of a single service) and helps in the interim stage as you keep the old integration boundaries (events, contracts, etc.) intact while adding the new ones.

For instance, in one project I worked on, we made significant changes using parallel design. The company adopted a business model that required increasing the scale of the database that the solution had to handle from hundreds to millions of items. To do this, we had to change the back-end database (from files to Cassandra), and the way we distribute the work (from centralized to distributed). The product architecture was built on event-based SOA using context-based routing**. Expanding the database was a localized change within the components that had to work while keeping the rest of the system intact. The distribution was handled in the infrastructure by changing the distribution policy of 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 of event-driven architectures, and the same goes for removing old subscribers when they are no longer needed. We did wait on deploying the interim results into production — as with the interchange analogy mentioned above, the interim product had performance problems while the work was in progress. Still, we kept everything connected and working while we gradually made a significant change.

In the real world, you probably use a mix of simplification, parallel design, and even leaps. We need to have several tools in our toolset. We can't afford to just have a hammer because, after all, not every problem is a nail.

*As I noted 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 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 third-party integration).

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video