Joerg Plewe's Blog

Programming Archives

My first CVS checkin 2007

C with NetBeans on Linux ... check it out!

µ-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!

This work is licensed under a Creative Commons License.