The frustrated architect

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 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 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. ;-)



Re: The frustrated architect

I was at this when you presented at Skillsmatter, and I get it, it's frustrated. But, what's with the Agile bashing.
What methodologies do you recommend?
Did you know XP could be argued as a minimal implementation of RUP Waterfall has never been a recommended methodology. Since the 70s, it has been considered "risky and invites failure"
What of the values from the Agile manifesto do you disagree with?
What XP practices do you think are bad?

A cargo cult mentality rarely works and this includes Agile... or anything else you want to pick on.

Re: The frustrated architect

This isn't about bashing agile, it's about bashing teams that focus on one thing at the expense of others and those that follow the hype without stepping back and ensuring that it's appropriate for them. It's about doing "just enough" of whatever is required, and that includes software architecture.

Re: The frustrated architect

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.

Re: The frustrated architect

To be honest, I have never understood how Architecture, which includes understanding the overall solution, fits in with Agile projects: Are there still the two distinct phases of Architecture and Development, or are they combined somehow? Do you have any links on the subject? Thanks.

Re: The frustrated architect

Precisely in what you said, "understanding the overall solution", is the answer to your question. A modern software solution evolves constantly, an architect must understand this solution throughout the entire sofware development cycle and take charge of its architecture always. IMO there is no such "Architecture phase", it's present all the time, although sometimes you will dedicate more time to architectural tasks than to plain coding

Re: The frustrated architect

IMO, The role of a software architect should be a career evolution for a developer.

I've seen numerous times where a developer is exceptional at what he does and the company moves the developer into a management position. Huh? How does that work?

Moving from developer to architect should be based on the breadth of knowledge that the developer has achieved over their career. I've also seen kids come out of college and deem themselves as "architects."

I consider these individuals as having "book smarts", but not "street smarts." They've never experienced how to optimize a web server (or code) or refactor existing code into a strategy pattern or even unit test with mocking frameworks...under pressure.

The agile skill set is something I would consider secondary (or even tertiary as this point). As you've stated, "it's still the new shiny kid in town" and if you have that skill set, then you are ahead of curve with some of the other architects.

Nowadays, it seems you need to find a developer who knows how to code. :-)

Re: The frustrated architect

So what exactly does a proper architect do?

Re: The frustrated architect

So what do you consider the role and deliverables of an architect to be? I'm currently staring at a 250 page Word doc I've written describing business processes and required functionality (with screen mockups) for a new system for a client and once that's done and the other after it for another client. Once they're done I might have some spare days to join in with the actual coding. Does that make me an architect or something else - what else should I be doing?

Re: The frustrated architect

In my role as an architect I wouldn't consider writing any 250 page doc a good use of my time - that's too much traditional BA or PM for me. I see my role as coordinating the efforts of others so that they deliver appropriate docs, if necessary, & more importantly ensuring that discussions have taken place so everyone is more or less on the same page. I would also consider high-level design of any proposed system, or changes, to ensure they fit within the enterprise's strategic platform which includes all other software systems under the dept's control. Detailing requirements (different from a project board's functional spec) would only be done within a product backlog. The more I use them the more I become convinced of their efficacy. This then feeds back up to the business customer for their buy-in. The developers then get involved with the business customer to define product backlog items into tasks that they complete. If you have good senior developers they should adhere to architectural guidelines instinctively & they should also be empowered to review code to increase a dev team's sense of ownership & responsibility. As an architect I'd ensure this was happening. Finally, at the code level, if there is something new &/or particularly tricky I would get involved with prototyping/solving it. Obviously there are many touch-points along this route, but the key parts for me are: communication, strategy & design.

Re: The frustrated architect

Maybe I should add that although I would prefer not go anywhere near writing 250 page docs, that's not to say I'm not able to do so if absolutely required to. In fact at every step I describe from functional specs, product backlog & project management/ScrumMaster to system design, code repositories, code reviews, coding & bug fixing, a good architect should have experience of doing all those things, & be able to do them well if required. Two consequences of that are that as an architect you have to be very choosy what you spend your time doing. Develop an archer's eye for picking the right problem & hitting it; secondly someone who is a solely book-trained architect who only draws & strategises away, isn't a tried and tested architect in my eyes: architects should have some battle stories. Analogously, a developer is a builder, a software architect is just as much town-planner as an architect of buildings.

Re: The frustrated architect

This is very true, I have no formal qualifications or anything in software development/architecture so my designs are purely based on my own experience, suggestions from the developers and whatever else I happen to come across. So I'll have plenty of war stories to tell the grandchildren. The archer's eye is a great phrase as you see in my role I have complete commercial responsibility for our software development division and so not only must I ensure that we deliver the business benefits to our customers I must also make sure that we make some money doing so. This requires me to work with our customers to identify their business needs, design a business focussed solution to deliver those needs, accurately cost it, manage it throughout the entire development life cycle and manage the people working on it - including the customer. We still have to work on a fixed price basis and so whilst the idea of a product backlog and user stories etc sound great, I haven't found a commercially sound way of using them when I also need to provide a fixed cost for the project upfront. My approach is therefore to write a complete functional specification at the beginning (which is where the 250 pages come from) and then provide a cost for the project based on the delivery of that as a software solution. However, the document isn't considered sacred and and we often tweak and adapt it as the project progresses based usually due to discovering new scenarios at the customer end or simply coming up with a new idea for something. The cost is then adjusted accordingly but this way it never moves too far away from the original number and it gives the business owners we work with, what is to them, an acceptable level of risk management.

Re: The frustrated architect

IMO, your role is more of a PM or PL. I believe the architect should get the requirements and analyze how to deliver the solution for them. The architect should know what are the best tool for the particular job and create the blue prints for it while deciding what patterns are more appropriate. The architect shouldn't worry about budget, the architect should be given a budget (or a margin that he can work with) and resources. With the requirements and aproximate budget at hand, he should build the specs that accomodates all the variables of a given project and plan the deliverables. He then can work with developers (and could even develop) and setup the environment. The architect should also monitor the products delivered by the development team and spot the problems and provide the solutions for them. The architect should also be the reference point for the developers when they need advice. Having roles of Business Analyst, Requirements Analyst, Project Manager and Architect at the same time is an overkill. That's what it sounds like what you're doing. Sometimes we can't scape from it because we're simply the man and we're given all these responsabilities, but it doesn't mean that's the role for an architect. When the architect has many more roles than it should, then he cannot focus on the task he's specialized at and may end up not being so efficient at it. I've worked on projects that I was the business analyst, the requirements analyst, the project manager, the architect and the developer. Believe me when I say I couldn't be the best at any of them.

Re: The frustrated architect

It seems that you are frustrated, 'cause people do much better than what you think you can do or you make yourself the only person to be "Software Architect".

Re: The frustrated architect

I advise my clients to help architects become technical leaders, either by going back into daily practice, but retaining authority (as it were) to make larger-scale decisions, or by becoming an explicit teacher. Why not?!

Re: The frustrated architect

Architect should be an alrounder in many ways than one. I agree that hands on architect is an asset to the project. As my mentore said, architecture is a collaboration and team game. Which means, architect has to better communicate, convince, seek feedback and mentor teams. It's also important that architect focus on busness needs and how architecture realizes that need but at the same time, shouldn't loose track on governace of the architecture. This is where hands on skills are more relevant while communicating with developers on the choosen architecture. They should be, in my view, convinced about the architecture and design for a successful projects.

Add a comment Send a TrackBack