April 2, 2007

"BOXES AND LINES"

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 lines. 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).

Although drawings typically consist of geometric shapes, it is not uncommon to include tables or indices to represent decisions or to provide a cross-reference. Nonetheless, boxes and lines represent the principal means to visualize and communicate a design regardless of the structure to be built, and have been used since time immemorial.

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 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.

In terms of the Information Systems industry, flowcharts have been used for years, well before the introduction of the commercial computer in business. Originally they included process diagrams; later they were used by programmers as a convenient means to document program logic. Such flowcharts typically made use of ANSI standard flowcharting symbols. But as the Structured Programming movement flourished in the late 1970's, ANSI symbols were considered archaic, and many new types of diagramming techniques emerged, including Bubble Diagrams, Data Structure Diagrams, E/R Diagrams, HIPO, VTOC, etc. (anybody remember Nassi-Schneiderman Charts?). I could argue the pros and cons of the various techniques but that is not the point. What is important is that all of these diagramming techniques acknowledged documentation as an inherent part of the design process.

Today, documentation of any kind is considered a taboo (particularly among the Agile Methodology people). Small wonder the IT Industry is experiencing the same type of problems today that we experienced 35 years ago in terms of managing design complexity.

BLUEPRINTING

It is a myth that one type of diagramming technique can be used for all development work. This would be like suggesting to use a wiring diagram to represent a floor plan. Different needs, different graphics, different purposes. There are actually four types of graphics to be used to the different levels of system design. This implies a blueprinting approach with various levels of abstraction, from general to specific. As we have discussed in the past, the "PRIDE"-Information Systems Engineering Methodology (ISEM) looks at a system as a product that can be engineered and manufactured like any other product and, as such, defines four levels of detail in a system's hierarchy:

LEVEL 1
SYSTEM

LEVEL 2
SUB-SYSTEMS (Business Processes)

LEVEL 3
PROCEDURES (Administrative and Computer)

LEVEL 4
PROGRAMS (for Computer Procedures)
OPERATIONS (for Administrative Procedures)

Four different levels, four different graphics used:

LEVEL 1
SYSTEM CONCEPT DIAGRAM - represents a freeform architectural rendering of the overall system.

LEVEL 2
SYSTEM FLOWCHART - defines the SUB-SYSTEMS of the System.

LEVEL 3
SUB-SYSTEM FLOWCHART - defines the PROCEDURES in a Sub-System (aka "Process Diagram").

LEVEL 4
COMPUTER PROCEDURE FLOWCHART - defines the PROGRAMS in a Computer Procedure.

Each level provides the specifications for the next (this is also known as "stepwise refinement"). With the exception of the System Concept Diagram, all of the flowcharts make use of ANSI standard symbols. As to the internal processing logic of a program, since there are many ways to skin a cat, the software structure diagram du jour is used, hopefully a standard one. However, a graphic may not be necessary to express the processing logic of a program. Instead, specifications may be interpreted by a program generator of some kind. Its a "fielder's choice."

CONCLUSION

Until such time as we can master the Vulcan "mind meld," whereby we can transfer knowledge telepathically, there will always be a need for documentation. Its an inherent part of the design process and the principal deliverable produced by engineers and architects. Don't deny it, accept it.

I am definitely not one for excessive documentation thereby becoming a burdensome task. Instead, documentation should be a natural byproduct of the design process. Just as blueprinting is an inherent part of the design process to architects and engineers, so should flowcharting be to system developers. And you shouldn't have to be a rocket scientist to draw a flowchart, keep it simple and try to use standard techniques for consistency instead of reinventing graphics every five minutes. As for me, I have no problem with ANSI standards; it works.

For additional information on graphics in systems design, consult the following sections from the "PRIDE" Methodologies for IRM:

"PRIDE" Flowcharting Symbols

Layered Documentation

Graphics

OUR BRYCE'S LAW OF THE WEEK therefore is... "Documentation is an inherent part of the design process."

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

MY "PET PEEVE OF THE WEEK" IS "BIRTHDAYS"

Last week I celebrated my 39th birthday for the 15th time (you do the math). I've always found it amusing how we as humans like to celebrate birthdays. Frankly, I don't understand the hubbub surrounding it. After all, we really had nothing to do with it. Actually, we're just victims of circumstance. If anything, I always thought the mother and perhaps the father should be congratulated on a job well done, but not the child.

We love birthdays as kids. Its kind of like a surrogate-Christmas where we receive lots of presents. I always felt bad for those kids who had birthdays in December and so close to the holiday season. There ought to be a rule for these people so they can have a party a few months earlier to break things up for them.

But aside from kids, I have little use for birthdays. Anniversaries and holidays like Fathers Day and Mothers Day seem more important to me. At least I had something to do with these decisions.

Speaking of anniversaries, on April 1st, MBA celebrated its 36th anniversary in business. In the I.T. industry you're lucky if you make it past one year. I guess 36 is unimaginable to a lot of people. In fact, MBA was founded prior to the birth of most of the people in the I.T. industry today. This makes me feel a little old, but it also tells me we must have been doing something right in order to last this many years.

To mark our 36th anniversary, MBA has embarked on a new venture in the area of VoIP (Voice over Internet Protocol). We're assisting a new startup company called Tele Monalisa to offer long distance calling over the Internet. We're pretty excited about all of this as we see a big market for Internet enabled calls. Look for our press announcements to come out shortly.

Such is my Pet Peeve of the Week.

eBOOK: THE BRYCE IS RIGHT!

Folks, be sure to check out our eBook entitled, "The Bryce is Right! Empowering Managers in today's Corporate Culture." This is a frank and candid description of the state of the art in management and includes essays on the problems in management today, along with some pragmatic advice on how to deal with them. Basically, this is a condensed course in management. As such, it is suited for managers, either those aspiring to become a manager or for those who need a refresher course. It will also be of interest to young people entering the work force, and is excellent for college curriculums.

Charles Cole of Lyndhurst, OH, said it is a "Very interesting book. Good work! It reminds me of some of the early works I read by W. Edwards Deming. Too bad the American corporate gurus of his day didn't pay him heed."

And Wolf Hager of Fort Myers, FL, says it is "A very impressive publication which requires careful reading and reminds me somewhat of Peter Drucker."

The price is just $20 plus tax. For more information on our book or to order on-line, see:

http://www.phmainstreet.com/mba/bryce1.htm

We have also produced a new one-day training program of the same name. For more information on both the eBook and course, please visit our web site at:

http://www.phmainstreet.com/mba/bryce1.htm

While there, look for our MS PowerPoint presentation describing both the book and the training program.

AND FINALLY...

I received an e-mail from Kurt Davis in Cincinnati who wrote me regarding last week's essay, "The Problem with being ahead of your time."

Kurt writes:

"I've studied your PRIDE methodologies a lot and have always found them to be intellectually sound. Yes, it is robust, but more than anything it has a concrete foundation, something you don't find too often at the university level."

Thanks Kurt for your note,

Frankly, I don't think university professors teach true systems theory anymore, whether its in the business schools or computer science programs. The emphasis is still on computing and programming. As a small example, I would love to see a college prof teach someone how to build a manual system. I don't think they would know where to begin.

This past week I got into a discussion with a consultant over the nature of systems and whether they have life cycles. I contend your systems go on as long as your company remains in business (or changes its business). For example, manufacturing, banking, accounting, and customer systems have been with us for many years. The only thing that changes is their physical implementation. This brings up a point: Systems should be designed logically so they can be implemented many different ways physically (as technology changes). Unfortunately, most companies do not think this way and design them physically which requires them to be rewritten every couple of years.

Again, thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2007 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END