According to a commonly admitted definition, the role of a software architect is to define “macro-aspects of a system based on the inputs from its stakeholders.” This implies that architects cannot be driven solely by technical considerations. They need to bear in mind the requirements of different stakeholders which often constraints the choice of technology and architectural design.
In his blogpost, Phillip Calçado emphasizes that, along with system users and project sponsors, the software development team is an important stakeholder because developers are very directly affected by architecture decisions. Hence, the development environment should be taken into account by the architect even though it may limit the scope of his choices and even result in renouncing to a technology that would objectively be the best for the project.
Calçado stresses, for instance, that it is crucial to take into consideration 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?
Another constraint may come from team distribution, be it physical or not. In Claçado’s example, a system for stock exchange for traders has three parts - data gathering, user interaction and transactions - with a different team working on each of them. Even if, technically, designing the system as a single module may be the best choice, the architect will rather have to design three modules that are black-boxes so that “teams can work in a fairly isolated stream.”
More generally speaking, Calçado stresses that it is essential to “collect feedback and respect the opinion of the group that will probably be most affected by your decisions.” One of commentators, Alberto Brandolini, goes along the same lines using the notion of “sustainable architecture” that requires the architect to assure that his “architectural design can achieve commitment by the team members.”
Taking into consideration this kind of constraints is important for the success of a project. This does not mean, however, to definitely renounce to a technique that would really add value to a project, because of time and skills availability constraints or resistance from the team. The role of the architect is indeed to elaborate the strategy for introducing change and to integrate it into his design:
[…] the architect should include a migration into the system’s roadmap. […] You can start by using Ruby [or any desired technology] 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.
