Many important challenges faced by a software architect for a large company have as much to do with the organization as technology. In a recent blog entry, Dan Greenblog drew parallels between the principals behind software architecture and effective organizational structures in an attempt to answer the following quesiton:
How is a company structured like a piece of software, and what best practices can be shared between the design of both?
The author admittedly approaches the subject from a specific, context influenced viewpoint with a technical orientation, all of which makes this article more, not less, useful for software architects. Here is his thesis statement:
A well organized company, like well architected software, is divided up into a modular set of functional components, all of which are allocated discrete, well-documented roles defined before they are built, all of which can communicate with one another using a universal and mutually agreed-upon protocol, and finally, all of which are constantly being monitored, maintained, upgraded, and, if necessary, refactored or phased out.
At first glance it might occur to the reader that they could only wish their organization was as well defined and efficient as that description. But the comparison exercise is really helpful because it takes an intimidating topic for most software architects - organizational management - and brings light to the fact that architects already have a lot of tools in their tool belt to help them do this well. Going into his four major points, Greenblog starts with modularity:
Modularization is perhaps the most important characteristic a corporation or piece of software can have. Each node, be it a software module or team of employees, has a mandate to perform a very specific task in the context of a greater whole; when all nodes are working in concert with one another, the entity as a whole works.
He then goes into Design by Contract principles, and requirements management:
In software development, the programmer writes pre- and postconditions in order to establish the role of a particular software component. With these boundaries well defined at design-time, the programmer is less likely to try to sneak additional functionality into code that was never meant to accommodate it. The same holds true in an organization. If the mandate of a team is well defined and appropriately suited to the skillset of the members of that team, then the team will likely perform well. If the team’s mandate changes, then some examination is in order to make sure that it can still perform its duties appropriately under the new definition.
And of course messaging patterns are also covered:
By mapping out the communication paradigm before a single line of code is written and keeping consistent throughout the whole application, the programmer saves him- or herself the trouble of inventing a new set of messages each time an additional module is added.
The notion of communication here applies both between modules, or teams, which may constantly interact with each other and require well-defined APIs for interaction, and for more asynchronous, interrupt-driven messages, which may better be handled by an event-based notification system.
And then he gets to the hard but true comments about the need to refactor both software and organizations:
A company, or a piece of software, is subject to the same rules of survival as any living entity: adapt or become extinct. In a market which is in constant flux, the only way to stay on top is to avoid stagnation and embrace change.
Perhaps if software architects in large organizations could cast a broader scope net during solution architecture development to include organizational change management engineering by using the same principals they are using on the software side, then the overall system (of both applications and users) could achieve a higher level of success.