CM: THE NEXT GENERATION of ALM Transparency

Interface
architecture allows growth without incurring additional learning curve or administration, in most cases, apart from understanding the business processes.

Third generation systems will be well-positioned to address executive use of the ALM tools.  But addressing the above problems is not a sufficient condition.

Process Model

Once the basic components are in place, we need to address the process thoroughly.  There are a number of process tools out there, but they really must be well integrated into the CM/ALM toolset to provide adequate control.  Some components that need to be managed include:

• Object State Flow
• Inter-object Work Flow
• Access Permissions

Essentially, it must be possible to address a set of requirements that identify how data moves through the system, how it interacts with other parts of the system, and who has permissions to trigger/execute various parts of the process and change the related data.

Object State Flow is a key component of an process model that can be easily expanded.  The central data object is identified and then the states of the object, and the transitions between states. This determines how a customer request is handled, or how a build is tracked through to production and delivery.

Inter-object work flow deals with rules for and triggers of actions on related objects based on the state of one object.  This is usually managed using specifically designed rules and triggers against the transitions of an object state flow.  It is also dealt with through user interface actions which trigger object actions across multiple objects.  Implicit in Inter-object work flow is the data that provides full traceability between objects.  It is not sufficient to have actions interwork. Nor is it sufficient to provide an audit trail of
what actions were performed.  The resulting data links which provide traceability are crucial to the reporting function, and this will be the key to executive buy-in to using the tool.

Access Permissions are handled in many ways.  The simplest and most common way is through providing role-based user interfaces.  The users can only do what the tool allows them to do.  Even if the user interfaces aren't foolproof (e.g. a Command Line Interface can be used to circumvent the restrictions), they provide a key component of process work flow by guiding users of each role through their tasks. To tighten access further, a lower layer of data access permissions must provide assurance that only those specifically authorized have the appropriate access to the data.  This includes capabilities to meet
ITAR regulations which require data to be physically and/or logically separated into access partitions so that only those authorized to access the data can see and/or change it.  CM vendors are stepping up to meet ITAR requirement if for no other reason than they want to sell to the U.S. government.

When these capabilities are present, it's possible to tune the solution to the corporate requirements.  This gives executives control because they can mandate, in a more cost-effective and timely manner, what their own requirements are.

Executive Buy-in: Reporting

All of these are capabilities are great for control and for usue by the development team but will only go so far toward getting senior management useful tools for themselves..  They need the appropriate level of reporting to go with them.  The reporting is not only for
senior management, but for the whole team to be able to function more productively and coherently.  Reporting must be able to cover these areas:

• Process - Process reporting must answer the questions:  What is the process? What "to-do lists" do I have?
• Data - From Dashboards, to drill-down summaries, to overview and to detailed levels, daa must be presented in a useful manner.
• Tools - Do I know what tools are being used in my business and is it possible to track the revisions of these?
• Metrics - Metrics identify key measures of how