All ‘classic’ (i.e. those used in regular university and certification programs) books on architecture I can remember of will state clearly that a software architect is responsible for defining macro-aspects of a system based on the inputs from its stakeholders. Although clear this sentence is very hard to map into day-by-day actions.

Probably one the least understood aspects of the architect role is that the software development team (which the architect is part of) is a very important stakeholder. An ideal architecture has to fulfill the requirements from the system users, the project sponsors and the developers.

This means that maybe the ideal architecture or a project won’t always use the ideal technology or techniques. It is wonderful when you have an experienced team of developers that will not have any problems adopting most of these but generally it’s not the case.

In most cases the architect will have to consider among the drivers of technical choice the team’s skill set. Imagine you join a team of long time VB6 programmers to develop a new website. No one has experience with Ruby on Rails although you know that is exactly the best tool for the job. The website must be delivered in a short time frame, no time for training. Would you go for the best technical choice?

At the same time an architect have to think about the future. Ok, maybe Rails won’t fit into this timeframe but if it would really add value the architect should include a migration into the system’s roadmap. I have some experience introducing Ruby through baby steps, at each iteration one or two stories would be implemented using the new platform. You can start by using Ruby whenever a script or small program is needed, for example and introducing the new web development platform slowly. The most important is that you should have a clear view of what the system should look like in the future and how to make this come true.

But before considering using Ruby or any new technology an architect should present to the developer his thoughts. Just as you will ask you users about how the interface should look like you must get the input from the developers. Of course just as the user can’t have his ideal Second Life-like user interface your developers will come up with ideas that won’t be feasible or desirable. The important thing is that you should collect feedback and respect the opinion of the group that will probably be most affected by your decisions.

I remember working at a highly distributed project. I was at the Rio de Janeiro branch and we had people in London, Germany and New York, I was basically impossible to have all the development team in he same conference call due to the fuses. The architect for the project was in NY, maybe the smaller office with only a few developers. It was very interesting to do a svn up and see what new toys he had inserted into the project. I can remember that by updating my workspace I became aware of the incremental introduction of Spring (1.2 then 2.0), Java 5, native C++ code accessed through JNI, PERL, Python and AWK (performing the same task: simple substitutions in configuration files during the build). Our project was a Java EE standard thing but nobody besides him had any idea of how the system was structured end-to-end. When questioned about this by senior management he would say something like “It’s all on the wiki, those devs are lazy!”. I’m sure you can imagine the quality of the single-page wiki description of the whole mess.

The problem in this case is not exactly on the terrible technical choices but in the fact that we, developers, wouldn’t be aware of that changes until we update our source files –and prepare to solve conflicts. If the architect can’t communicate to his colleagues in Europe or South America properly he should have adopted a different strategy than simply throwing changes at us.

Team distribution, physical or not, is a major issue in architecture. Say we have a system that allows traders to exchange stocks. One part of the system is about gathering data from the market, the other part is about the user interaction and other is about submitting the transactions back to the market. For any reason someone decided that we will have different teams working on each module.

At the end of the day is a single system -any of these modules in isolation would be useless- and could be architected as this. There is when the team structure influences the architecture. Although all modules will run in the same JVM, application context and web context they are being developed by different teams. When the information gathering team needs to perform a full build they shouldn’t have to be aware that the transactions team is working of a maintenance release.

In this example scenario the architect have to design the modules so that those parts of the same application –they are not components- will be black-boxes (or at least grey boxes) and teams can work in a fairly isolated stream.

Using Rails, introducing AWK and friends, designing the system as a single module and the like may be the best technical design but architecture is not about technique, at least not only about this. It is the same concept that exists among civil engineering and architecture.

When you go for an apartment inspection and realize that a perfect place to rent unfortunately receives direct sunlight at undesired times you are facing exactly the problems we are talking about here. Maybe placing the building that way was the perfect technical (engineering) choice but an architect should have realized that eventually people were going to live there and they won’t be happy waking up at 6a.m. burned by the Australian summer.

Remember: people will ‘live’ in your system. Outside and inside it.