-- JaiminPatel - 25 Aug 2009

Automated Governance

This section will attempt to outline governance checks that can be automated using common industry solutions. The basis of the governance check will be an attempt to enforce design and architectural policies and best practices as development organizations are building, updating and submitting assets through the software development lifecycle.

Requirements Phase

The Requirements phase is the first phase where design time governance (policy management) can provide value. An automated check should be done within requirements systems or plain word documents for basic compliance, consistency, ensure proper internal standards are being applied. Many companies start requirements review cycles with large groups of people getting together most often as the review cycle is going on it is discovered that the requirements document is incomplete and missing key required sections. This discovery causes a stoppage in the review process until the author completes the document. These start and stops of reviews within the SDLC cause delays and waste great deal of time. With an automated review model all review documents are checked to ensure compliance and then a review cycle is started.

IDE Governance (Eclipse)

As developers are building assets within an IDE the developer should be able to initiate a check of the source code in an effort to assess the compliance level of the asset against corporate policies and best practices. The checks that should be done within an IDE environment include the following; programming styles, code structures that could negatively impact Performance, Security, Maintainability and many other characteristics.

Source Code Control Systems

Within the source code management system automated governance provides all the same level of compliance checks that were done in the Eclipse environment but this time the enforcement can be stronger. For example in the Eclipse environment development organizations may allow code warnings in the source code control system the policy is that all checked in code must be completely clear of any policy violation otherwise the user is not allowed to submit the code into the system. This is valuable for development projects that could be cross organizational and the convergence point is the source code control system for example the COBOL developers may not be using an eclipse but their code needs to be checked just like the others so having an enforcement point at this level create a uniform compliance model.

Build Systems

The final automated governance check can be initiated within the build system phase of the SDLC. The governance compliance levels at this stage is the same as the other but the impact of the violations can be stronger. In this phase an automated check is done of the full build package for compliance and if there is any artifact that is noncompliant the build process can be stopped.

It is important to highlight that the action to stop a build process is completely up to the customers. There should be options within any automated process for to continue the build process or to stop the process.

Asset Management Systems

The Deployment phase is where automated governance interacts with the asset systems to ensure compliance of artifacts. Compliance checking for all assets in the system as they are published and transitioned from one state to another. The value that automated governance provides in this phase is based on the fact that compliance checks can be made on metadata and content within the asset. Any automated governance system should be able to place scoring values back into the asset systems so when developers want to reuse an asset they can see the detail compliance report as well as how good of an asset it is based on the compliance analysis.

This is critical if the objective within the organization is to increase the quality of asset and reuse.

Publish

In the publish phase the automated governance process is initiated in an effort to ensure that all the required information for all artifacts are provided by the developer.

As described in the scenario section the asset information (and metadata) that needs to be provided by the developers include, but not limited to, items such as:

• name
• version (asset version, not workproduct version)
• asset type (describing the asset's expected content, constraints, lifecycle, relationships, categorization)
• description
• relationships/dependencies to other assets
• workproducts, contained directly, or referenced
• published location (server, community)

The automated governance process can check not only the content of the artifact but can also ensure that the metadata is in line with standards and policies defined by the architects. (This was added to the Scenario: Developer Publishes Service Specification)

Search

In the search phase the automated governance process should provide valuable compliance information about the assets being search for. When a developer is searching for assets in the assets system it should provide compliance information that will help him/her make the appropriate decision on how to use the assets in the application that he/she is building. The compliance information should include a detail view of the compliance check and any associated metadata about the compliance level of the asset.

Retrieve