<-- Back to full color view

What is Architecture? Why It’s Important to Plan for the Final Requirements

Originally published March 31, 2011

At a recent conference, the question arose – what is architecture? While the question was about  information architectures, I present the following to explain the importance of an architecture that is developed to meet the final requirements.

Anyone who has been to Santa Fe, New Mexico, knows that architecture is. You drive through the streets of Santa Fe and you can be nowhere else in the world. The adobe, the vigas, and the exposed beams all tell you that you are in Santa Fe. And the message of your whereabouts in Santa Fe is loudly confirmed by the Plaza, the La Fonda, the Ore House and other well known local attractions.

Architecture defines Santa Fe as in no other city, But architecture is a hard thing to define. There are many ethereal aspects to architecture, and merely seeing exposed beams and adobe does not define architecture. In truth, architecture is both very simple and very complex at the same time. I prefer the simple approach to understanding architecture, so let me give you a very simple explanation of architecture.

Architecture is the road to my house.

I live in a village in the countryside. We were the first or second house in the village many years ago. When we moved to the house we live in, there was one dirt road to the village. And with only a few people living in the village, that was not too bad. It was adequate.

Our developer petitioned the county to upgrade the road our village. The county said that they had not budgeted for an upgrade so nothing was done. Soon there were more homes in our village. Soon the small dirt road was overwhelmed. It was dusty in the summer time and icy in the wintertime. And it was always crowded. The builder went to the county and showed them the plans for building out the village. Reluctantly the county paved the small dirt road into a two-lane road.

This was an improvement for a while. But soon more homes were being built and the two-lane paved road was inadequate. But the county did not have the budget to do anything.

Then one day we woke up to a lot of noise and discovered that our road was being torn up. A sewer line needed to be dug. There was more dust, more construction, more inconvenience, especially as now the number of cars on the road had increased.

But after the inconvenience of the sewer line was completed, everything was fine. Except now there were even more cars on the road. The builders once again petitioned the county to expand the two-lane paved road. But – once again – there was no budget.

Then one day we all woke up to the road being torn up – again. This time it was a trench for television cable that needed to be dug; and, as fate would have it, the television cable path went directly across the road. So there was more disruption, more construction, more detours. And this time there were a lot of cars. It was a real mess.

After the television cable was buried, the traffic on the road was unbearable. All neighbors banded together and submitted a complaint. Even though the county did not have the budget (once again), the county tore up the two-lane road and built a four-lane road into the village. It took a long time for the construction, and during the building process traffic was just horrible.

But when the four-lane paved highway was built, at long last there was smooth and safe traffic in and out of the village.

And the county? With all of the building of roads, rebuilding of roads, tearing up of roads, detours, the laying of sewer lines and cable television lines, the county ended up spending far more by building stopgap temporary roads than they would have spent had they sat down at the beginning and planned for the future. By keeping their eyes focused on the short term, they spent far more budget than if they had understood and planned for the final requirements from the beginning.

Whether architecting a county road system or an information system, planning for the final requirements is the only proper route to take.

SOURCE: What is Architecture?

  • 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!

Be the first to comment!


Copyright 2004 — 2020. Powell Media, LLC. All rights reserved.
BeyeNETWORK™ is a trademark of Powell Media, LLC