There is a plethora of configuration management (CM) and application lifecycle management (ALM) tools out there, most of which I would classify as second generation, or 2G, tools. A precious few are 3G tools, while there are a number of 1G tools, and one that I would classify as 4G.

Given all of these tools contain CM capabilities, what's the biggest factor that makes one tool stand out from another? Well, there are a lot of candidates: Level of administration, reliability and availability, multiple site global CM capabilities, and end-to-end integration. However, I believe the biggest factor is the area of customization, configuration, and tailoring.

Terminology
Before we proceed, let me clarify some definitions. The defence industry and other sectors reserve the word "customization" for work done under a software development contract—that is, lots of programming is involved. The words configuration and tailoring are used for the run-time or end-user "customization," which doesn't involve programming, though it often involves scripting.

I have a bit of a problem, not with the definitions, per se, but with the ideas they conjure up in my mind. Configuring or tailoring is typically thought of as making minor "customizations" not requiring development. Generally, you might allow some tailoring to refine process and data schema in order to add some menu items or to pre-can some reports.

You wouldn't use the term “tailor” to create a new dashboard or a new, integrated time-tracking application, or even to generate some special purpose traceability navigation tools. And that's where the problem is: Mention these items and "development" comes to mind, but that's the 2G way of thinking about things.

On top of that, you must deal with the in-between factors: Setting up a custom web interface for accessing your ALM data, creating build automation scripts, generating dialog panels, and writing rules and triggers. These generally take a fair bit of scripting and perhaps integration with additional tools.

But with a 4G tool, these more complex-sounding tasks can be done more simply, without programming or extensive scripting. Creating a dashboard is a customization effort when using a 2G tool. When using a 4G tool, it's simply a configuration effort. While both tools may end up with similar results, it’s probable that the results would be better in the 4G tool.

In this article, "customization" refers to any configuration, tailoring, or customization of a solution. In this way, the terminology is not solution-specific.

Why Do We Customize?
Take any two organizations in the world of SCM and ALM and look at their CM and related processes; it is likely they will be quite different. There are a number of reasons for this, ranging from corporate culture to industry regulations, to maturity and expertise levels. Technology solutions need to support an organization's process, and they need to do so in an efficient and productive manner.

This means a good deal of customization will be necessary. Starting from a mature solution can usually minimize the customization effort. But beware—some solutions are so tightly "scripted" that any change is complex and risky.

In our own shop, here at Neuma, we customize for a variety of reasons:

1. To simplify ease of use for each role

2. To reflect our evolving process

3. To automate our processes

4. To capture data more accurately and easily

5. To present information in more appropriate formats

6. To simplify data navigation and traceability

7. To add data needed to improve our quality and processes

8. To extend or expand our solution to cover additional functions

9. To create rules and triggers that customize our work flow

10. To cater to personal preferences

Generations Apart
Ever try to create a dashboard using Subversion? What about extending your existing solution to do time sheet management and roll ups for project costs? Would you run meetings directly from your CM/ALM solution? Would you have to swap out CM tools if your projects moved from traditional to agile methods?

The fact is that different generations of CM tools address predefined expectations. And because you are probably more familiar with one generation of tool than another, it's worth noting a brief overview of how far apart customization capabilities are in various tool generations.

A 1G tool deals only with source code control and build support. Customizing it to support project management is not an option. Trying to create fancy user interfaces is not an option. There may be some very basic trigger capability to help customize to your process needs, but for the most part, you use the tool's basic components and script around it to provide a higher level of functionality.

In a 2G solution, you have the ability to integrate point solutions to form a wider ALM solution. The user interface can be customized by changing forms and views, customizing reports, and adding menu items. These are not trivial tasks. If you want to add a slick dashboard to show project status, you're probably talking about a reasonably significant development effort. Creating rules and triggers can be script intensive, but can help to integrate the point solutions.

Move to a 3G solution and you might start taking a few things for granted. A single repository platform means rules and triggers are much simpler to implement. Perhaps there are a few common, precanned triggers that only need on/off configuration. You might consider adding a new function to support customer site tracking or lab equipment assignment, and these might each take a few days to implement within your solution framework. You may be able to customize existing dashboards or perhaps even create a few new ones, as the needs arise, in a matter of hours. You can adjust your data schema to better reflect your traceability requirements, without having to create new forms or query and reporting scripts to take advantage of the changes. You'll focus, not on what menus or commands should be visible, but rather on what "to-do" lists and pre-canned custom reports are presented to each role when the tool application starts up.

With a 4G solution, you may begin to move a lot of customization over to the end-users so that they can rapidly and easily tailor their own presentations. Dashboards are no longer just drill-down summaries that present information, but are context-sensitive so that you can narrow, expand, or adjust the dashboard view. You can use the dashboard to drive meetings or to focus on specific tasks such as peer reviews or backlog prioritizing. And these dashboards are generated in minutes rather than days. You can do more customization because it’s easy and you want a custom fit.

Extending the scope of your solution can be done in hours, eliminating the need to shop for and integrate additional tools into your solution. Your corporate culture is no longer "Can we get the tool to do this in the next release," but instead a more agile "Let's sit down and adjust my view of the tool in real time to handle my requirements" kind of mantra. Automation moves from primarily an implementation of some requirements to primarily a specification of the requirements. Data fill is higher quality with fewer keystrokes and clicks because of "semantic pick-up" or context-aware tool behavior. You teach your tool the CM strategy so that it proactively prompts its users rather than teaching the users the strategy and implementing rules and triggers that ensure they abide by this strategy.

OK. We've moved rapidly through an overview of four generations of CM/ALM customization technology. If you're using a 1G solution, it may be hard to contemplate the 3G and 4G scenarios. But likewise, if you're using a 3G or 4G solution, you might find it hard to understand how it could make sense to use a 1G or 2G solution.

Perspective
Let's go through this overview from a different perspective: What are your customization goals in each generation?

1G:  You're trying to get the tools to work consistently with no gotchas, while keeping the command interface simple.

2G:  You're trying to make all functionality available without having to memorize commands. You're trying to piece together a set of tools into a solution. You're trying to automate and, where possible, simplify operation to minimize human error and improve data quality.

3G:  You want to use your ALM tool as a communication center for all roles across the product team. You focus on ease of use, on a role-by-role basis. You're making the tool conform to your process rather than vice versa. You're looking to have information and actions front and center, with role-appropriate to-do lists, single-click reports, point-and-click rapid traceability navigation, and active workspace trees that compare your CM context view to your workspace and show you the details on the tree view without you having to ask.

4G:  You focus on task-based and role-based dashboards that encompass areas of information and action specific to tasks and roles you need to support. You want to run all meetings from the tool with in-meeting capture of decisions and actions. You look to extend communication beyond your product team to customers, suppliers, and corporate executives. As such, you want to ensure that your tool requires no training—or perhaps just some process training and a 10,000-foot capability overview. You seek to replace all administration training with a few comprehensive admin dashboards. You want the tool to understand your process and to take advantage of this understanding.

So with each generation of solution, your goals are different. Of course, there are not solid lines between generations, but on the other hand, sometimes it's very hard to get your middle managers, or even your CM team, to think beyond their current constraints.

Examples
I'm not going to go through an exhaustive list of examples, and I'm not going to look at 1G or 2G examples. Instead, I’m going to highlight a few examples that are easy to get your head around.

The first example is that of creating a meeting dashboard for running a Problem Review Board (PRB) meeting. The dashboard we've created in this example has just a few widgets: Attendees, Summary, Agenda, and Problem Flow. But at the same time, it's easy to zoom in to any item on the dashboard or to pull up a menu to perform an action on one of the problems on the agenda, as shown in figure 1. So even with just a few widgets, we have a comprehensive set of information and actions at our fingertips.

In this example, you mark the attendees and then check off the agenda items as you move through them. The Problem State/Transition Flow is shown and color-coded to the state of the agenda items. In fact, it's interactive, so that the flow can be corrected, if necessary, by the PRB, perhaps to introduce a new state or to allow a new transition or two. So what sort of configuration or customization code is needed to produce this custom meeting dashboard (at least, in this 4G tool)? Well here it is:

meetingdashboard ?'Problem Review Board Meeting' 

  '?/users attribs with PRB/5(name)##[*]Attendees'

  ?,/reverse (probs stream @cur stream status < answer sort priority)/90(priority status)||[* *]Agenda_Summary

  '?/reverse (probs stream @cur stream status < answer sort priority)/24(status stream priority title)##[**]Agenda'

  ?,/#probs/70(:16 status:20)!Problem_Flow

As you can see, it's fairly straightforward, though perhaps a little bit cryptic if you don't know the scripting language—one line per widget. Better yet, this script can be generated from a dialog panel for those who don't like scripting.

The bottom line is, you can now run your meeting right from the CM/ALM tool. No need to print out or email reports. You don't even have to be in the same room as long as you've all got access to the same dashboard.

The next example, a tad more complex, is a task-based "work station" for software peer reviews. The requirements: We want an easy to view code difference or delta capability and options to enable more or less context, change match criteria, etc. Perhaps it could address some of the more difficult aspects like finding the Update/Change Package that needs to be reviewed and capturing review comments against the Update. This might define a fairly good "Peer Review Station."

The top row of widgets sets the context: Which product, development stream, and user are we looking at.

The next line allows selection of an Update (i.e., Change Package), defaulting to the user's latest update.

Then a file selection and a couple of reporting options followed by the actual delta report.

Then a review area, where review comments can be entered and saved with the Save Review button.

Below that would be a description of the Update, and that's followed by a list of problems or features addressed by the Update with full zoom-in capability for more details.

The scripting for such a Peer Code Review Station:

dashboard   ?/products/Product  ?,<Stream>Stream   ?,/users/User

  ?/changes ?User product ?Product stream ?Stream status <= ready/(status title)Update

  ?/mods ?Update/(..title)File   ?,4[@setcount 'mods ?Update']File_Count   ?,4[1]Context   ?,4[3]Match

  ?<>15x160![> delta ?File -match ?Match -context ?Context oldnew  -dir ?^deltaworkarea ?Update]Delta

  ?<>4x120[?Update-Review.txt]Review

  ?<>4x120[>get -term ?Update -field notes]Notes

  ?/problems ?Update/2(status title)##Problems  ?,/activities ?Update/2(status title)##Activities 

  ?'Update Review Station'[<SaveReview>savereview ?Update ?Review] ?'*'[<refresh>*]

Again, the scripting is very straightforward. I've highlighted the prompt widget names for those who want to follow more closely. And again, generation of this scripting can be assisted through a dialog panel if desired.

The essential point here is that this customization indicates what goes on the dashboard in a very high-level scripting language specification; I like to refer to it as an next generation language (NGL). There is no need for layout tools or programming; just specify what widgets there are, what order they appear in, and what goes into each widget. It helps that this GUI generation language is integrated with the repository and with the macro and command language of the CM/ALM tool.

There are all sorts of areas to customize: tool bars, instant reports, quick links, to-do lists, guidance, and so forth. Now imagine if a single line or two of scripting were all that was necessary to create each instant report, each navigation tree, or each to-do-list top-level item. That's why customization is big—really big. It really makes sense when you consider the fact that each shop does CM differently.

So What?
OK. Great. We have a couple of dashboard examples and a main screen layout. So what?

Think for a minute about the various roles in your CM and product team. What if you could go to a representative of each role and ask: What dashboards could you use to make your life easier, by putting all the information you need in one place, along with all the actions you need to perform? What if you could sit down with them and ask for feedback while they tell you what they want? For a start, you'd have a lot of happy users. Productivity would increase. Cost of tool customization would almost disappear.
 

Trackback(0)

TrackBack URI for this entry

Comments (2)

Subscribe to this comment's feed

Joe Farah said:

... Hans, thanks for your comment and I must agree that this is a challenge. First of all let me say that the easiest road to standardization is to develop a set of role-based dashboards (including those for status, meetings, and tasks) that are pertinent and easy to use. Ease-of-use is a great force in standardization. As well, a good ALM tool should allow you to have some level of flexibility while still keeping the standard components. So it may be fine to let project manager Smith customize his session and dashboards, but maybe we want to force him/her to keep certain dashboards and report tabs a single click away. This helps to expose the standard boards, without reducing flexibility otherwise. In general, standardization need to be done at the Enterprise, Methodology, Project, Role and User levels. A tool like CM+ (shown in the examples) allows you to implement a layered approach so that some standardization can be achieved without inhibiting flexibility within the standards. So let's start from the top down with customizations (i.e. Enterprise, Methodology, ...) rather than from the bottom up. Nevertheless, this is a real challenge that is not being addressed properly because of the limited exposure of experts and CM managers to 4G tools. Joe

report abuse vote down vote up

December 22, 2011
Votes: +0

Hans said:

	... I like the clear description and this is the way forward, but how do you standardize this flexibility in the organization? When every project defines their own approach and these project starts to collaborate, all kind of 'customizations' must be changed, with conversion of the presentation, etc. I think that is the greatest challenge of 4G.
	report abuse vote down vote up

December 21, 2011
Votes: +1

Write comment