Back in the mid 90's, I was lucky enough to serve FedEx as subject matter expert and project lead for the first methodology-driven application to be delivered that was based on the recently completed information strategy plan for the Air Operations Division we spent nearly two years developing. As a small group of about 10, those of us who developed the plan had spent the first several months evaluating and selecting first a methodology, and second a documentation and application delivery environment to support it. We selected James Martin's Information Engineering methodology, and then the IEF toolset from Texas Instruments, precisely because it was entirely graphical in nature, and generated all the code required to implement the documented business rules and entity relationships directly from the diagrams. It went far beyond what we used to call 4GL Generators to fully integrated CASE, in that the resultant code included all the DDL, stored procedures, messaging, and client code targeted to practically any database, O/S, or browser (back when everyone used Netscape
). So, to the point of the discussion, we have definitely digressed from what was state-of-the-art with graphical design and development tools used to be, to today.
One of the most valuable components of the IEF toolset was its powerful ERD tool. The purpose of the tool was not just for the programmers. Programmers tend to be self-interested when it comes to tools. Before anyone gets defensive, let me say I have been a programmer since the 70's, and have worked with, hired, and managed hundreds of them over the years, so I get to have an opinion. The greatest value in the ERD (and DFD, for that matter) is as a tool to gain consensus with the user about what an application is to do. The number one reason I've seen application development efforts fail is because the folks doing the programming just thought they understood what the customer wanted, and then included a healthy dose of what they "really need", and so delivered a glove that did not fit the hand as expected. Through experience, I assert that ERD and DFD are the most effective tools available, even yet today, with which to communicate analysis and design constraints back to a customer, before any coding or design is started. If you do not have an agreement on terminology, the entities involved and their relationships, and what business rules are about to be implemented, you are really wasting your time and the customer's to go any farther. ERD and DFD pictures are easy enough for any business unit manager to understand. I have taught them untold times in my career, sometimes to audiences over a hundred. I always start my presentations with a quick review of how to read the diagram, which takes 5 minutes.
The beauty of the IEF was the ability to drive the documentation to such a detailed level that the code came from it instead of vice-versa. Another common failure of applications is lack of documentation and eventual death through the inability to maintain and extend them as a result. With the IE methodology, the documentation is done first. What a concept. You actually get to know what the finished product looks like before starting. I suspect most programmers who would think that diagrams get in the way and have no value, would also allow a home builder to just start nailing lumber together to build their house without any plans or diagrams. Just trust me
The ugly news is, IEF is no longer available. I understand it has evolved into a product call GEN from Computer Associates, but I have no idea what it costs or what it offers. The worse news is, at FedEx we spent several million dollars over the course of three years learning the methodology and the toolset, developing the underlying information repository, ERD, AHD, RAW Matrices, etc. required to get to the generation level, and then applying them to the first application. The application was great success, and the architecture was then in place to quickly develop additional applications, but the front-end cost was high.
Today, I use the same flaccid diagramming tools that are already mentioned in this blog, like Visio, to develop my ERD and DFD for new work. I have a tool that was given to me by Texas Instruments when the IEF training was completed, called Business Design Facility, that I use if I'm the only one who will be working on the diagrams because I can't share it. I would personally love to find another tool like IEF that I could afford to own.
As a last word to programmers who dislike diagrams and favor the "makes me look really smart" approach of screens of code, please reconsider. The diagrams and CASE are not attempts to make you redundant, any more than the machine gun made foot soldiers redundant. They are just extremely effective ways to improve your efficiency and effectiveness by providing an iron clad way to understand the problem before developing the solution and removing ambiguity about whether the solution is correct or complete.