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? 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. The point of SOA is to better manage control and constrain systems, not to pretend they don't need to be built. 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. 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 bad or 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. They are just words - what matters is the connection the words entail. The connection implied by Metropolis is not in my experience. 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. I like organic and growth metaphors over physical construction or industrial ones - they ring true to me. For an alternative view on what it might mean to be a software architect or think about software read Ralph Johnston or Luke Hohmann (or his interviews). For some facts on software process instead of blind faith read Robert Glass. To see what it might be like to live in software garden, rather than a city, read Ward Cunningham, Tim Berners Lee or Pete McBreen. To understand why programming is intimate to design, read Jack Reeves or Kent Beck. To appeciate technical leadership read Joel Spolsky or Martin Fowler. To find out what modern factory systems and supply chains really do and have been doing for the last twenty years read the Poppendiecks. To find out about Service Oriented from people who are instrumental in actually building them subscribe to Don Box or Sean McGrath. That is kind of of material I would like to see mixed into the next issues of the Journal....
Previous Topic
