7.2 Creating New Processes

Specifically, the detailed process for creating processes is defined as follows:

Define the goals of the process explicitly. There should never be any doubt about what a particular process is expected to accomplish.
Explain the current organizational context, which illustrates why a process is needed. This explanation provides a basis for later discussing whether the process is still needed when an organization changes.
List a brief outline of the process, which covers the process steps and how the process progresses. Each step in the process should have a concrete completion point. Even ongoing tasks should have some well-defined completion point, for example, a single cycle. The steps of the process should provide measurable progress toward the completion of a process deliverable.
Make sure that the process deliverables and timetable are explicitly stated. Ideally, the specifications for the deliverables include how the product is to be formatted as well as the information it contains.

Next, it is important to know when it is necessary to define a new process. There are two key indicators: (1) a major disruption or problem occurrs that could have been prevented if a process had been in place, or (2) an opportunity exists for improved outcomes if a process is put in place. So either a new process prevents or eliminates bad outcomes, or it creates desirable outcomes or improves existing outcomes.

Finally, maintain a high standard for how a process is defined. Processes that are vague and open-ended and do not satisfy or exceed the preceding criteria for a process will create a false sense of security in an organization and will ultimately waste valuable time and resources, as critical process elements are endlessly debated and redefined.

In a brand-new software development effort, an architect should ensure that processes exist for at least the standard stages of the software development process (i.e., requirements, design, configuration management, testing). Over time, processes will need to be created to improve software quality, including a code review process and a defect tracking process. Again, it may not be the role of software architects to define and execute all these processes; however, they do have the responsibility of ensuring that these processes are in place and sufficient for the project needs. Without these processes, it will be extremely difficult for any architect to have a direct input on how the software architecture is realized in the designs and actual implementation.

For development environments where existing processes are in place, new processes are developed to solve particular recurring problems. It is critical that the existing context, which determines the need for the process as well as the process details, is communicated to those affected by the process. In addition to developing buy-in, the new processes allow process participants to provide critical feedback either into how the process can be improved or on other issues that also need to be addressed to accomplish the process goals effectively.

A common mistake of a novice software architect is to assume responsibility for tracking too many of the various processes required for the project to be successful. While there are times when a software architect needs to assume some process execution duties, a more effective approach is to delegate the majority of such responsibilities to the project manager or other members of the development team. The architect's responsibility is to ensure that the processes are being tracked and that the software artifacts (design models, documentation, code, etc.) are in accordance with the guidelines and heuristics dictated by the software architecture. Properly done, documenting how to make architectural tradeoffs and verifying that the artifacts are in compliance will dominate the bulk of the software architect's schedule. The time-consuming process execution frequently overwhelms novice architects and impedes their effectiveness in controlling the architectural consistency throughout a project.