ABSTRACT
Many years ago, I visited a large aerospace company complex in the eastern United States. While there, I was introduced to their engineering processes. They had many, many manuals of processes that were color coded by functional area usage. This was their approach to functional area separation. In the software volumes, they did one thing that was an absolute revelation to me — they consciously separated “what you need to do” from “how you need to do it.” It was such a fundamental concept and yet it has not been done by many companies, even today! That inspired the idea for this process framework architecture. You need to consciously separate “what you do” from “how you do it.” The way they approached the “what” level, however, was immersed in the Department of Defense (DoD) 2167 standard of that day for terminology and document deliverables. They only addressed what you had to do at high-level 2167 phases as described in that standard. The granularity of their “whats” was at a real high level for the software engineering phase level. Their process implementation paralleled the standard for phases and expected deliverables within each phase. This means that their implementation was a document-centric view of the “what you have to do” world. Their “howto” world” was a pile of process stuff (in how-to process element number order) that was just “there.” You could not pull out a how-to process element from the pile and get an answer to the question, “Where does this fit?” I felt that this was a huge mistake. It became a requirement in
this proposed software process architecture that process elements had to fit somewhere and that one should be able to answer that “where does it fit” question. My impression was that this process mapping to the DoD 2167 standard did wonders for the government auditors and company management but did little for the people actually doing the work — the practitioners.
