Extending Professional Software Architecture

Imagine a time when building architecture meant "sketches" that would vary from one architect to another, one type of building to another.  It must have been quite difficult for the skilled tradesmen to build anything more than individual excellence... to deliver repeatable quality... because the "instructions" they were working from were so wildly different from one situation to the next. In some cases, the blueprints may have been vague, or even inaccurate.  In other cases, they must have been maddeningly specific.

Software Architecture is still at that stage.  We have the UML, thank goodness, but we don't yet have a good, reliable, standard set of 'documents' that we can use to describe an architecture in a consistent way... or do we?

One effort focused on moving Software Architecture to the next level of maturity is the ISO (International Standards Organization), working to create and sustain the RM-ODP (the Reference Model for Open Distributed Processing).  (Actually, the standard comes from a joint effort of three different standards bodies: ISO, IEC and ITU-T).

In May of 2007, the good folks behind the RM-ODP released a set of profiles for UML called UML4ODP.  This is a major move, and one that all architects should take note of.

The RM-ODP is cool because it attempts to describe the "set of models" that can be used to specify a software system.  A good analogy: The RM-ODP tells you what diagrams a set of blueprints should contain.  If you are an architect, and you use the RM-ODP, you can provide a "standard" set of blueprints. 

This is cool, because developers can then receive a standard set of blueprints from the architect.  The goal: to help the Software Development profession rise to a level of 'repeatable' quality. 

Using standard architectural descriptions, we can better estimate the cost of software.  We can encourage specialization on specific components, much as home builders can subcontract electrical wiring to one speciality, and the heating system to another.  We can use agile techniques on some parts of the system, and "spiral-iterative" techniques on others (if that appeals to you). 

We can even begin developing system services that can simply be 'plugged in' to a standardized architectural description (much like a building architect can use a stencil to draw a picture of a bathtub, knowing that it will be the right symbol, and size, regardless of which manufacturer is ultimately chosen to supply the actual tub).  (We are not there yet).

The RM-ODP indicates that a system should be described from five viewpoints: "Enterprise," "Information," "Computational," "Engineering," and "Technology."  

Personally, I don't think that these five viewpoints cover the gamut.  As I dig, I will surface more viewpoints: perhaps two more, from what I can tell now.  Regardless, this is the place to start, and I highly recommend that folks do a little digging on their own, especially if you are more than a few years out of college (like me).

When software architecture does make the move to "profession" from "craft," which side do you want to be standing on?

Comments

• Anonymous
  October 06, 2008
  The (ISO Standard) RM-ODP model is a powerful and well reasoned mechanism for creating Architectural

• Anonymous
  October 08, 2008
  If that was a real question, I'd go with "craft".

• Anonymous
  October 08, 2008
  Hi ET, That's a good thing.  When Building Architecture became a profession, it didn't end the need for plumbers and electricians and other skilled trades.   We will always need the skilled trades.   I'm glad to see that you know where you are comfortable. --- N