Thoughts On Software Architecture and Corporate Structure

Posted by Mark Figley on Jul 23, 2008 06:46 PM

Community

Architecture

Topics

Business Process Management,

Business

Tags

Organizational Patterns

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.

1. Back to top

   Recent blog entry by Dan Greenblog

   Jul 24, 2008 8:42 AM by Matt Davis

   Need to set that link... http://dangreenblatt.com/blog/2008/07/21/thoughts-on-software-architecture-and-corporate-structure/

   Reply

2. Back to top

   RE: Thoughts on Corporate Structure

   Jul 24, 2008 2:44 PM by Sean Bethune

   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.

   I don't disagree that this isn't a noble goal or that there aren't real benefits with this approach, but my belief is that despite every best intention to engineering/architecture to build a better organization that this will never happen. I've been on too many process automation projects that strayed in organizational boundaries and suffered through political and personality issues with the managers/executive team. My humble experience is that corporate organizations are too dynamic and oriented around the personalities and political power agreements to be aligned to an standardized engineering approach. At best, these structured approaches are applicable to autonomous functions of the organization -- which may be where enterprise architecture is headed, but the fastest way to kill a project is to tell an executive to reorganize the department.

   Reply

3. Back to top

   Interesting concept

   Jul 25, 2008 5:51 AM by Andy Skipper

   I'd agree that personalities are a far greater influence on the malleability of corporate structure than Dan's probably allowing for here

   Reply

• Older >