The natural progression of a system will lead it to fill the confines of the structure it is contained in.
Therefore, the first act in architecting a system is defining the structure that contains it.
When a system exists in opposition to its containing structure, this is a problem; the result will be the destruction of the system, container, or both.
Last week I reviewed the design of two different systems. At a high level they both accomplished the same goal, but nonetheless their designs differed.
The first was developed by a single team; it had no clear security, data, or communication boundaries within its implementation. The second, developed by two teams, was composed of two distinct and loosely coupled services which communicated with each other through a single externally developed service.
Their architectures mirrored the developing team’s organizational structure; their designs influenced more by the organization in which they existed, than the problem they solved.
The scenario above is not unique, and has been observed in software for decades (see: Conway’s law.) Yet we rarely expect leadership; the people who dictate an organizations structure, to have the technical ability to architect the systems developed under them.
If you want to improve the design of the systems in your organization, you better invest in making your architects into managers, or your into managers into architects.