6.2. Creating New Processes
Specifically, the detailed process for creating processes is defined as follows:
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.
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 occurred which could have been prevented if a process was 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 which are vague, open-ended, and do not satisfy or exceed the criteria listed above 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, etc. Over time, processes will need to be created to improve software quality, including a code review process, defect tracking process, etc. Again, it may not be the role of the architect to define and execute all of these processes; however, he does have the responsibility of ensuring they are in place and sufficient for the project needs. Without these processes, it will be extremely difficult for the 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, it allows process participants to provide critical feedback either into how the process can be improved or on other issues which also need to be addressed to effectively accomplish the process goals.
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. It is the time-consuming process execution which frequently overwhelms novice architects and impedes their effectiveness in controlling the architectural consistency throughout a project.