Tuesday, February 5, 2013

Drawing a Line in the Sand

I rarely have trouble sleeping, but when I do it’s over topics like; which is more important, the bow or the arrow? A crayon or a coloring book? A recipe or a stove? Both! Neither! Aaggggggghhhhhhhhhhhhhhhhh!

Each of the above is important, and without their counterpart each becomes important only in an academic sense. Such is the relationship between Architecture and Implementation. Consider the following statements and determine which ones are statements of architecture:

  • A large financial services company sells and exits its mortgage business.
  • Placing an application domain controller in front of a set of clustered web servers.
  • Using MQ Series, with a persistent queue to send messages between applications
  • Maintaining user authentication credentials in an application-specific database.
  • int x := max( a, b );
  • Utilizing an open source framework to provide user experience enhancements including data validation.

As Admiral Ackbar would say, “It’s a trap!” Each of these statements could reasonably be the result of, or the cause of, a conversation of architecture. See the line of programming code above; “int x := max( a, b );” - as low a level as this single Java statement is, there is an inherent architecture to it, and a reasonable architecture debate could ensue.

In any solution design there are more decisions to be made than there are roles or people. Therefore, we have to draw a line at some place to distinguish between the responsibilities of architects, and the responsibilities of developers.

But let’s make sure we don’t confuse “roles” with “importance”. A bow is no more or less important than an arrow. An “architect” is no more or less important than an “implementor.” An architect’s work should precede that of an implementor, but that is a attribute of sequence, not importance.

So which of the above bullets are architecture? They all are, with a caveat. This graphic shows the various sub-disciplines of architecture; Technology, Information, and Business.

We add to this - a designation called, Application Design. Note that even though we have stated all of the bullets above are architecturally significant, we are drawing a line above the design examples. This “line in the sand” illustrates the separation between what we call architecture and that of design. This would represent the distinction between what we would expect of a full-time architect, and the design decisions expected from a Lead Developer.

Full-time architects will be allocated to a specialty such as Technology, Business, and Information. Lead Developers will often span all of these areas as implementers. One additional nuance that makes this separation of responsibilities even more delightful is that workload management and balance will often require that Lead Developers function as architects. That, however, should not muddle the proper distribution of responsibilities. A person with a title of “developer” should not be excluded from using their skills as an architect, assuming sufficient experience. Full-time architects should be leveraged on initiatives where the work-set, demand, and time-requirements call for it.

In summary, there is plenty of important work to go around, yet it is important that we assign appropriate expectations to appropriate skills. Many design options and alternatives are rightfully aligned with Lead Developers, while architectural decisions should be deliverables of full-time architects. Time, demand streams, and priorities may cause individuals to fulfill different roles - that is OK.

Follow by Email