| "Documentation is an inherent part of the design | | | | Today, documentation of any kind is considered a |
| process." - Bryce's Law | | | | taboo (particularly among the Agile Methodology |
| INTRODUCTION | | | | people). Small wonder the IT Industry is experiencing |
| I recently overheard a Business Analyst say there | | | | the same type of problems today that we |
| was more to systems architecture than drawing | | | | experienced 35 years ago in terms of managing |
| boxes and arrows on a piece of paper. This may be | | | | design complexity. |
| true to a degree, but the ultimate deliverable of any | | | | BLUEPRINTING |
| engineering/architectural practice is a set of drawings | | | | It is a myth that one type of diagramming technique |
| from which to build a product. Architects and engineers | | | | can be used for all development work. This would be |
| do not spend all of their time drawing diagrams; for | | | | like suggesting to use a wiring diagram to represent a |
| example, they have to specify requirements and | | | | floor plan. Different needs, different graphics, different |
| analyze such things as the stress of components to | | | | purposes. There are actually four types of graphics to |
| determine the suitability of materials for use in design. | | | | be used to the different levels of system design. This |
| But aside from this, the end result of engineering or | | | | implies a blueprinting approach with various levels of |
| architecture, their deliverable, is a set of drawings, be it | | | | abstraction, from general to specific. As we have |
| a blueprint, a floor plan, wiring diagram, plumbing, or a | | | | discussed in the past, the "PRIDE"-Information Systems |
| set of flowcharts. | | | | Engineering Methodology (ISEM) looks at a system as |
| Such drawings basically consist of boxes and arrows. | | | | a product that can be engineered and manufactured |
| Boxes (be it squares, rectangles, polygons, circles, etc.) | | | | like any other product and, as such, defines four levels |
| represent tangible objects and lines represent | | | | of detail in a system's hierarchy: |
| relationships between such objects. Flowcharts are | | | | LEVEL 1 SYSTEM |
| similar; here, boxes represent specific types of | | | | LEVEL 2 SUB-SYSTEMS (Business Processes) |
| processes or decisions or objects such as inputs | | | | LEVEL 3 PROCEDURES (Administrative and |
| outputs/files, and lines represent dependencies | | | | Computer) |
| between them (comes from/goes to). | | | | LEVEL 4 PROGRAMS (for Computer Procedures) |
| Although drawings typically consist of geometric | | | | OPERATIONS (for Administrative Procedures) |
| shapes, it is not uncommon to include tables or indices | | | | Four different levels, four different graphics used: |
| to represent decisions or to provide a cross-reference. | | | | LEVEL 1 SYSTEM CONCEPT DIAGRAM - |
| Nonetheless, boxes and lines represent the principal | | | | represents a freeform architectural rendering of the |
| means to visualize and communicate a design | | | | overall system. |
| regardless of the structure to be built, and have been | | | | LEVEL 2 SYSTEM FLOWCHART - defines the |
| used since time immemorial. | | | | SUB-SYSTEMS of the System. |
| In addition to diagramming techniques, engineers and | | | | LEVEL 3 SUB-SYSTEM FLOWCHART - defines the |
| architects have found it useful to develop models and | | | | PROCEDURES in a Sub-System (aka "Process |
| prototypes to evaluate the overall physical aspects of | | | | Diagram"). |
| their design. These are useful but let us not forget they | | | | LEVEL 4 |
| are all ultimately based on a design of some kind | | | | COMPUTER PROCEDURE FLOWCHART - defines |
| (boxes and lines). From the models and prototypes, | | | | the PROGRAMS in a Computer Procedure. |
| designs can be adjusted as required. | | | | Each level provides the specifications for the next (this |
| I guess what I'm driving at is that despite all of this | | | | is also known as "stepwise refinement"). With the |
| peripheral activity, and to refute my Business Analyst | | | | exception of the System Concept Diagram, all of the |
| friend, the principal thrust of the engineer or architect is | | | | flowcharts make use of ANSI standard symbols. As |
| to produce and maintain a reliable set of drawings. It all | | | | to the internal processing logic of a program, since |
| comes down to boxes and lines. Interestingly, today's | | | | there are many ways to skin a cat, the software |
| analysts and programmers think drawings are "old-hat" | | | | structure diagram du jour is used, hopefully a standard |
| or passé. I don't care whether you draw it with | | | | one. However, a graphic may not be necessary to |
| pencil and paper or by computer, documentation is an | | | | express the processing logic of a program. Instead, |
| inherent part of the design process. Failure to | | | | specifications may be interpreted by a program |
| recognize this is to deny reality. | | | | generator of some kind. Its a "fielder's choice." |
| In terms of the Information Systems industry, | | | | CONCLUSION |
| flowcharts have been used for years, well before the | | | | Until such time as we can master the Vulcan "mind |
| introduction of the commercial computer in business. | | | | meld," whereby we can transfer knowledge |
| Originally they included process diagrams; later they | | | | telepathically, there will always be a need for |
| were used by programmers as a convenient means | | | | documentation. Its an inherent part of the design |
| to document program logic. Such flowcharts typically | | | | process and the principal deliverable produced by |
| made use of ANSI standard flowcharting symbols. But | | | | engineers and architects. Don't deny it, accept it. |
| as the Structured Programming movement flourished | | | | I am definitely not one for excessive documentation |
| in the late 1970's, ANSI symbols were considered | | | | thereby becoming a burdensome task. Instead, |
| archaic, and many new types of diagramming | | | | documentation should be a natural byproduct of the |
| techniques emerged, including Bubble Diagrams, Data | | | | design process. Just as blueprinting is an inherent part |
| Structure Diagrams, E/R Diagrams, HIPO, VTOC, etc. | | | | of the design process to architects and engineers, so |
| (anybody remember Nassi-Schneiderman Charts?). I | | | | should flowcharting be to system developers. And you |
| could argue the pros and cons of the various | | | | shouldn't have to be a rocket scientist to draw a |
| techniques but that is not the point. What is important is | | | | flowchart, keep it simple and try to use standard |
| that all of these diagramming techniques | | | | techniques for consistency instead of reinventing |
| acknowledged documentation as an inherent part of | | | | graphics every five minutes. As for me, I have no |
| the design process. | | | | problem with ANSI standards; it works. |