Architecture Consistency Maintenance

Pattern Attributes

Intervention Architecture
Domain any
Work Programme WP2
Research Area Architecture
Evidence Type Case study, Small-scale experimental study
Evidence Source IBM, 6 post-grads/professional software developers
Evidence Strength Anecdotal
Trigger lifecycle_phase > 2


This pattern addresses the situation where an organization wants to maintain consistency between a system’s source code (its “as-implemented” architecture) and its as-designed architecture. It is widely reported that the as-implemented architecture of a software system drifts with respect to its as-designed architecture over time. If this consistency is not preserved, the non-functional attributes that the architect was originally trying to instill through the as-designed architecture may not be realized in the as-implemented architecture.


Real world time pressures can result in programmers diverging from the as-designed architecture. Likewise programmers’ lack of knowledge of the as-designed architecture may also cause divergence. Additionally, programmers may have additional insights, based on implementing the system that the original architect may not have considered and so they (the programmers) may proactively chose to deviate from the as-designed architecture to improve the system. In this latter case, the problem is that the architect is not aware of the newly introduced divergence.


The approach/solution is best illustrated by the demo of the JITTAC tool that has been generated as part of this research work. The demonstration is available as a video-clip. Specifically this pattern is addressed by starting from 2 minutes 47 seconds into the video clip, but it is probably useful to view the whole video clip for context. Specifically the solution is for:

  1. The architect to create an explicit representation of the architecture
  2. The architect to map the source code entities onto the nodes of that architecture
  3. The architect to address the inconsistencies that become apparent between the code (the as-implemented architecture) and the as-designed architecture (as per the Architecture Establishment pattern)
  4. The programmers, when coding on the system would then be alerted through margin warnings or intellisence/auto-complete as to their introducing inconsistencies between the as-designed architecture and the as-implemented architecture (in real time)
  5. If they persist with the introduction of inconsistencies (assuming a valid rationale) they will be prompted to declare that inconsistency through an email facility to the system architect.

Impact Metrics

The case study was qualitative, consisting of quotations from architects and observations of them using our tool/approach. The experimental study used metrics like ‘time to remove inconsistency’ during a small software-evolution task,

Document Templates

Architecture Establishment: A pre-requisite pattern


  1. Rosik, J., LeGear, A, Buckley, J. Babar, M.A., Connolly, D., (2011) Assessing Architectural Drift in Commercial Software Development: a case study. SPE 41(1): 63-86.
  2. Rosik J., Buckley J., and Babar M.A, (2009) “Design Requirements for an Architecture Consistency Tool” Proceedings of the 21st Working Conference of the Psychology of Programmers’ Interest Group, pp. 109-124.
  3. Buckley J., Mooney S., Rosik J., and Ali N.. (2013) “JITTAC: A Just-In-Time Tool for Architectural Consistency” Proceedings of ICSE, pp 1291-1294
  4. Ali N., Rosik J., and Buckley J.. (2012) “Characterizing Real-Time Reflexion-based Architecture Recovery in Practice” Quality of Software Architecture, pp 61-70