Someone recently on LinkedIn asked what it would take for a developer to be promoted to an architect. My pithy response was, “is that a promotion?”
Where and when did the term ‘architecture’ inveigle itself into software development? IIRC, when I began my career as a programmer over 25 years ago, the term was absent. If we think about someone from 2021 turning up in 1995 and talking about ‘architecture’, I envision scenes from a Connecticut Yankee, or perhaps the hapless priest from Eric the Viking babbling about Christianity to the pagan Norse. Simply put, the vocabulary of software development didn’t include the word ‘architecture’. In fact, even ‘application’ was a stretch. More often than not, what software development produced were ‘systems’, perhaps reflecting some with the utilitarian aesthetic of a caravan site that operated with relentless consistency.
I’m not going to bother digging through the strata of software development archaeology to work out precisely when we switched from ‘designing systems’ to ‘architecting applications’, suffice to say it may have something to do with the Zachman, etc. work that was done in the US following the realisation that software development was not like other technical disciplines in that it was very unpredictable in terms of outcomes, had a very short history with little in the way of stable and proven methods, and was soaking up increasingly larger amounts of money for what were mediocre results at best. Plus ça change.
To digress for a moment, real architecture is a widely practised discipline with strict requirements on practitioners and a history of methods and techniques stretching over millennia. Generally an architect is an architect, basically the training is the same with some specialisation in the profession for a given set of application domains, e.g. commercial, residential, but the fundamentals are the same.
In real architecture we don’t see the proliferation of (perceived) specialisations that have mushroomed in software development. We don’t see ‘wall architects’ or ‘blueprint architects’ or ‘plumbing architects’
Here’s a probably incomplete list of architecture specialisations within contemporary IT:
- Enterprise;
- Solution;
- Technical;
- Infrastructure;
- Data;
- Security;
- Domain (no idea, it was on Seek);
- Business;
- Innovation (??? again, on Seek)
- Programme
- Cloud
- Platform
- Integration
This is obviously bordering on the ridiculous but it is does show a degree of imagination that most real architects would be proud of. Imagine, if you will, that there was a similar division of labour across all the elements of real architecture? Chaos would ensue as architects swarmed over building sites each clutching a tightly focussed and largely context free design.
Recently I was given the job of assisting the lead developer of a midsized system with the development of a solution architecture. I sent him a message and asked him to set up a meeting. An invitation for a half hour meeting appeared. Turns out the system has been under development for over a year so the developer was less than enthusiastic about an architectural beard (or chin for the clean shaven) stroking exercise than he was about delivering. The reason for the architecture was so that it could be presented to the architecture governance board (beards/chins aplenty to be stroked there) for review and approval. The meeting lasted 20 minutes and needless to say I was left with the impression that interest was low and my involvement post-application development was less than welcome.
It is my view that the practise of building software is too malleable, too plastic to lend itself to the hard edge of the draftsman’s ruler. Indeed, that plasticity is probably its single greatest benefit and, at the same time, its biggest pitfall. Architecture as practised in software development today is often superfluous and largely overlooked when it comes to the actual implementation. By overlooked I don’t mean not done, it’s just not something that most developers have a great deal of regard for.
Looking at the last 20 odd years, the biggest paradigm shift has been from waterfall to iterative development, the Unified Process being the common ancestor for contemporary iterative development methods. This shift really meant having the whole SDLC align with what the developers had always done which is to exploit the plastic nature of software development, encapsulated in the mantra: fail fast and fail early or more traditionally: if at first you don’t succeed …. Of course this approach doesn’t scale well and there is a strong argument for restricting iterative approaches to the build/test phase.
It seems to me that the assuming, in some cases mandating, architecture as a precursor to designing and building any application is a regressive step back into the world of pure waterfall, relying as it does on assumptions and limited by ‘known and unknown unknowns’ in the Rumsfeldian sense. At best, architecture should be just enough to give some foundational guidance to the development process and an order of magnitude estimate that has a reasonable level of confidence (> 70%).
The time and effort spent on architecture as a standalone activity within the SDLC would be better spent on improving the leadership of software development teams, with a closer focus on team dynamics, and the management of collaboration within a development team. A greater focus on people skills combined with a confident technical rapport is worth any number of lines and boxes in whatever diagramming language happens to be in vogue. At the same time the leadership should be alive to the landscape outside of the team and working to mitigate disruptive forces. Agile goes some way towards this, however it has become faddish and the fundamentally drifted into the IT consulting trap of being offered as the panacea for the shamefully low success rate that is endemic to software development. Much the same could be said of software architecture in its multifarious manifestations.
About the Author
Patrick Brosnan is a 25 year IT veteran. He trained as a programmer during the golden age of Object Oriented programming in the late 1990s. Since then he has designed enterprise level systems and lead the software development teams that have implemented them. Patrick takes a pragmatic approach to architecture which is based on the idea that the architecture activity should be just enough to provide confidence in the solution and anchor the development effort. He tries to avoid saying that things were better 20 years ago.
