« The reason PHP is more popular than Java: it's safer | Main | It's called software for a reason »

EMEA Architects Journal 2: less architecture, more practice

It is impossible to design a system so perfect that no one needs to be good - T.S. Eliot

I liked the first issue of the Journal. I liked the second one less. What bothered me is the lack of focus on implementation or engineering and almost total emphasis on abstract architecture. How do I execute? What do I build?

chaplin Over half the issue was dedicated to SOA, but I'm still none the wiser above what I already knew myself from building in that style. There's nothing to indicate how one would can create an SOA system. Perhaps it's just that my notion of proper automation and care in software is not informed by building houses, factory production, engineering bridges, or questionable abstractions. I believe the EMEA Journal has sound goals - make systems more valuable to business, perform a leadership role on Windows platforms; but the publication should consider mixing up some balance in its articles. Any one or two of these articles would be fine, but not all five. After five, the good ideas become vapourware.

lang Pat Helland's Metropolis is featured in the Journal and is the best of the bunch. This is a remarkable opus. I think it's probably the ultimate expression of software as Building, as the construction of an Architecture. It's the last word on the matter - you will not find a better essay on the subject. There are strong economic pressures to go and think this way. It's comforting to think that we are reaching some kind of critical inflection point of commodization, productization (perhaps most accurately, Walmartization) of software, when society and industry has spent and is spending such frightening amounts of capital on software. Nonetheless, to me the city is not a good metaphor for software, and never has been. Writing software has not felt like designing and building a house. Using software is not like using a house - a program is not a habitat. Changing software is not like demolition (if it is, you're in trouble). I've built houses, I've built SOAs, and the processes have nothing much to do with each other as far as I can see. The problems in software are down to complexity, expediency in engineeering and duplication much more than insufficient architecture. We can call making and thinking about software systems building and architecture if we want, but that's as far as it goes. I like organic and growth metaphors over physical construction or industrial ones - they ring true to me.

gehry And yes, my business title is Technical Architect. But lets be careful about aggrandizing ourselves with direct comparisons to Architects in other disciplines. We are not architects or engineers like those folks are - they have a richer deeper background to draw from. The likes of Marcus Vitruvius, Bruneschelli or Thomas Slade don't exist in software. But - it doesn't matter what your process, technical and architectural leanings are. At some point, if you want a system that will do useful work and grow with your needs, you will need to find competent people to write the code.

That is kind of of material I would like to see mixed into the next issues of the Journal.

April 21, 2004 05:18 PM


Trackback Pings

TrackBack URL for this entry: