BT

Thoughts On Software Architecture and Corporate Structure

by Mark Figley on Jul 23, 2008 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Recent blog entry by Dan Greenblog by Matt Davis

RE: Thoughts on Corporate Structure 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.

Interesting concept 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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT