Thoughts on Software Architecture and Enterprise Structure

Many significant challenges faced by a software architect for a large enterprise have as much to do with the organization as the technology. In a recent blog entry, Dan Greenblog drew parallels between software architecture principles and effective organizational structures in an attempt to answer the following question:

How is a business structured like software, and what best practices can be shared between the design of the two?

The author certainly approaches the topic from a specific perspective, influenced by the context with a technical orientation, which makes this article more, not less, useful for software architects. Here is his thesis statement:

A well-organized enterprise, like well-architected software, is divided into a modular set of functional components, which are assigned discrete and well-documented roles defined before they are built, all of which can communicate with each other using a universal system and mutually agreed protocol, and finally, which are constantly monitored, maintained, upgraded and, if necessary, refactored or removed.

At first glance, the reader might think that he can only wish his organization was as well-defined and efficient as this description. But the comparison exercise is really useful because it tackles a daunting subject for most software architects – organizational management – and highlights the fact that architects already have plenty of tools in their tool belt to help them do this well. Going into its four major points, Greenblog starts with modularity:

Modularization is perhaps the most important feature any business or software can have. Each node, whether a software module or a team of employees, is mandated to perform a specific task within the context of a larger whole; when all the nodes work in concert with each other, the entity as a whole works.

It then discusses the principles of design by contract and requirements management:

In software development, the programmer writes preconditions 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 introduce additional functionality into code that was never intended to incorporate them. The same is true in an organization. If a team’s mandate is well-defined and suited to the skills of that team’s members, the team is likely to perform well. If the team’s mandate changes, a review is necessary to ensure that it can still perform its functions appropriately under the new definition.

And of course, email templates are also covered:

By mapping the communication paradigm before a single line of code is written and remaining consistent throughout the application, the programmer saves the trouble of inventing a new set of messages each time an additional module is added.

The notion of communication applies here 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 can be better handled by event-based notification. system.

And then it comes to the harsh but true comments about the need to refactor both software and organizations:

A company, or software, is subject to the same rules of survival as any living entity: adapt or die. In an ever-changing market, the only way to stay on top is to avoid stagnation and embrace change.

Perhaps if software architects in large organizations could broaden their scope when developing solution architecture to include organizational change management engineering using the same principles they use on the software side, then the overall system (of applications and users) could achieve a higher level of success.