Warning--high buzzword content in this blog entry might cause headaches. Aspirin, cool water and a whitenoise generator recommended. For best results, do not read on an empty stomach.
I've recently begun a Twin Cities chapter of the International Association of software architects. IASA is a not-for-profit company devoted to advancing the science of software architecture. The Twin Cities chapter will give residents of the Minneapolis and St. Paul area a language-neutral forum for discussing architectural concepts. We're having our first meeing in August, on the 16th. I'm still looking for a flexible and affordable venue, but we've got our speaker lined up and it's sure to be good. I'm just extremely thankful to have a group like IASA, which can offer me a national superstructure for hosting architectural meetings. I've really longed for high-level architectural discussion in the course of the last year, and found a rather sparse community.
Believe it or not, the best friend the architecture community has right now is probably Microsoft corporation--they've been a tireless advocate of advancing architecture as a science and as an art form, and they've been more eager than I would originally have thought to assist my fellow IASA chapters (all of whom to my knowledge have been founded, organized and run by Java User Group leaders). They're actively encouraging me to seek out sponsorship for my local chapter from the J2EE industry, because they know that architecture is a language and platform neutral science (it's been around far longer than .NET or J2EE/J5EE/whatever version Sun's PR goons want to call it. The willingness of Redmond to assist without control and encourage cooperation with Sun, IBM, BEA, SAP, Borland, etc is an advanced indicator to me that Interop and SOA is truly the way of the future. And that means that software architecture as an explicit and well-developed science is also the way of the future.
But so very little is commonly known or understood about software architecture. You can't get a degree in it. You can't really even become certified in it. Sun offers an architect certification, but theirs is really a language and platform biased vision of architecture that doesn't hold its own in the world of legacy interop and the emerging web services market.
Paul Preiss, the President and Founder of IASA, has been coaching me on his views of architecture and I've been noticing a distinct bias against including the concerns of developers and development practices in the architects repertoire. This is strikingly familiar to the bias developers hold toward practitioners of interaction design (and also a little reminiscent of the stratospheric nasal tilt many enterprise developers have shown .NET developers in the past five years). In defense of those developers out there looking to learn more about software architecture, and as an early attempt to make architecture more accessible and less "mystic", I'd like to throw out a few of my own ideas about architecture, and some links to other definitions and resources that people might find helpful.
The separation of development and architectural concerns should be undertaken only for practical reasons--when it is more efficient to have specialists focusing on each role than it is to have developer teams juggle traditional programming/construction and architectural/design responsibilities.
The "Model-2" approach to software development kicked off a trend toward greater isolation and abstraction between roles in development teams. In addition to separating the concerns of interaction designers and software engineers, there have been advances for isolating the administrative and executive concerns from the development process. This might be mere conjecture, but based on my own experience, we might have software engineers to thank for most of these architectural advances--it is possible they've been providing automation hooks and tools to remove themselves from the middle seat. I think that perhaps some underground coalition of long-toothed Unix hackers tired of having its shores invaded by milling throngs of well-meaning but tiresome (savage) artists and executives has finally elected to do something about it.
On the other hand, perhaps we are the savages and have the suits to thank for these new advances. Or (most likely), there's a bit of savage and a bit of savant in each of us.
architecture, in a way, is a way for developers to climb up and see the larger picture. The more you work with different Open Source projects (especially when you're trying to augment, alter or otherwise extend an existing software product), the more you'll gnash your teeth and notice how difficult a poorly thought-out (or even a well planned but strategically dissimilar) architecture can hinder your progress and spoil an otherwise good user experience. For example, the Jakarta Tomcat server has a very specialized architecture that allows it to operate in a standalone environment. This is sort of like an astronaut in a space suit--it's got lifecycle management, onboard dependencies, all the things it needs to operate in the depths of space. But all that luggage might prove a hindrance when trying to embed it in a service-rich environment. For this purpose Jetty is clearly superior--it is well adapted to life in lush surroundings.
This metaphor is working, and metaphor, really, is what software architecture is about, so I'm going to run with it. One could describe an architecture like one describes the evolutionary skeletal adaptations of an animal. The Irish Elk had a very specialized "architecture" in its 13 foot antler crown. Tomcat has a very specialized architecture that allows it to function in the barren environments typically operated by green-skinned n00bs. Both, because of their relative inflexibility (and I'm not by any means trying to cast a shadow on Tomcat--I've warmed to it quite a bit since becoming familiar with OpenEJB) stand to lose out when the environment changes. In the case of the Irish Elk, the weather improved and firebearing bipedals arrived on the scene. In the case of Tomcat, service rich environments and flexible component based architectures could render the "all in one" solution unnecessary. In order to avoid falling into disuse, Tomcat will need to adapt. And development concerns are not what's holding them back. The key lies in architecture.
And this is why developers need to learn about architecture--particularly good developers. There is even cause for them to specialize--the all in one solution might not be well suited to our contemporary technical job markets any more than the Irish Elk was to the woods. The advantage that developers have over self-styled architecture purists is that they know from experience, perhaps on an untrained but intuitive level, how and where the programmatic weaknesses in certain software architectures might lie. But in learning about architecture, they need to abandon the minutiae of flow control and implementations of their software, and begin to concern themselves with the construction of modular but holistic systems, functional organs for a service-oriented world. In this world, executive concerns and Interaction Design play at least as important a role in the delivery of software products as developers.
This morning's ramble is complete for now. I'll continue on this topic (and assemble some links to resources) soon.