The Human Face of Software Architecture

by Vitalii Tsybulnyk 25. December 2009 13:51

Over a last two decades, the human aspects of software engineering have become a central topic among researchers and practitioners. It appears that software construction has even more in common with some sort of social activity than with technical engineering [Cockburn04]. This happens partially because "software is soft" [Fowler98], which means that existing practices of civil engineering don't work well for its dynamic requirements and rapidly changing environments. But an even more important issue is that software is the product of human thinking processes, which makes the 'people factor' a key aspect for future investigation in the understanding and improvement of software construction.

The result of this 'human-centric' era is that some important parts of software development are already being referred to by most practitioners as not only engineering, but also a social subject. This list includes software architecture.

'Software architecture' is a terribly overloaded and ambiguous term, even by our industry standards. There are a few formal definitions, (for example, "architecture is the highest level concept of a system in its environment" or "architecture is the set of design decisions that must be made early in a project"), and researchers and practitioners argue with such definitions [Fowler00]. Ultimately, there is still no better definition than Ralph Johnson's: "Architecture is about the important stuff. Whatever that is." But 'importance' is a very subjective quality, and the people factor plays a huge role in the definition of software architecture. Even if you consider that software architecture is a 'set of design decisions' (such as design patterns usage, object model, etc.), there are a significant amount of human factors in these decisions. In this article, I would like to give attention to those factors, and try to summarize the main human aspects of software architecture.

 

Design Patterns and Best Practices Are Always Used With Bias

Design patterns are not concrete, especially in where and when they should be used. Alistair Cockburn, in his brilliant article [Cockburn96], proves that even the use of well-known design patterns is significantly influenced by social issues, as well as the designer's personal bias in designing a solution.

Design decisions are balance points between intent, external forces, principles, and counter-forces, so this balance is unique for every designer and project environment. Cockburn presents 15 related patterns, which show social issues driving architectural decisions. It appears from this article that identifying the social background influencing design decisions is significantly more important for successful software architecture than the engineering background of these decisions.

 

Architecture Is Often Built Evolutionary

Another very important quality of architecture is agility. Software architecture first appeared in the early 1970’s, and inherited much from a civil architecture. As a result, the methods of software architecture were quite formal and the whole concept of the architecture supposed a 'beforehand' construction. However, when a planned design stage became included into a wider and wider range of projects, it became apparent that careful and formal architecture, developed before the beginning of coding, doesn't work well for all software projects. That was the beginning of the agile era in software development. The idea of agile-style evolutionary architecture is illustrated in Martin Fowler's article [Fowler00]. Fowler proposes to start architecture with the simplest possible current requirements solution (YAGNI principle) and then 'grow' the architecture through the project's lifecycle and changing requirements, using refactoring techniques for safe incremental changes. Even for database design, which is traditionally considered to be the most 'fundamental' part of software architecture, Fowler uses refactoring and other agile techniques to build it evolutionarily [Sadalage03].

The evolutionary nature of architecture is a very important development from the point of view of human aspects in architecture. It means that real-world architecture is not a static concept with formal academic methods; instead, it is a dynamic, subjective, non-linear process with many unknown parameters. So the software architecture of some projects on the current stage is closer to handicraft, or even art, than an industrial engineering process.

I spent over 5 years of my professional career working as a developer and architect in small to medium-sized projects (SMP’s), some of them startups. In my own experience, carefully planned architecture almost never helps to make a project successful. On the other hand, projects with mediocre architecture become successful, both technically and financially, quite often. This happens because SMP’s and startups almost never have adequate resources or pre-defined long-term requirements, so careful prior architecture leads to project failure, either because of an over-spending of time and human resources, or because the architecture rapidly becomes out-of-date due to changing requirements. Only human intuition and the use of an evolutionary approach allow technical leaders or architects to find a balance between all these hostile factors and bring such projects to success.

 

Software Architects Are Human Beings

There is also an essential fuzziness in the definition of the 'software architect' role in the software construction process. Some managers have a difficult time hiring for an 'architect' position because they don't exactly know what an architect's duties and responsibilities are. However, if the right person appears in a team, everybody can easily recognize who the architect of the project is, even without a clear consensus on the meaning of this role.

Martin Fowler allocates the roles of 'Architectus Reloadus' (the person who makes all the important decisions and does this because a single mind is needed to ensure a system’s conceptual integrity, and, perhaps, because the architect doesn’t think that the team members are sufficiently skilled to make those decisions) and 'Architectus Oryzus' (the person who is very aware of what’s going on in the project, looks out for important issues and tackles them before they become serious problems, collaborates, programs with a developer, and participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in nontechnical terms, etc.) [Fowler03]. However, these two types of architects could be also explained as just two different sorts of people playing the architect's role, approaching the problems in different ways to compensate for different natures and skills.

Luke Hohmann separates architects into 'tarchitects' (technical architects) and 'marchitects' (marketing architects), according to the technical or business perspective of system's architecture [Hohmann03]. However, this bias in an architect's role could also be explained by the individual strengths and personal spheres of interest of two different people playing the role of the software architect.

Basically, 'software architect' is not just a role in a development process; it is a very concrete person with a very concrete set of human characteristics, such as knowledge, skills, experience, and communication abilities. Moreover, an architect almost never works on his own. He works in a team, so the team's skills, biases, and intra-team communications all contribute to the successful design development. In my own experience, projects are more successful if an architect is able to explain important design decisions to developers using just a sheet of paper with clumsy boxes than if an architect can draw perfect UML diagrams (which nobody can easily understand).

 

To summarize, the characteristics of people have a first-order effect on software development, not a lower-order effect [Cockburn99]. Social issues, human intuition, the reaction to rapid changes in a dynamic project's environment, personal bias, and the unique set of skills and experience of team - all of these human factors influence the 'big picture' of the project and key technical decisions, even more than all the engineering factors put together (knowledge of design patterns, optimal object hierarchy, detailed UML schemas, etc.). Engineering techniques are just good instruments, which are used by human beings with all the logical consequences.

 

References

[Cockburn04] Alistair Cockburn: “The end of software engineering and the start of economic-cooperative gaming”, Humans and Technology Technical Report, January 2004

[Fowler98]  Martin Fowler: “Keeping Software Soft”, Distributed Computing, December 1998

[Fowler00] Martin Fowler: “Is Design Dead?”, XP 2000, July 2000

[Cockburn96] Alistair Cockburn: “The Interaction of Social Issues and Software Architecture”, COMMUNICATIONS OF THE ACM , Vol. 39, No. 10, October 1996

[Sadalage03] Martin Fowler, Pramod Sadalage: “Evolutionary Database Design”, martinfowler.com, January 2003

[Fowler03] Martin Fowler: “Who Needs an Architect?”, IEEE Software, July/August 2003

[Hohmann03] Luke Hohmann: “The Difference between Marketecture and Tarchitecture”, IEEE Software, July/August 2003

[Cockburn99] Alistair Cockburn: “Characterizing people as non-linear, first-order components in software development”, Humans and Technology, October 1999

Tags:

Software Architecture

Add comment




  Country flag

b i u quote
Loading


Blog