Process

Tools acquire meaning in a context defined by process.

Vendors mostly want to talk about the tools they sell. And some of them will talk about the process which makes those tools meaningful. But the place we need to start is talking about the processes that we are following, or trying to implement. Once we agree on those (or at least agree that we understand them) we are in a position to talk about the various tool choices that might be meaningful in that context.

I've spent the greater part of the last twenty years in large IT organizations at large companies. So, although the views expressed here are not those of any employer past, present, or prospective; they are informed by that large-IT-shop culture. These may be different than the concerns of smaller IT organizations, or of organizations that sell technology.

The processes that are pertinent are those which involve:

• business analysis (developing business cases)
• requirements definition
• architecture and standards definition and enforcement
• software development and integration
• software testing and verification
• configuration and release management
• system administration and operation
• maintenance (upgrades, bug fixes, minor enhancements)
• helping users (help desk, trouble tickets, documentation, floor support)
• staffing (recruiting, training, developing, managing, and motivating people)

Ideally, we use software to assist with all these activities. That's the "shoemaker's children" technology. We are engaged in those activities to deliver different technology to the organization; and that requires moving through all of these activities. The processes which we have to follow to get from begninning to end can be hampered by the lack of tools which can hand off from one activity to the next in a seamless way. It is in dealing with the gaps between the tools that support these various activities that we invest most of our time and energy -- because the tools tend to focus on solving a particular problem without an awareness of the context in which they are embedded; without an awareness of the activities which precede or follow. It may be possible that these activities can be viewed in isolation -- that they need not be inter-related. But for most organizations I've been involved with, they are.

I'm not going to address these in any particular order. But I intend to talk about them all at some point. Sometimes focusing on a particular activity -- and sometimes on the interfaces between them.