We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Information Systems: Carpenters and Architects

Originally published September 1, 2011

“Let’s build a bridge across the river!”

“Great. I will get a saw and some hammer and nails and let’s start right away.”

“No, I think a better idea is to get an architect. That way we will know what foundation we need, where the stanchions will go, and what kind of pavement we will need.”

“But we are in a hurry. It is going to take a lot of time and money if we get an architect. Let’s just start hammering and sawing right now.”

How many times has this conversation occurred – not in the context of a bridge but in the context of an information system? I recall years ago when I was invited to a meeting to discuss the possibilities of building a new system and was asked to bring a coding pad to the meeting.  Let’s start building code before we even understand what needs to be built. Since we didn’t know what we were building, we had to build it in a hurry. Such was the mind-set of the information systems developer in the 1960s. (Yes, there once were things known as coding pads. Now we only find them in the Smithsonian.)

It is hopeful that time has taught us that we need both architects and carpenters to build a complex structure such as an information system.

The training for carpenters – the database designers and the programmers of the IT industry – is fairly well established. A programmer learns how to write code and compile it. A programmer learns how to read some input and process it into output. A programmer learns how to create reports and run transactions. These are the basics for a programmer. In addition, we have systems programmers, systems analysts, and assorted other types, all who are necessary professionals for the building of an information system.

But the training for architects is much more circumspect. Architects need to know a little bit about a lot of things. Architects need to know about the economics of development. Architects need to know about schedule and milestones. Architects need to know how to envision the final product. Architects need to know about technology and products, about capacity and operating characteristics, about politics and personalities, about the speed with which development can be done, about hardware and software architecture. In short, the architect needs to become familiar with and up to speed on a very wide variety of topics. There are a few formal classes on information systems development architecture, but far and away architects learn to be architects by through experience – on-the-job training. And the biggest teacher of all is failure. Architects learn what is right and wrong by trial and error. Years of experience enable an architect to know good practices from bad practices. At the end of the day, it is experience that is the great teacher of architects. In a way, this is unfortunate, because ANYONE – and I do mean ANYONE – can claim to be an architect. Literally anyone can put ARCHITECT on his/her resume and there is no one to dispute it.

In the very early days, there were no information systems architects. Indeed, when Ed Yourdon first suggested that there should be a structured approach to the architecture of information systems, Yourdon’s thinking was considered to be avant-garde.  And it is probably true that Ed Yourdon and his band of merry men and women (DeMarco, McMenamin, Zells, et al) were the world’s first information systems architects. Structured programming turned into SDLC (systems development life cycle) and became the origin of information systems architecture.

But since the early days of Yourdon, there has hardly been a clear and concise path to becoming an architect. Information systems architecture involves so many different aspects that there just is no one way to become an architect. There are no one or two disciplines must be mastered in order to become an architect.

Today we know that we need the architect. And when we finally get one, we hope and pray that the one that we get knows what he or she is doing. We hope that the architect’s education has included a generous blend of failures and successes.

  • Bill InmonBill Inmon

    Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.

    Editor's Note: More articles, resources and events are available in Bill's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Bill Inmon



Want to post a comment? Login or become a member today!

Posted September 6, 2011 by sgupta.email@gmail.com


That’s a great analogy. ‘Practice of Architect’ grew from builders having difficulty as designers and supervisors. Information System is traversing the same path. Looking at the pace of change (where disruptiveness is the norm), I am not sure of right-frameworks, practices and training-needs firming-up anytime-soon. However there is a good amount of experience getting shared, and that’s quick-shared learning. Another plus is that there is a method in the madness, somehow it’s all adding up; this fluidity is fast becoming strength. 'How can I be sure of trusting a possible voodoo-architect with my Information System?', is a good question which Bill raised. But as Bill said, it’s not possible to walk without one.


Is this comment inappropriate? Click here to flag this comment.