Social Accounting
Shapiro's thought processes mirror the thinking on social force accounting of Rajesh Uttangi, who in 2004 prepared a white paper called Social Dimensions to Architecting Software Systems for Project Perfect. In his paper, Uttangi, a specialist with the Rational Competency focus group, Talent Transformation, Wipro Technologies, writes:
Alistair Cockburn in a paper titled On the Interaction of Social Issues and Software Architecture says "It has long been said, 'Architecture follows Organization' and 'Organization follows Architecture' . . . Architects do not like being told their clean design is a result of accounting for social forces. Project managers do not use their knowledge of social issues to influence architecture. Yet it is clear that social issues affect the software architecture in ways that the good architect takes into account."
Throughout the development cycle, architecture involves many aspects - business strategy, technical infrastructure, competitiveness, data and above all, delivering value to the stakeholders like the users, developers, managers and the architecture team itself. While the interests of the user community are well understood and religiously protected, the other stakeholders don't find so much support from the architecture. Because still they are expected to work for realizing the architecture and not use it as a tool to come up with a good system, bringing their own expertise to bear.
In complex systems, no one person covers the full breadth of technical expertise required to properly inform the architectural decisions, and lend credibility to the architecture, he notes. That suggests the need for a system definition that can represent the interests of different organizations. The architects on the team represent knowledge of the products of their organizational group (project, division and so on) as well as the relative priorities of their system requirements (organizational goals, and product functionality and qualities). Architects cannot exist and work in isolation from the rest of the organization.
But frequently the challenge for the architecture team is not to create an architecture that is "as if of one mind" - that is, having the quality of integrity - but to create one at all. Many times it is even difficult to be able to orchestrate the minimal conditions required to complete the job. The reasons for settling for such a substandard work product are the difficulties on the social front - being able to sell the "vision" to the team, acceptable distribution of roles and responsibilities, common levels of understanding about what is to be done, timely communication and separation of concerns, et cetera. The trickiest ones are common understanding and communication.
Philippe Kruchten says that "the practice of architecture is a long and rapid succession of sub-optimal decisions, mostly made in partial light". Architecture projects are, by their very nature, ventures into uncharted territory and especially fraught with competing ideas on which direction to take. Without obtaining a consensus and solid leadership, indecision is like[ly] to reign.
While there is hardly any need to highlight the technical issues associated with architecture, the social aspects that continue to have ever-increasing influence cannot be ignored, Uttangi asserts. There is no doubt that there are team members who feel used, left out or ill-treated in almost all projects, particularly when the question of their involvement in the system's architecture comes.
"The problems are exacerbated by ever-growing size of teams, integration of cultures and faster turnover rates, increasing complexity and cross-technology interoperability concerns. If issues of stakeholder involvement, assimilation of ideas, recognizing contributions and mutual support issues are systematically, yet informally addressed, results can be pleasantly surprising," Uttangi states in his conclusion.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.