Friday 10 September 2004 — This is 20 years old. Be careful.
I was talking to a very interesting software architect the other day, and we were discussing a layer he had built on top of .NET. I asked if the .NET framework didn’t already do whatever it was he was trying to do. He said,
An architect’s job is to build the framework on top of the framework.
On one level, this sounds like re-inventing the wheel. But I really agree with it. In fact, it neatly encapsulates something I’ve been trying to understand for a long time. I’ve worked with people who were nominally architects, but didn’t feel to me like they were “doing architecture”. I couldn’t put my finger on what was missing.
But now I think I see it: those non-architects weren’t thinking in terms of building frameworks. I don’t mean “framework” here as “a packaged API that will be offered to people you haven’t met”. Most software is not shipped as a framework. But many private layers that no-one will ever see should be designed as if they were public frameworks. The framework mind set forces you to clearly define semantics, isolate modules from each other, and prepare for change.
The non-architect architects I’ve worked with had many good skills. They were masters of many technologies, they learned quickly, they could work at many levels of the system, they could write a lot of code, they could mentor others, they cared about the quality of the product, and so on. But they were lacking the essential framework mentality, and it showed.
Comments
I guess I'd disagree a little bit. In my opinion, as an architect, the architect's job is to define the framework...period. It's still architecture if the framework is being defined on top of a random mess of third-party parts instead of a coherent lower-level framework. Also, it is not the architect's job to build the framework. Yes, I firmly believe that architects must remain firmly grounded in reality (I've spent too much of my career cursing architects whose heads were in the clouds) and should be involved enough with the implementation to keep that edge, but if they're spending too much of their time on implementation then they're not spending enough time doing an architect's job. Looking forward and making sure the pieces fit and doing all of the other big-picture stuff so that developers don't get bitten by things that work separately but don't work together take too much time and energy on too irregular a schedule to put an architect on coding tasks that might become part of the critical path.
What they should have done is 'give them what they need not what we might want'. There were certain fundamental things that should have been in the constructors (C++. RAII and all that), but of course they left it up to the user. So you had partially initialised objects.
Quite frankly they should have just created the corporate specific messages and left the rest of the 'initialise queue', 'get message', etc. to us since they made such a hash of it.
Add a comment: