In the last post, we discussed the need for architecture governance and tools which can be used for enforcing architectural governance. Let us discuss about the general Architecture governance lifecycle.
As with most of the tools mentioned in the last post, the recommended strategy to enforce governance would be followed in 3 major lifecycle steps
1. Define – The Architecture Rules. Most of the above tools provide a capability to create architectural rules as a part of an external
configuration file. At build time the code is checked against the defined rules file for validation. The definition step would also include
setting up an organizational structure who would validate and ensure manual intervention when needed.
2. Validate – This is the process of executing the rules against the code base and validating compliance. The success of the build process
would depend on the severity of the problems encountered.
3. Reporting – This step creates the documented data for dissemination and for the purpose of feedback and taking corrective action.
Example of the 3 steps with Architecture Rules tool.
Define Phase
Architecture Rules allows the definition of rules as an XML file or programmatically. XML is a preferred way because the configurations are easy
to change and do not need compilation. A typical XML file would look like this:
[sourcecode language=”xml”]
<cyclicalDependency test="true"></cyclicalDependency>
[/sourcecode]
This would ensure that cyclic dependency checks are carried out. Likewise, for ensuring that architecture is honouring the separation of concerns and the defined logical architecture:
[sourcecode language=”xml”]
<rule id="web-layer-with-wildcards">
<comment>do not mix web and dao</comment>
<packages>
< package>com.inphina.app.web</package>
< package>com.inphina.app.web..*</package>
</packages>
<violations>
<violation>com.inphina.app.dao</violation>
<violation>com.inphina.app.dao..*</violation>
</violations>
</rule>
[/sourcecode]
The above rule would ensure that if a dao is called from the web layer then a violation needs to be thrown.
Rules can also be enforced with JUnit tests. In this scenario the rules would be triggered as JUnit tests and can be executed via the IDE.
Developers and Architects would need to write unit test that extends AbstractArchitectureRulesConfigurationTest.
A sample unit test would look like this:
[sourcecode language=”java”]
final Configuration configuration = getConfiguration();
final Rule rule = new Rule("services");
rule.setComment("services may not depend on web layer.");
rule.addPackage("com.inphina.app.core.services");
rule.addViolation("com.inphina.app.web");
rule.addViolation("com.inphina.app.web.spring");
rule.addViolation("com.inphina.app.web.decorators");
configuration.addRule(rule);
configuration.setDoCyclicDependencyTest(false);
[/sourcecode]
Validate Phase
Once the rules have been defined. The validation phase would trigger in
1. Either at the time of build when the project is built with Maven / Ant or,
2. In the IDE when the checks are executed as part of JUnit tests
Reporting Phase
Architecture Rules would generate a result of compliance checks and that can be used for feedback and taking corerctive action. The generated
report is in an XML format thereby enabling versioning and easy sharing.
Recommendations
We would recommend the following characteristics for enforcing architectural governance
- Use an automated tool to ensure governance
- The tool should integrate with the Maven multi module build system
- Should be able to offer results as a part of the plugin.
- The tool should be able to break the build on a violation
- Reporting and Configuration (defining of rules) should be easy
On the basis of the above, Architecture Rules in the Open Source space and Structure 101 in the commercial space are good alternatives.
Thus with any product you would like to introduce these lifecycle steps to carry out the governance. Of course the first two steps to define and validate would form the crux for your governance process.