#158 removed empty line, reference to resources

articles/aprg.md

@@ -25,7 +25,7 @@ Such a model comprises at least the following:
 - quality attribute requirements specifying the qualities required from the resulting system
 - architectural decisions as a record of options available and explicit decisions needed to fulfil the given requirements
 
-In the following we consider mainly the system and application architectures. An extension of the approach to requirements and decisions requires further research beyond that which we have implemented so far[Structurizr.InfrastructureAsCode].
+In the following we consider mainly the system and application architectures. An extension of the approach to requirements and decisions requires further research beyond that which we have implemented so far (see resources: [Structurizr.InfrastructureAsCode]).
 
 ## Architectural erosion and the model-code gap
 Architectural erosion is the divergence of the architecture model from the source code and infrastructure that actually implements the model. It results in a model-code gap and usually happens gradually during the iterative and incremental development and maintenance of a system. The code and infrastructure evolves, but the architecture model is not kept in sync. After a while, we end up with a model that describes the system as it was meant to be in the beginning but not as it is actually implemented and delivered. 
@@ -45,7 +45,6 @@ Instead of modelling the architecture in a diagram, we may use code like the fol
 
 Now, when this gets executed, the corresponding infrastructure and connectors are created and the system is ready to be used according to its description in the code.
 
-
 Note that the implementation is based on Structurizr, an executable ADL which also allows architectural diagrams to be generated. Therefore, we may additionally generate up-to-date views of our current models, as needed, in the system's Architecture Guidebook, for instance.
 
 In case we need to evolve or refactor the architecture, we work directly with the code. Only by this means are we able to modify the actual system and hence the model is always in sync with the code and infrastructure. Of course we could also change the system directly, but this is similar to changing code in a running system without updating the underlying source code in the repository, an anti-pattern which is hopefully nowadays no longer practised anywhere. 
@@ -56,7 +55,6 @@ Finally, code can be executed and tested. If architectural requirements are impl
 
 The idea of Architecture as Code provides a required abstraction to Infrastructure as Code. With tools like Structurizr and its extension we move further towards executable ADLs which not only describe but actually *implement* the architecture of a system.
 
-
 *By {{page.authorName}}*
 
 {% include "./aprg.resources.md" %}