Diagrams for System Evolution

every system has an architecture (whether deliberately designed or not) and most systems change and evolve during their existence - which includes their architecture. sometimes this happens gradually and sometimes in large jumps. let's have a look at a simple example.

basic context diagram for a furniture company

the main elements are:

• sales orderbook where sales staff book orders and designers occasionally view sales.
• product catalogue where designers record the details of new products.
• warehouse management application that takes orders and either delivers to customers from stock or forward orders to manufacturing.

the data flow is generally one way, with each system pushing out data with little feedback, due to an old batch-style architecture. for example, the designer updates product information but all the updates for the day are pushed downstream at end-of-day. the warehouse application only accepts a feed from the sales orderbook, which includes both orders and product details.

there are multiple issues with a system like this:

1. modification to the products (new colours, sizes, materials etc) are not delivered to the manufacturer until after an order is placed. this means a long lead time for manufacturing and an unhappy customer.
2. the sales orderbook receives a subset of the product information when updated. this means the information could become out-of-sync and not all of it is available.
3. the warehouse system also relies on the sales orderbook for product information. this may be out of date or inaccurate.
4. the designer does not have easy-to-access information about how product changes affect sales.

the users are unhappy with the system and want the processes to change as follows:

1. the product designer wishes to see historic order information alongside the products in the catalog. therefore the catalog should be able to retrieve data from the sales orderbook when required.
2. don't batch push products to the orderbook and warehouse management. they should access the product catalog as a service when required.

system redesign

therefore the system is re-architected as follows:

this is a significant modification to how the systems works:

• the sales orderbook and product catalogue have a bi-directional relationship and request information from each other.
• only orders are sent from the sales orderbook to the product catalogue.
• there is now a direct connection between the warehouse manager and the product catalogue.
• the product catalogue now provides all features the designer requires. they do not need to access any other interfaces into the system.

however, if you place the two diagrams next to each other they look similar and the scale of the change is not obvious.

when we write code, we would use a ‘diff’ tool to show us the modifications.

i often do something similar on my architecture diagrams. for example:

system before modification

system after modification

when placed side-by-side the differences are much more obvious:

i’ve used similar colours to those used by popular diff tools; with red for a removed relationship and green for a new relationship (i would use the same colours if components were added or removed). i’ve used blue to indicate where a relationship has changed significantly. note that i’ve included a key on these diagrams.

you may be thinking; why have i coloured before and after diagrams rather than having a single, coloured diagram? a single diagram can work if you are only adding and removing elements but if they are being modified it becomes very cluttered. as an example, consider the relationship between the sales orderbook and the product catalogue. would the description on a combined diagram be "product updates", "exchange sales and product information", or both? how would i show which was before and after? lastly, what would i do with the arrow on the connection? colourise it differently from the line?

conclusion

i find that having separate, colored diagrams for the current and desired system architectures allows the changes to be seen much more clearly. having spoken to several software architects, it appears that many use similar techniques, however there appears to be no standard way to do this. therefore we should make sure that we follow standard advice such as using keys and labelling all elements and connections.