In the IT business you now can be an Information Architect. But what is architecture?
architects do not make architecture
Architects design products that reflect their belief. This sentence has two meanings. Both the architect and his product have the belief. I used the word belief not to become religious about things. Belief expresses a vision that lasts. Architecture is not about having a good idea, or every time having a good idea. Products designed over the years share a, probably developing, vision.
The architect's vision must also last because others need time to recognize it. Once they do discover the line of thought the designs will get attention in the designer community. If the qualities then get recognized and communicated, followers may adapt the vision and possibly expand and improve on it. A stream or culture then has emerged. So criticasters and colleagues determine the if the products deserve the qualification "architecture". It is never the architect that himself set out to produce architecture. The architect had the drive to:
The community doesn't so much decide if a design is good or bad or if the vision is good or bad. It seems that visions that entirely cover the problem area are most appreciated. The vision or belief is most usable when it can be applied to different parts of the total product and at different levels of detail. This is why famous building architects could not only design buildings, but also lamps and cities. Also within the context of the building there are different hierarchical levels. The vision can regulate the shape of the building and of a room in the building but also regulate how a window is placed in the wall. So it is not the contents of the vision that is important. Its quality lies in:
- make the design express the vision
- develop the vision
The following diagram shows the relationship between vision and design:
It shows that, once you have entered the loop, you have a good chance on self-propelling your architectural capabilities.
- a vision to regulate the entirety
need for vision
Is a vision needed? Can we not just rely on engineering? IT people have not yet been able to automate the constructing of software. That is because in most projects the combination of requirements and tools with which to solve them do not give a single unique solution. When giving a number of developers the same requirements and tools they all make a different solution. Apparently requirements leave room for freedom. Different engineers fill in the free space in different ways. Being aware of that free space and finding enduring ways to fill it distinguishes the designer from the engineer. Once you saw the free space you recognize the need for vision.
So it seems that vision is needed to resolve a lack of requirements. Why were those requirements missing then? That is because they are requirements for which no measurable or verifiable criteria can be formulated. It doesn't make sense to formulate requirements of which one cannot upon delivery
objectively measure if they were met.
We join ranks in objectiveness and distinguish ourselves in subjectiveness. The architect enjoys the vision making the void subjectively work.
The outcome of the Design activity generally is a Model, a model for the product to be developed. The model can take different forms. It can describe the Product to be constructed by text, drawings, schemes, artificially generated photo's etcetera. A model usually is a simplification of the reality. Normally models cannot attempt to model reality in all its aspects and details. In the software industry the product itself is a model too. Software often models the behavior of a real-life phenomenon and then also can only do that by leaving out many of the real-life aspects and details. The software designer and information architect thus make models for models. This does say something about the chance of coming up with a good product. It also says something about the activity of constructing. The Model that is input into the construction activity leaves room that needs to be filled in. So there is a design type of activity hidden in the construction. It must be this way. If the model were as precise as the product it would have become the product.
room for vision
The room for culture and religion only becomes available after the primary issues of food and shelter being mastered such that they no longer require the full attention. It is interesting to try and guess how the people managed to get the below giant stones transported over hundreds of kilometers and how they managed to place them up-right.
But amazing is that their society was developed to be able to afford spending so much energy on such a "useless" thing. Gravity and friction existed and also in those days w = f . s applied. Whatever the source was, they had more energy than needed for the production of food and shelter.
If that energy source was human their farmers and carpenters must have been really good at what they did.
In the software factory or IT business there must be a surplus in intellectual energy that can be spent on "useless", non-measurable things. The room for vision and design only becomes available when the workers are not or no longer fully occupied by technical issues. You need not be occupied by technical issues when one or more of the following apply:
- technical responsibility is deferred to other people
- your technical expertise is proven already
- the design will not materialize into a product
deferring technical responsibility
This is good practice in the software industry but at the same time quite dangerous a phenomenon. There are two perspectives on the encapsulation of the technical issues. From the HRM perspective there traditionally is a split in competence which at the same time constitutes a career path:
In the above Analyst and Consultant have most of the architects properties in their profession. For commercial, economical and organizational reasons these functions have been segregated from the programmer. It seems unaffordable to allow a consultant to still develop software. And with the sector typical technology push, submitting to segregation quickly brings you to the point of no-return.
From the software development perspective technical issues get addressed in a separate phase of the project. Different "project methods" use different names. The methods that I had a look at distinguish about the following phases, activities or processes:
Sometimes Analyses and Design are combined into a single phase, sometimes Design is included in the Construction phase, sometimes Construction is called Implementation. The point is that the strive for manageability causes the architect to get separated from the building. Taking a higher perspective it seems that the architect is also in danger of losing the link with the company and its business processes. Software development methods do not very well deal with such stuff. They probably consider it outside the scope of the method. More abstract methods like Prince-2 do not whish to deal with specifics of certain types of projects. Strategy management such as with The Balanced Score-card recommend IT but fail to make the link between the strategy and say the Enterprise Bean. In the above scheme we can assume business analyses, alignment and alike to have been included in the initiation phase. Anyway the architect is at risk. The methods separate him from the business as well as from the software development.
proven technical expertise
Once evolution carried the IT worker from programming to designing there is a chance that his technical expertise is sufficient to free the architect from stumbling over it. Technology seems to develop at light speed though. At the conceptual level however it doesn't. The IT workers still have a hard time getting to a 2 second response time and still worry about what to do if the program cannot acquire the additional memory. The architect knows this can be solved.
Building business applications, interactive graphical systems, batch programs, EDI services, distributed systems, one/two and three tier applications, for 24/7 types of companies with big cultural differences you may be ready, ready for viewing such issues other than from a technical perspective.
l'art pour l'art
Designing Information systems that are not going to be built and implemented is the way to develop vision. It is very difficult. In the absence of constraints the architect can only rely on his vision. Time, money and other valuable resources cannot provide the excuse anymore.
My guess is that Rietveld was smart enough to understand that his chair was not going to populate livingrooms all over the world. The chair is an expression of his vision and most probably enabled him to further develop his vision.
The helicopter from da Vinci would need another 500 years, even though he wrote that he tested the principle on a model that would go up in the air.
architecture and the technology push
Room for architecture only becomes available once not having to worry about technical issues anymore. This makes it unlikely that architecture can base itself on technology. Even more unlikely is that an architectural vision would base itself on a particular instance of technology. If your vision would only work with one particular technology in IT you'd need a new vision every couple of years. Consumers are getting used to products only lasting for a couple of years. I'd hope that visions last longer.
The Lego company has been changing its product line. Under the title educational you can still find some of the stuff with which I had to build cars, planes, houses and castles: bricks, plates and wheels. You now buy a package that allows you to build King Leo's Castle. Another package allows you to build a particular car.
I use these Lego examples to show you that the technology push can even make it obsolete for you to be an architect. I need not mention names of IT products that do the same. In general terms those 4-GL and total-solution type of products determined the architecture for you. Some of them even go as far as modeling your business for you. Those have then covered the whole range from business modeling to implementation. You buy their architecture.
architecture and the methodology push
All these new methods do serve a worthwhile purpose. They do not make you a good architect / designer. They can not replace a vision. Management methodologies can be helpful in organizing and controlling the process of coming from an idea to a working product. Modeling methods can be helpful in communicating and formalizing the design. But all methods work equally well for good solutions and for bad solutions. They cannot help us in developing the vision and cannot help us designing in the context of that vision.
Architecture is the recognition of the expression of a vision in -the design for- a product.
the next episode
Do architecture and design develop themselves? Do architects/designers? What is my vision? Is it complete and transparent enough? Is it a vision that has something that can regulate IT solutions? Can it regulate the design at different levels, from the level of source code to the level of the business strategy?
Theo van Eijndhoven, 2002