Organizational Savvy: The Missing Piece in Software Architecture Education
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The field of building architecture as a professional discipline evolved from a variety of backgrounds and skills. As Mary Woods explains in her book From Craft to Profession: The Practice of Architecture in Nineteenth-Century America (University of California Press, 1999), the progenitors of the architecture profession included those for whom architecture was a suitable artistic profession for a European gentleman—to master craftsmen and artisans, such as carpenters, masons, and draftsmen. However, one characteristic that was shared among these early architects was a need for organizational skill to be successful. Efforts to characterize the discipline gave architects an important role as an intermediary between the builders and the clients. Architects fought to have a role in the oversight of the construction of the buildings they designed. When architects failed to grasp the importance of managing these relationships, projects ran over budget, clients were dissatisfied, and occasionally buildings were unsafe. Today, even as the field of architecture now incorporates aspects of disciplines such as chemistry and physics (as well as new software-driven tools), organizational skills remain an important part of a building architect's toolkit.
The field of software architecture is at a stage of development similar to that of building architecture in the nineteenth century. Today, more and more software professionals assume the role and title of software architect. Some of these people have a background of programming and software engineering. Others have a background in modeling. Still others end up in the field with a background in systems engineering. All of these disciplines bring a variety of different elements to the discipline of software architecture. Like building architects, software architects need to draw on a broad range of disciplines to be effective, and like their earlier namesakes, organizational savvy is also an important part of this skill set.
Unfortunately, the one area that is often missing from software architects' repertoires is an understanding of the importance of organizational behavior. Often, what determines the success of a software architecture is not technology, but the behavior of the organizations building and using the architecture. This is especially important because a successful architecture usually requires participation from many different groups—from across many different organizational boundaries. However, unlike many of the other tools in a software architect's repertoire—such as programming, modeling, and systems engineering—few, if any, software architects come to the profession with experience in the discipline of organizational behavior. Fewer still acquire this sort of training in preparation for their work as software architects. Software architects' toolkits are not complete unless they have an understanding of the kinds of organizational issues they'll face and how to address them.
Satisfying the demands of a software architecture requires coordination of many different systems and organizations. A typical e-commerce transaction, for example, will traverse the systems of many organizations, leveraging shared platforms such as the Internet, client browsers, Web servers, business logic components, security systems, and back-end databases. Additional organizations are involved in developing these systems, and even more groups may be involved with inventory, fulfillment, customer support, and marketing. In this environment, software architecture is essential for coordinating these systems and organizations. There are many different exchanges and interfaces that need to work together. To be effective, the partners must not only agree on the interfaces, they must also agree on when and how to use them. Teams within these groups must also be kept in sync. If these organizations are not aligned, partners may fail to deliver key components or withdraw from the effort, causing the initiative to fail. This would cause pain for developers and customers, as well as their managers and sponsors, and of course the architects. Understanding the motivations and interests of these organizations and the stakeholders in them is essential for selecting partners and maintaining their participation. It is also crucial for the architecture to be adopted by the partners, and for the partners to be satisfied by it.
We can draw two lessons from this history. First, we should recognize the importance of organizational concerns to the work of individual software architects. Those with a key stake in the success of software architecture should give consideration to these organizational issues in making specific decisions, as well as in their own professional development. Second, from an institutional perspective, as more universities offer coursework in software architecture, certifications for software architecture develop, and professional societies for software architecture form, we should question whether these efforts are complete without including knowledge of organizational concerns.