Architecture Governance Lifecycle


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:


<cyclicalDependency test="true"></cyclicalDependency>

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:


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

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:

 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);

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

  1. Use an automated tool to ensure governance
  2. The tool should integrate with the Maven multi module build system
  3. Should be able to offer results as a part of the plugin.
  4. The tool should be able to break the build on a violation
  5. 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.

Advertisements

About Vikas Hazrati

Vikas is the Founding Partner @ Knoldus which is a group of software industry veterans who have joined hands to add value to the art of software development. 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). To know more, send a mail to hello@knoldus.com or visit www.knoldus.com
This entry was posted in Architecture and tagged , , . Bookmark the permalink.

2 Responses to Architecture Governance Lifecycle

  1. Paul Hickey says:

    Hi Vikas,

    Just to let your readers know, although its a commercial product, Structure101 is free for use on open source projects.

    Cheers,
    Paul

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s