When one hears the term architecture, he may think of Jørn Utzon, Renzo Piano or the bigger then life Howard Roark. Why is this flattering analogy used in the IT context?
Applications can be big. When you listen to Microsoft, you think that its new operating system is the biggest technological effort endeavoured by mankind. Was the construction of the Empire State Building in the 1920s a smaller task than the writing of an operating system that, just maybe, will not crash as often as its predecessors? I do not know how to compare efforts like the defence of Stalingrad, the eradication of smallpox or the writing of the Gettysburg address (172 words in total). Nevertheless, I am convinced that software development projects may be as big as projects get.
Some software products find themselves used in a way never dreamed of by their creators. For example, the Macintosh received the ability to control multiple screens without a major change to its operating system. Windows had to be re-written from scratch, X-window had that feature from day one. A system that I designed for testing of other systems was used to load data into systems instead of keying it manually.
Software is considered more extendable than a building. No one would think to extend a tree house to accommodate 3,000 people for thirty years. More than once have I seen an overnight huks that was extended into a million lines system, without any one asking if we starch the system too much.
As software is big, extendable and used in unpredictable manner, it must be able to replace some of its components over its life. Look at my dear Honda Odyssey. I will commit a driving offence if I replace its wheals with different size wheals , or perform a structural change to the engine. With software the story is different. Our windows 98 is not as different from the old PC-DOS that IBM sold us in 1982, as Bill and his marry marketeers love us to think. Yet, it runs on a machine a million times faster with a hard disk a million time bigger and more memory than any one could have dreamt of in the 80s.
Any useful software component finds itself quick smart used as a component in a bigger software artefact, which in tern, being useful, will find itself in an even bigger artefacts. Even worth, our useful piece of software will find itself used, as components in many systems, of some we may even not be aware. The converse is also true, every system is build of smaller components whose developer faced the same problem.
The special ingredient that enables software to grow to mammoth size, be used in a manner not conceived by its creators, morph its components in mid life in participate in bigger systems is Application Architecture.
Remember, Frank Lloyd Wright was not a civil engineer. He did not calculate beams, cement or steal types. He worked with a civil engineer who did this for him. So do Software Architects, they do not design databases, nor write programs. They neither design screens nor test systems. Software architects are also unlike to manage the project or integrate the components delivered by the various specialists.
What the architects do is to talk with their users, see what they want. Than find what the users need. The architect has to take into account all of the requirements that we discussed earlier such as size, growth, flexibility. A good architect will try to demonstrate to himself that the system he designs will behave as desirable in many ways (for example let his family members play with a prototype). Than the architect has to dream a way to bring that thing to live, and share some top of an envelope scratches with the engineers (can this be done?). Than the architect has to convince the users that what he, the architect wants is what the users needs and that the user should pay for it. Caprice behaviour like that of Jørn Utzon is rarely tolerated.
Having done all of this the Architect is ready to write the blue print of a system. The document will describe how the system will be seen by the users, how will it be partitioned so that it can be built by different contractors. The architect may describe a rollout timetable for the system, or recommend a big bang approach. Sometimes the architect will tell how to test the system and what key performance indicator should be managed. The architect can tell even what key performance indicators may be ignored, for example today we consider disk space as free. The system architect may even prescribe the development process that has to be followed to build the system in an efficient manner.
I have seen a case when the system architects deliberately limited the versatility of their product, knowing its limitation. The example is Digital Equipment Corporation (DEC) VAX systems. The contract dictated by DEC prohibited the use of this product for air traffic control preposes.
Architecture defines interfaces, design defines how to build the application.
Architectures are implemented by designers and designs are implemented by builders. Architecture does not have enough detail so that a builder can build of them. Designs do not represent the big picture well enough so that the above ingredient will be visible.
Architect often err by creating an architecture that is too generic. For example An architect required to define a vehicle object may dream of some thing that will
* fly, * travel fast on road; like a Formula 1 race car, * be stable off road; like a tank, * sail in high sees, * dive better than a Russian submarine and ... * drill channels under the ground.
This is bad architecture even though it has all of the above ingredients. Architects who design creatures like this may though have a long and successful career. With a bit of luck they will be able to job hop every a few years living the "detail" work behind to their "incompetent" colleagues.
Architect often err by creating an architecture that is not specific. Imagine that the following will be submitted as an architecture:
The constriction engineer will classify activities that will be performed in the space. He will than arrange them in such a way that: * Related activities will be located close to each other. * conflicting activities will be isolated from each other.
This is bad architectural statement even though it has all of the above ingredients. What the architect meant to say was:
* The dining room will be near the kitchen and * the parents bedroom will be away from the rumpus.
The Zachman Framework describes a list of documents that may be chosen by an Architect, it is the periodic table of the System Architects. One of the first tasks every architect has to do is to decide which of the multitude of documents in the framework will help him do his job.