Joerg Plewe's Blog

µ-architecture - what's that?

When talking about architecture, people think in terms like 1,2,3,4...n-tier, J2EE, client/server, thin vs. thick client. The pieces put together are Oracle vs. DB2, BEA vs. JBoss, Struts, Swing, JSP, JavaFaces, etc.. This is the big picture! It is obvious that the decisions taken there are extremely important and can loose the battle before it begins. But can they also win the battle?

From my observation, there is a second level of architecture, not less important, which I will call micro-architecture now.
Even in a good, well chosen highlevel architecture, the code written in the teams can be a real mess! Unreadable, unmaintainable, far too many lines of code, inconsistant, many bugs. This happens because not every single team member is a universal genius and too often they have to deal with things they are not-so-good at or are just lacking experience. There are many APIs around to deal with and most of them are complex.

Have you ever seen what happens when a former VisualBasic or MFC coder constructs a Swing GUI? A massacre!!

Maybe GUI is a good example here, because it can be done right and it can do done so miserable. Highlevel architecture defines: we do it in Swing! Period. Well done. Good decision! Now the heterogenous team just starts extending a JFrame, adding JTextFields, JButtons and so on. Half a year later, your whole business logic is distributed over a net of FocusListeners, KeyListeners, AncestorListeners. Zillions of lines of code, an ugly, inconsistant GUI and the whole team totally occupied with just GUI coding and bug fixing.

As you might guess, the µ-architect had been missing! Or he was there, but nobody noticed.

Consider there had been one single experienced Swing guru somewhere in your team. Unrecognized so far. Coming along with a nice little API that separates data from presentation and introduces abstract events (like 'user wants to open something' in favor of 'mousePressed', 'keyPressed', 'focusLost'). He shows a clean path how to apply a simple MVC pattern (I have something in mind like JDNC or JGoodies, just maybe even more focused).
Then this guy is your µ-architect. Listen to him!

GUI is only one example. There are more. A cool way to do logging? Access the database? I18N? They all have in common that they focus on a small aspect of the development process. Nevertheless, the impact can be huge!

Most of the time, µ-architectures are just called APIs. But they are more. Typically, they are coupled with a certain way of coding and/or a development process. If they are good, they can enforce a slim process and high quality of code measured in terms of consistency or few lines of code. They can avoid the necessity to generate huge amounts of code or enforce clean SoC.

µ-architects typically don't have an accentuated position that is known to be architectural in any way. They can be just one member of a coding team. Sometimes, they don't even know - how important they are and what they do. They are code-level architects, artists in some respect, black-belted, experienced code wizards with a good feeling for quality and style. They love to edit well-formatted code, care for the IDE they use, don't like meetings so much.

Do you know who you µ-architects are? Are you sure they are paid good enough? Take care!

Comments

• Nice blog entry Jörg,

  I have found it to be largely a matter of perspective between the two types of architects. I often hear project architects say: The devil is in the details. Typically I hear the µ-architects say the converse: God is in the details. Yet both perspectives are very complimentary, and ultimately necessary, to successfully design robust large applications.

  I have not yet met a person who who is an expert in both viewpoints. I guess it is because they require such very different mindsets.

  John

  Posted by: cajo on November 01, 2004 at 02:43 PM

• Absolutely right!

  What you describe as the micro-architect is exactly the position needed to bridge the gap between software architecture and a solid implementation - and i agree that this position is crucial for the success of a project.

  Fuad
  

  Posted by: fuad_abdallah on November 03, 2004 at 12:19 PM

This work is licensed under a Creative Commons License.