Simon lives in Jersey (Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon regularly speaks at international software development conferences and provides consulting/training to software teams at organisations across Europe, ranging from small startups through to global blue chip companies. He is the founder of "Coding the Architecture" (a website about pragmatic, hands-on software architecture) and the author of "Software Architecture for Developers" (an e-book that is being published incrementally through Leanpub). He still likes to write code too, primarily in .NET and Java. Simon is a DZone MVB and is not an employee of DZone and has posted 33 posts at DZone. You can read more from them at their website. View Full User Profile

The frustrated architect

03.26.2012
| 8744 views |
  • submit to reddit

Giant leaps or deep turmoil?

The IT industry is either taking giant leaps ahead or it's in deep turmoil. On the one hand we're pushing forward, reinventing the way that we build software and striving for craftsmanship at every turn. On the other though, we're 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 it's 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.

Software architecture has a bad reputation

I tend to get one of two responses if I introduce myself as a software architect. Either people think it's 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 it's 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 models or 200 page Microsoft Word documents to an unsuspecting development team as if they were the second leg of a relay race. And that's 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 mustn't forget the obligatory narrative about "ROI" and "TCO" that will undoubtedly accompany the presentation.

Many organisations have an interesting take on software development as a whole too. For example, they've 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 design and software development, with people often being pushed into a role that they are not prepared for. These same organisations tend to see software architecture as a rank rather than a *role*.

Agile aspirations

Agile might be over ten years old, but it's 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 isn't necessarily the silver bullet that everybody wants you to believe it is. As with everything in the IT industry, there's a large degree of evangelism and hype surrounding it. Start a new software project today and it's all about self-organising teams, automated acceptance testing, continuous delivery, retrospectives, Kanban boards, emergent design and a whole host of other buzzwords that you've 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 isn't a reason to neglect them.

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

So you think you're an architect?

It also turns out there are a number of people in the industry claiming to be software architects whereas they're actually doing something else entirely. I can forgive people misrepresenting themselves as an "Enterprise Architect" when they're 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. I've 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 you're undertaking the software architecture role and you're delivering stuff like this, you're doing it wrong. This *isn't* software architecture, it's also foolishly hoping for the best.

From frustration and beyond

Admittedly not all software teams are like this but what I've presented here isn't a "straw man" either. Unfortunately many organisations do actually work this way so the reputation that software architecture has shouldn't 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 we've learnt in recent years? Is foolishly hoping for the best sufficient for the demanding software systems we're building today? Does any of this matter if we're not fostering the software architects of tomorrow? How do we move from frustration to serenity?

If this strikes a chord and your view of software architecture is more like the role we discussed at QCon London, you can view the slides and video from my "The Frustrated Architect" talk, which I'll be repeating at the DevWeek conference in London on the 29th of March. My book also has some answers. ;-)

Published at DZone with permission of Simon Brown, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jonathan Fisher replied on Mon, 2012/03/26 - 9:22am

Software Architects have a bad name because there are too many that treated their position like a dictatorship. Sure, someone has to steer the ship, but everyone on board has ideas. I've dealt with some of the worse dictatorship regimes, who moan endlessly about standards (as opposed to best practices), compliance (instead of innovation), and then have the nerve to get upset when you don't invite them to your design meetings. These teams should be called "Architecture Teams" they should simply be called "The team that says No."

 

As a software architect, try to be the team that says yes. Direct the organization: spend time doing the important things like modeling, instead of wasting time on things like building internal frameworks. Jump in on projects that are behind, and bust your @$$ to help mentor junior developers. Only a fraction of your time should be spent enforcing standards. The majority of your time should be facilitating _other people's_ ideas.

/Rant about other architects from an architect

Dapeng Liu replied on Mon, 2012/03/26 - 12:10pm

6 years ago I joined this industry when my mind was codes, codes and more codes

today it becomes not only codes but also developers

I think as a software architect / tech lead, it is more important to enable the developers to come up with the solution than to do it all by yourself

the old Chinese saying goes like "don't give him fish, teach him fishing"

Yaron Levy replied on Sun, 2012/06/10 - 10:16am

I think the problem is that you're divorcing the management chain from the actual task. The lead architect in a civil project is the de facto manager. Not in the sense of coordinating vacation days, but in the sense of being responsible for WHAT work is to be done, and overseeing any potential problems, and overcoming any unforeseen challenges. So in those terms, he's the lead project manager architect with agile expectations. You're right, there is no silver bullet, but at my company, the management chain is integrated into the development chain such that they understand the technology, and are supposedly able to adjust to unforeseen disruptions to the project development. However, because of that, they suffer in the traditional sense of management, leading to a disconnect with employee needs, but those things aren't as difficult, and don't require "agile management". As is, I respect the development environment, even if I disagree with some of their basic management philosophies.

Jaffa Wify replied on Thu, 2012/07/05 - 6:17am

The architect hired by a client is responsible for creating a design concept that meets the requirements of that client and provides a facility suitable to the required use. Thanks a lot. Regards, write my thesis

Jaffa Wify replied on Tue, 2012/07/10 - 5:27am

In many ancient civilizations, such as that of Egypt and Mesopotamia, architecture and urbanism reflected the constant engagement with the divine and the supernatural, and many ancient cultures resorted to monumentality in architecture to represent symbolically the political power of the ruler, the ruling elite, or the state itself. Thanks a lot. Regards, Homes for sale Mesa AZ

Jaffa Wify replied on Sat, 2012/07/21 - 5:03am in response to: Jaffa Wify

Call the police to report domestic violence charges and initiate the prosecution process. Many states have mandatory arrest policies in effect, meaning that if you call to report domestic abuse, they're forced to make an arrest and bring charges on your behalf. Thanks for sharing. Regards, toronto lofts for sale

Tony Stark replied on Sun, 2012/08/26 - 11:20pm in response to: Jonathan Fisher

I software testers, and I know a lot about software and product quality. in his article, the author raised is really very important and relevant questions. and this is important as it is for software developers and for all users.
admission requirements for mit undergraduate

Kamran Shafqat replied on Sat, 2013/06/08 - 1:05am in response to: Jonathan Fisher

Call the police to report domestic violence charges and initiate the prosecution process. Many states have mandatory arrest policies in effect, meaning that if you call to report domestic abuse, they're forced to make an arrest and bring charges on your behalf. Thanks for sharing. Regards

 

<a href="http://yemle.biz/">Share It</a>

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.