From Flowcharts to Objects — Lessons for Enterprise Architects

by Jeff Tash, ITscout

Once upon a time, long, long ago, back when engineers still carried slide rules, the most important tool in a programmer’s toolkit was his trusty old plastic flowchart template. It allowed developers, using pencil and paper, to graphically draw rectangles to represent processing steps, diamonds to reflect if-then-else decision tests, and sundry other assorted shapes to depict such things as input and output devices like punch card readers, magnetic tape drives, line printers, and visual displays. A program’s processing logic was described by the various intersecting lines interconnecting the multitude of geometric shapes.

Flowcharts were primarily intended to be used as a way for programmers to communicate, especially when trying to explain to non-programmers what a particular program actually does. At their core, flowcharts are, first and foremost, all about process.

In the beginning, back when the art of programming was still in its embryonic stages of development, the physical appearance of flowcharts often resembled a plate of spaghetti with its many multiple lines crossing every which way. Besides being difficult to read, or even follow, spaghetti code was almost impossible to maintain or enhance. That’s what led to the structured revolution that began during the 1970s, especially after the famous Dutch professor Edsgar Dijkstra began cajoling software developers to avoid the use of GOTO statements. Of course, I always kidded that Dijkstra must have been a quiche eater because real programmers never worried too much about GOTOs. What real programmers always yearned for was a COME-FROM statement (since they spend the majority of their time reading existing code and trying to figure out how the execution threads actually get there!). Unfortunately, the remedy for spaghetti code -- structured programming -- aka functional decomposition -- itself introduced a whole new set of reusability issues (see discussion below).

Another major trend that emerged in the 1970s was the practice of modeling data, specifically entities and relationships. A big advantage of data modeling over process modeling is that entities and relationships are, generally, very stable. A customer is a customer. An employee is an employee. A contract is a contract. These real world entities don’t change very often. This contrasts markedly with processes which forever seem to be undergoing radical transformations -- like every time there’s a business reorganization. Most real-world business processes are anything but stable -- they are constantly changing.

Why are data models stable while process models are not? Because a data model is a scaled-down, detailed representation of a real-world object. Conversely, a process model is, most commonly, a functional decomposition whereby a large process is iteratively broken down into ever smaller and simpler tasks. The result is a decomposition hierarchy that is visually depicted by an upside-down tree with its root at the top and branches and leaves extending downward. The leaves on the end of branches correspond to trivial tasks. The highest level branches (the ones closest to the root) often reflect organizational structure. In essence, every time there’s a reorganization it’s because the business process has changed, or vice versa.

There’s another major distinction between data models and process models that’s quite revealing. Ask a dozen different software developers to each create a data model to represent a single set of real-world objects. In all likelihood, all dozen different models will closely resemble one another. Next, ask the same dozen programmers to functionally decompose a single business process. I can almost guarantee all twelve decomposition trees will each be considerably distinct.

The important point to grasp here is that when modeling processes based on functional decomposition, the boundaries that delimit each process module are, in essence, largely arbitrary. Each person’s decomposition tree consists of its own combination of branches and leaves and, much like their counterparts in the living world, each tree is quite unique. By definition, each branch points to a node that corresponds to a module. The reason why modules seem like their boundaries are arbitrary is because different people naturally decompose the same process very differently. Since, like in nature, every tree is unique, the classification of modules is often understandable only to the original developer. No wonder attempts to reuse modules almost always fail. The boundaries for data models, by contrast, are not arbitrary. They are a function of the real-world objects being modeled. Modules, therefore, can in fact be successfully reused because they’re organized around objects which can be found… and then changed… or extended…

The object revolution that began in the 1980s with Smalltalk and C++ -- and led today by Java, C#, and SOA -- is a manifestation of the colossal shift from process-centric to data-centric software development. Process-centric is terrific if your emphasis is on automating new systems. Ask an end user what they do and they can walk and talk you through each and every step of a complex process. Yet, most of those same people probably couldn’t identify an object unless they tripped over one.

The problems associated with functional decomposition don’t rear their ugly head during the development phase of the system life cycle. Rather, big problems begin to emerge during the maintenance phase. That’s when disagreements arise over the specification of what is a module. It’s why the natural tendency for so many young programmers when asked to make a change to an existing system often come back with a recommendation to throw away all the old code and start all over anew. Object-oriented development, by comparison, has made a significant impact improving reusability. The reason why developers can reuse code is because they can find objects. Object delimiters are not arbitrary -- they model real-world stuff.

Object-oriented enables developers to build software the same way users usually express their requirements -- by exception. Invariably, developers are told how users want a system to behave just like it already does, only differently.

So, what’s the lesson here for enterprise architects? How does a discussion spanning flowcharts to objects affect the world of enterprise architecture? The main point to emphasize is how critically important it is for enterprise architects to focus on initiatives that emphasize stable, non-arbitrary models -- the kind where if you ask a dozen different people to design one, all twelve models will share a striking similarity.

Nowadays, enterprise architects often expend significant amounts of time and effort building business process models. Be careful to avoid making the same mistakes of the past. I strongly urge you to de-emphasize modeling based on functional decomposition. Instead, concentrate your efforts on approaches that depend on modeling business events -- the most reusable facet of computing -- and business rules -- the most volatile aspect of computing.

An enterprise architect should begin by creating a technology architecture and then preparing a presentation for management explaining the enterprise’s technology portfolio. Like objects, technology architecture represents real-world “things” such as systems, applications, products, vendors, etc. These are not arbitrary. Quick payback can be achieved by identifying opportunities to reduce costs through consolidation and the implementation of standards.