The socio-technical perspective of dependencies highlights the benefits of identifying relevant dependencies as early as possible in the development cycle, so that the project can institute appropriate coordination capabilities. As software architectures become an integral part of the development process, they represent a key source of technical and organizational information for identifying dependencies. However, software architectures represent a higher level of abstraction that could potentially hinder the identification of relevant technical dependencies and, consequently, important coordination requirements.

The growing usage of standardized design and modeling languages, such as UML, might represent a way of overcoming these challenges by using information extraction and graph-theoretic analytics similar to those used to mine software repositories, as discussed earlier in this chapter. We could then envision a “coordination view” of software architectures that combines the product’s technical dependencies with relationships among the organizational units responsible for carrying out the development work.

A potentially even more promising future direction is to develop a better understanding of how software architects make design decisions, particularly pertaining to technical and work dependencies. Software architects rarely make design decisions under ideal conditions. In fact, software architects constantly face a collection of nontechnical as well as technical constraints. Therefore, making trade-offs is an integral part of the decision-making process of software architects.

Examples of the forces software architects have to consider when making decisions include:

Software architects tend to develop their own heuristics and evaluation approaches. To date, only a limited set of guidelines exist, derived from research work at Siemens [Sangwan et al. 2006], Philips [Kommeren and Parviainen 2007], and Motorola [Battin et al. 2001]. However, there is a growing interest among researchers and practitioners in developing a systematic way of evaluating software architectures and changes to them, a way that considers technical and organizational constraints, particularly in the context of large-scale distributed development projects.

As discussed earlier, researchers have paid a great deal of attention to communication, awareness, and coordination tools for software development. Recent empirical studies have demonstrated the value of such tools in small work teams [Sarma et al. 2008]. Despite these positive results, the empirical evaluations of awareness tools have been performed only in small teams.

Current collaborative tools do not provide satisfactory support for larger teams or large-scale projects. In such settings, the complex web of technical and work dependencies creates awareness mechanisms that provide overwhelming amounts of information, diminishing the potential benefits of coordination. The issues of scalability and information overload highlight an important limitation of current collaborative environments. Traditionally, the central premise of awareness tools is to capture coordination information of a distributed team or project. However, presenting all the available coordination-related information is not the appropriate approach, especially if the information is not actionable.

There are two important dimensions of actionable information: relevance and timeliness. Evidence suggests that developers create informal practices that tend to “follow the dependencies” to self-coordinate based on their knowledge of dependencies in the code, in order to minimize the impact of their efforts on others and vice versa. For example, developers have been known to email specific developers in a team before a check-in to warn them of impending changes and potential conflicts.

However, we know that automating email notifications for every check tends to result in information overload, and at that point developers start to ignore the notifications. Awareness information is far more useful when it is directed only to users who will be affected by a particular change. Moreover, information needs are dynamic, so in addition to identifying the right people, coordination information should be delivered at the right time. Information needs change as the context of the developer’s task changes.

In the future, we expect to see a new generation of tools that manage scale and information overload by combining new analytical and visualization techniques in a more social context, mimicking current social computing environments. Then we could expect to see new tools that apply social networking approaches to the many collaborative tools proposed by researchers and to commercial products, such as IBM Rational Team Concert, to identify particular organizational boundaries (e.g., departmental units or projects) and provide special support for such coordination barriers.

Research on software processes shares several commonalities with research on socio-technical congruence, since an important aspect of software processes is the examination and management of relationships among the development organization’s members, tools, and the product. Ongoing research efforts in the process community are focused on developing a better understanding of the issues of cross-enterprise collaboration and coordination, suggesting a move towards a socio-technical perspective.

Frameworks such as socio-technical congruence [Cataldo et al. 2006] [Cataldo et al. 2008] could be very useful in evaluating the coordination capabilities that a particular set of software processes offer for a development organization that has multiple actors or roles (e.g., a change management process) across multiple organizational units under varying levels of uncertainty. Such a novel approach would complement the traditional process modeling approaches used to design, simulate, and evaluate software processes.

Some of the open research questions to be addressed include the development of mechanisms for utilizing socio-technical measures to improve software design and development by combining novel processes and tools, as well as understanding how processes, personal interaction, and collaborative tools complement each other to improve coordination.