Has Conventional Software Architecture Become Obsolete?

keith — Wed, 01 Nov 2006 17:31:00 GMT

For as long as I have been in this industry, the architecture space has been one of the sexier areas within which one can operate. Six figure salaries, prominent roles on large projects and long lunches with c-level management are rewards that most of us aspire to attain at some point in our careers. Successful architects can enjoy rock-star levels of popularity within the software community by sharing big ideas and the lessons they have learned from years of experience.

Unfortunately for those of us in the trenches, successful implementation of these big ideas can be much more difficult to achieve than we are lead to believe. What may initially seem like a clean, elegant solution can quickly become an engineering nightmare as new requirements surface and unanticipated complexity is forced into our designs. Budget blowouts, missed deadlines and broken promises have seen a growing tide of cynicism and resentment directed towards the architecture community.

Increasingly people are questioning the value of software architects and the artefacts they produce. The "thought leaders" of our community are frequently accused of being disconnected from reality, providing esoteric solutions that look great in PowerPoint but are either too convoluted or too simplistic to work in the real world. Ted Neward sums up the current climate of discontent rather well in his new MSDN column where he highlights some of the more common attitudes towards architecture and poses the question:

"Are we [architects] nearing extinction? Or does architecture - and the architect - still serve a useful purpose?"

Before I put in my two cents on the topic, in the interest of full disclosure I would like to point out that I am not an architect. I'm one of those guys in the trenches - a developer / consultant. However I like to think that I have participated in enough strategy workshops, authored my fair share of architecture specifications and learned enough lessons the hard way to offer a balanced perspective on the topic.

I am a firm believer that architectural guidance is a fundamental requirement for the success of any non-trivial software project, but acknowledge that this guidance need not necessarily be delivered by someone who is considered an "architect". The theme of Ted's column, "Pragmatic Architecture" resonates strongly with me. It is essential that both architectural guidance and the mechanism by which it is delivered are approached in an equally pragmatic manner.

On projects that are moderate in scope, involving smaller, agile teams, an implicit approach to the delivery of architectural guidance may be the most effective mechanism. By this I mean that the more clued up members of the development team call on their knowledge and experience to define the architecture early on and ensure that the solution maintains architectural integrity throughout the duration of the project. Under the right circumstances this approach can be extremely effective as when the architecture is the responsibility of those charged with implementation it is often highly pragmatic.

Caution should be taken as this approach can be destined to fail under the wrong conditions. If developers on the team lack the knowledge and experience to make the correct architectural decisions, a fundamentally flawed architecture may initially be defined and deteriorate into an expensive, unwieldy mess as the project progresses. Under circumstances like these, success may require an architect to spell out the architecture in detail up front and mentor the development team (or team lead) throughout the project lifecycle to ensure its integrity is not compromised.

The conventional, explicit approach to the delivery of architectural guidance can be a necessity on larger projects. It is often not possible for any individual or team to have the breadth of knowledge required to make informed architectural decisions without abstracting away the lower level details. There may simply be too many functional areas, software components, business entities and cross cutting concerns to consider. Utilisation of an architect or team of architects may be essential in these circumstances to ensure the right decisions are made.

In some situations, members of the development team may know the business inside out and have the knowledge required to define a technically flawless architecture but this may not be enough to ensure a successful implementation. Senior management are often the ones responsible for the decisions that can make or break a project and members of the development team may have the 'clout' to sell directors and c-level management on the merits of what could be the best (or only achievable) path forward. Architects typically enjoy a closer relationship with upper management and can have the 'pull' required to sell an idea, get a proposal signed off or help secure funding approval for a project.

The notion that software architecture / architects are now suddenly irrelevant is an absurd generalisation that shows a lack of perspective and forethought. It is this kind of dogmatic thinking that leads to the "silver bullet" mentality that all too often can saddle fundamentally sound concepts such as service oriented architecture with the stigma of blown budgets, missed deadlines and broken promises. Architects don't kill software projects - an absence of pragmatism however can, and usually will.

kn1ght : Architecture, Jibba Jabba

Has Conventional Software Architecture Become Obsolete?