Simon Brown - Software Architecture for Developers

The IT industry is either taking giant leaps ahead or its in deep turmoil. On the one hand were pushing forward, reinventing the way that we build software and striving for craftsmanship at every turn. On the other though, were continually forgetting the good of the past and software teams are still screwing up on an alarmingly regular basis.

Software architecture plays a pivotal role in the delivery of successful software yet its frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the software architecture role exists on even the most agile of teams yet the balance of up front and evolutionary thinking often reflects aspiration rather than reality.

I tend to get one of two responses if I introduce myself as a software architect. Either people think its really cool and want to know more or they give me a look that says I want to talk to somebody that actually writes software, not a box drawing hand-waver. The software architecture role has a bad reputation within the IT industry and its not hard to see where this has come from.

The thought of software architecture conjures up visions of ivory tower architects doing big design up front and handing over huge UML (Unified Modeling Language) models or 200 page Microsoft Word documents to an unsuspecting development team as if they were the second leg of a relay race. And thats assuming the architect actually gets involved in designing software of course. Many people seem to think that creating a Microsoft PowerPoint presentation with a slide containing a big box labelled Enterprise Service Bus is software design. Oh, and we mustnt forget the obligatory narrative about ROI (return on investment) and TCO (total cost of ownership) that will undoubtedly accompany the presentation.

Many organisations have an interesting take on software development as a whole too. For example, theyve seen the potential cost savings that offshoring can bring and therefore see the coding part of the software development process as being something of a commodity. The result tends to be that local developers are pushed into the higher value software architecture jobs with an expectation that all coding will be undertaken by somebody else. In many cases this only exaggerates the disconnect between software architecture and software development, with people often being pushed into a role that they are not prepared for. These same organisations often tend to see software architecture as a rank rather than a role too.

Agile might be over ten years old, but its still the shiny new kid in town and many software teams have aspirations of becoming agile. Agile undoubtedly has a number of benefits but it isnt necessarily the silver bullet that everybody wants you to believe it is. As with everything in the IT industry, theres a large degree of evangelism and hype surrounding it. Start a new software project today and its all about self-organising teams, automated acceptance testing, continuous delivery, retrospectives, Kanban boards, emergent design and a whole host of other buzzwords that youve probably heard of. This is fantastic but often teams tend to throw the baby out with the bath water in their haste to adopt all of these cool practices. Non-functional requirements not sounding cool isnt a reason to neglect them.

Whats all this old-fashioned software architecture stuff anyway? Many software teams seem to think that they dont need software architects, throwing around terms like self-organising team, YAGNI (you arent going to need it), evolutionary architecture and last responsible moment instead. If they do need an architect, theyll probably be on the lookout for an agile architect. Im not entirely sure what this term actually means, but I assume that it has something to do with using post-it notes instead of UML or doing TDD (test-driven development) instead of drawing pictures. That is, assuming they get past the notion of only using a very high level system metaphor and dont use emergent design as an excuse for foolishly hoping for the best.

It also turns out there are a number of people in the industry claiming to be software architects whereas theyre actually doing something else entirely. I can forgive people misrepresenting themselves as an Enterprise Architect when theyre actually doing hands-on software architecture within a large enterprise. The terminology in our industry is often confusing after all.

But what about those people that tend to exaggerate the truth about the role they play on software teams? Such irresponsible architects are usually tasked with being the technical leader yet fail to cover the basics. Ive seen public facing websites go into a user acceptance testing environment with a number of basic security problems, a lack of basic performance testing, basic functionality problems, broken hyperlinks and a complete lack of documentation. And that was just my external view of the software, who knows what the code looked like. If youre undertaking the software architecture role and youre delivering stuff like this, youre doing it wrong. This isnt software architecture, its also foolishly hoping for the best.

Admittedly not all software teams are like this but what Ive presented here isnt a straw man either. Unfortunately many organisations do actually work this way so the reputation that software architecture has shouldnt come as any surprise.

If we really do want to succeed as an industry, we need to get over our fascination with shiny new things and starting asking some questions. Does agile need architecture or does architecture actually need agile? Have we forgotten more about good software design than weve learnt in recent years? Is foolishly hoping for the best sufficient for the demanding software systems were building today? Does any of this matter if were not fostering the software architects of tomorrow? How do we move from frustration to serenity?