We have struggled a bit to define precisely what DTGov is and what we want it to be.  Currently the project allows users to create instances of custom BPMN2 workflows whenever an artifact in the S-RAMP repository is added or changed in some definable way.  The only vertical solution atop this concept currently supported out of the box is Deployment Lifecycle Management.

This approach is fine, as far as it goes.  However, it's not clear that there is a tremendous amount of value provided by the lifecycle management workflow, given other systems designed specifically for this space.

Going forward, we are considering how DTGov might be broadened and focused at the same time.  HA!  What do I mean by that?  Well, we would like DTGov to be more broad in the sense that it can "consume" events from more systems than simply S-RAMP.  So we would like to be able to listen for changes in other systems like bug tracking systems, source code versioning systems, etc.  On the other hand, we are considering constraining DTGov's functional responsibility to focus on the definition and evaluation of design time policies.  So rather than simply triggering an arbitrary workflow whenever something changes, instead we want to have a formal definition of a Design Time Policy.  The UI can then be focused on how to define these policies and then monitor how they are evaluated and applied.

Hopefully the following information will make this more clear.  Any thoughts/feedback always encouraged and welcome!

Terms & Definitions

• Policy Definition: the data model used to define a design time governance policy.  The definition must include information about the following concepts:
• Policy Information Point (PIP): a configured design time governance event source.  Examples include S-RAMP, git, JIRA, etc.  These are read-only sources of governance information.
• Policy Decision Point (PDP): some piece of logic that determines whether the policy has been violated.  Information from the PIP(s), along with other external sources, are used to make this determination.
• Policy Enforcement Point (PEP): a configured endpoint that can be used to affect some sort of governance change.  For example, cancelling a git Pull Request would be considered a policy enforcement point.
• Policy Notification Channels: configured notification channels - sends policy violation information to users.  Examples include twitter, email, SMS, etc.
• Policy Actions: set of asynchronous actions to take when a policy is violated.
• Policy Waivers: a role could be provided allowing someone a chance to waive the policy for this particular instance/violation.

Concepts

• Define governance event sources (JIRA, git, S-RAMP, etc) as the Policy Information Points.
• Actions can be any sort of asynchronous thing - workflow, script, etc…
• Notifications is a top level concept, along with Actions.
• Correlation - we need a way to correlate individual policy violations together into sensible groups (e.g. the “Project” concept already suggested).  This way users can see a stream of related policy violations.
• Wiring together disparate endpoints is easy enough.  But the gap that DTGov fills is the context and interactions useful for Governance

Tooling

• UI overlay on top of the endpoints to create Policy Definitions.
  • Select one or more PIP, with a “selector” of some kind
  • How to use multiple related PIPs?  CEP of some kind?
  • Define a set of Policy Notifications
    • Support for multiple notification channels (email, SMS, twitter)
    • Template based?  How to handle different channel limitations/formats?
  • Define a set of Actions
    • What information is available to be passed to the action(s)?
    • Actions must be async - this is currently handled poorly in DTGov 1.0.
• The UI should be able to display a stream of governance activity with various filters, including at least “project” and “type”.
• Admin user responsible for defining/designing the policies
  • All aspects of each policy definition should be configurable via the UI (see Concepts above)
  • Policies are named for easy consumption in projects (by non-admin users)
• Business users will create Projects, define roles, choose/configure policies which should be evaluated for a project
• Nested projects - allow projects to be nested, allowing this simple concept to model more complicated project configurations.

Technologies

• Camel: Message transformation and routing framework with a large variety of endpoint components (http://camel.apache.org/components.html).
  • Event consumers
  • Notification producers
  • “Action” producers
  • Existing components to use:
    • Amazon-*
    • Dropbox
    • File
    • FTP, FTPS, SFTP
    • GMail
    • SMTP
    • IRC
    • Twitter
  • New components to be created and contributed back to Camel:
    • GitHub
    • JIRA