Monday, November 29, 2010

Architecture: How Low Can You Go?

I love sinks because they help me explain how things that are designed really poorly can still be widely successful, lasting through generations of users.   Yep - most sinks are walking architectural disasters; er, make that user interface disasters.  Consider that there are two attributes of running water you need to control; temperature and rate of flow.  Perfect; most sinks come with two knobs.  Which one is temperature?

The poor design of sinks is so pervasive in our society that I typically get people trying to argue why the design is actually good.  It isn’t, and if you had been brought up on the planet Zornak (I’m just saying), you would see it too. 

Let’s just call it an implementation detail.

That, is an interesting topic - at what point do you stop considering an attribute of a solution an architectural element and start thinking of it as an implementation detail.  Where do you draw the line on an IT solution and say above the line is architecture and below it is implementation.

Consider this code snippet:

for ( int x = 1; x<10; x++ ) { array[x] = x }

Which means, create an integer variable ‘x’ and loop through the “array[x] = x” line of code, increasing the value of x by 1 while x is less than 10. 

For the uninitiated, this line of code likely does not perform as a programmer would have intended, unless he or she wanted the first element of the array (the zero-ith element), to have whatever default value the compiler assigns.

Is this an architectural discussion?  An implementation detail?  A Bug?  A clever use of computing resources based on an intimate knowledge of the language (C/, C++, Java, C#, etc..) and compiler? 

Every organization needs to establish a boundary that separates architecture from implementation.  This not only facilitate decisioning, but also responsibility and accountability.  The Architecture / Implementation boundary facilitates the systematic distribution of work, tools, priorities, skills, and training.  It allows for the encapsulation of effort, which seems intuitively elegant in an environment dedicated to developing business services.

Here, we use the Zachman Organizational Model for Enterprise Architecture, and define the Technology Row as the boundary.  Below the Technology Row is implementation; above it is architecture.  In our architecture reviews we do not consider code, IP addresses, or other details when assessing the appropriateness of a proposed architecture.  It’s not that these are unimportant, far from it - they’re just not considered architectural elements.

The Software Engineering Institute says that an architecture largely permits or precludes a system’s quality attributes (such as performance, reliability, security, etc).  Note, that an architecture does not guarantee quality attributes.  A good architecture can yield positive qualities, while a bad architecture yields faucet knobs that must be used carefully or you’ll burn your fingers or splash your tie - two mistakes that never happen on Zornak.

Follow by Email