By Ursula Huber on October 24 2018 15:41:20
In addition to diagramming techniques, engineers and architects have found it useful to develop models and prototypes to evaluate the overall physical aspects of their design. These are useful but let us not forget they are all ultimately based on a design of some kind (boxes and lines). From the models and prototypes, designs can be adjusted as required.
I recently overheard a Business Analyst say there was more to systems architecture than drawing boxes and arrows on a piece of paper. This may be true to a degree, but the ultimate deliverable of any engineering/architectural practice is a set of drawings from which to build a product. Architects and engineers do not spend all of their time drawing diagrams; for example, they have to specify requirements and analyze such things as the stress of components to determine the suitability of materials for use in design. But aside from this, the end result of engineering or architecture, their deliverable, is a set of drawings, be it a blueprint, a floor plan, wiring diagram, plumbing, or a set of flowcharts.
Such drawings basically consist of boxes and arrows. Boxes (be it squares, rectangles, polygons, circles, etc.) represent tangible objects and lines represent relationships between such objects. Flowcharts are similar; here, boxes represent specific types of processes or decisions or objects such as inputs/outputs/files, and lines represent dependencies between them (comes from/goes to).
Helping an organization map out processes can be a challenging task unless you know how to create sample flowcharts. When attempting to get subject matter experts to redefine their business processes, it is imperative to help them identify gaps or redundancies in their current as-is process.
I guess what I`m driving at is that despite all of this peripheral activity, and to refute my Business Analyst friend, the principal thrust of the engineer or architect is to produce and maintain a reliable set of drawings. It all comes down to boxes and lines. Interestingly, today`s analysts and programmers think drawings are "old-hat" or passé. I don`t care whether you draw it with pencil and paper or by computer, documentation is an inherent part of the design process. Failure to recognize this is to deny reality.
Flowcharts can be quickly created in many computer software programs; even recent versions of Microsoft Word and PowerPoint contain Smart Shapes that allow users to rapidly insert a flowchart into a document of presentation. Specialist Flowchart Diagramming software also exists but for sheer versatility and the ability to connect data to shapes I would put my money on Microsoft Visio. It has a huge range of ready-made stencils containing all the shapes you could possibly need (and the ability to create your own if you wish), and very slick automatic connection features. Visio also allow a flowchart that dexcribes one process to become part of a larger process and to integrate with it via a hyperlink from a button on the drawing page.