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:

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:

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 testsReporting 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.

Like this:

Vikas is the CEO and Co-Founder of Knoldus Inc. Knoldus does niche Reactive and Big Data product development on Scala, Spark, and Functional Java. Knoldus has a strong focus on software craftsmanship which ensures high-quality software development. It partners with the best in the industry like Lightbend (Scala Ecosystem), Databricks (Spark Ecosystem), Confluent (Kafka) and Datastax (Cassandra).
Vikas has been working in the cutting edge tech industry for 20+ years. He was an ardent fan of Java with multiple high load enterprise systems to boast of till he met Scala. His current passions include utilizing the power of Scala, Akka and Play to make Reactive and Big Data systems for niche startups and enterprises who would like to change the way software is developed.
To know more, send a mail to hello@knoldus.com or visit www.knoldus.com