Most software developers are not architects

I still struggle to believe that, even in 2014, the role of software architects remains hugely misunderstood by many people in our industry. We generally understand the role of software developers, business analysts, project managers, ScrumMasters, testers, etc but a common definition of the software architecture role still seems to elude us. There's nothing new here, I've spoken and written about this before, as have many others. The thing that irritates me the most is the common knee-jerk reaction along the lines of...

There is no such thing as a software architect and we don't need people telling us what to do. Software architects should write code along with the rest of the development team.

I agree 100% with the coding part of this statement. There are a number of reasons why software architects should be involved with the day-to-day coding activities on a software team. This is *my* preferred way of working. The "there's no such thing as a software architect" and "we don't need software architects" is shortsighted though.

Our industry is very hype-driven and it's common to hear people speaking at conferences about their "flat teams where we're all just developers". The implication here is that all of the other disciplines needed by the team (project management, business analysis, testing, etc) are also being accounted for by the team, typically through self-organisation, perhaps by agreeing that everybody is jointly responsible. In the latter case, this implies that the software architecture duties are being shared amongst the team too. In this situation, everybody is a software architect, except when they're not.

While I agree that software architects should be developers, most software developers are not architects. This is an important distinction. Many software teams out there are operating without anybody who understands the value of the software architecture role, let alone have anybody doing it. It's a technical leadership role and a lack of technical leadership leads to a whole raft of problems.

To give a real-world example, Troy Hunt wrote a great blog post last year called Should websites be required to publicly disclose their password storage strategy? that talks about how many websites are much less secure than they would make you believe. Some of the commenters suggest that perhaps the developers simply don't know any better, particularly when it comes to securing user passwords in a database. I agree, and while it would be great if all software developers had a thorough understanding of security, that's not going to happen overnight. Besides, we can't be experts in everything, but then we don't need to be. Such stories point to a lack of technical leadership. Every software team needs at least one person who is able to take a holistic view of the software being built, create a vision for the team to work with and ensure that any high priority risks are identified and mitigated. I'd say that these risks include security breaches.

If you think about software architects as being the equivalent to structural engineers in the building world, then it's not surprising that many software systems crash and burn. This frightening letter on Uncle Bob Martin's blog additionally highlights the need for more professionalism in the industry. I think it's time we started looking at how to tip the scales in balance of software development being more about engineering than craft, especially as we seem to be telling the next generation that coding is easy. Explicitly identifying those responsible for the technical leadership role, and educating others about it, is a step in the right direction.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: Most software developers are not architects

Architects design buildings. You all need to get yourselves a new word. Period.

Re: Most software developers are not architects

Whenever a discussion does not subside over time it´s a hint there is a misunderstanding or something more fundamental to be taken care of. This is the case with the discussion(s) about software architecture, software engineering and software craftsmanship.

"We are craftsmen not engineers" is as shortshighhted as "We are developers not architects" etc. And there will be no progress without an agreement on what those terms mean in the first place. What´s a "craftsman" anyway? What´s an "engineer"?

I recommend this book to help: http://www.amazon.com/Discussion-Method-Conducting-Engineering-Technology/dp/0195155998 - it´s written by an engineer reflecting on his disciplin.

With this and some experience as a craftsman and some common sense under my belt I venture to say:

We are engineers and craftsmen and researchers. All the time. It´s inevitable.

And here´s my definition:

-Craftsman: Someone who knows tools and materials to build a work piece according to a plan/design. A craftsman essentially is not creative with regard to what to build. He does not design the work piece.

-Engineer: Someone who has a state-of-the art knowledge about methods, tools, materials, natural laws etc. to design a work piece with help of heuristics (to balance requirements and find solutions) under certain constraints.
An engineer essentially is creative with regard to what to build. It´s his job to come up with a solution to a problem.
An engineer basically is an inventor. He brings something new into the world.

-Researcher: Someone who finds out about the state of the world. A researcher does not invent something new, but only describes what´s already there. A researcher is in the business of building up understanding/knowledge.

Take these definitions and it´s clear software developers are craftsmen and engineers and researchers.

When we analyze requirements, when we learn a new programming language or a new database API we´re researchers.

When we think about how to meet performance requirements or how to make software more secure or how to implement some functionality we´re engineers. That´s designing software. That´s what architecture is about.

And finally when we´re implementing a design, when we write code, then we´re craftsmen. We deal with tools and materials to manifest a design idea.

The point of contention is, it seems, how much time we do or should spend in those "modes". Some believe they can be mostly craftsmen. Let´s call them hackers ;-) Some believe others can be mostly craftsmen. Let´s call them managers :-)

But in truth we can (and should) only be some 20% of our time in craftsman mode. Because being a craftsman is slow and boring.

Most of the time we´re engineers or researchers. Most of the time we´re researching requirements or analyzing code during bug fixing or before engineering a new solution. Or we´re researching a new tool, method, API. Or we´re engineering a solution to perform better, be more scalable, more usable, more functional.

Interestingly TDD is intuitively separating those modes: writing a test requires research, because you need to know what to test in the first place, you need to know the requirements. Then implementing the solution is part engineering work and part craftsmanship. And finally refactoring means being an engineer again, because you design a better solution than existed before.

Also from the above definitions it becomes clear why estimation is so difficult. How long research or engineering (inventing) takes cannot be estimated. Only the work of craftsmen can be estimated because it´s kind of repetitive. Since we´re 80% of our time in researcher/engineer mode it´s fundamentally impossible to predict how long a task from analysis to design and finally to implementation will take.

Bottom line: All developers are architects/engineers. So they better get up to speed with architectural methods.

Dwelling on romantic images of craftsmen hammering away on stones of a cathedral won´t help software development much. Cathedrals like pyramids like the Burj al Arab did not get built just by craftsmen. And even more complex software won´t get built successfully just by craftsmen. It needs researchers and engineers as well.

-Ralf

Re: Most software developers are not architects

Totally agree on the engineering/ craftsmen thing. I'm into Business Analysis, and there it's exactly the same problem.
I think the two mainly differ in the level of 'structural thinking', a thing pretty hard to grasp. This is why I like the topic of abstraction so much, since I believe it plays a leading role in gaining a better understanding of what separates the engineers from the craftsmen.

So long
|=

Re: Most software developers are not architects

Great comment Ralf! It will be interesting to see where our industry goes over the next decade, perhaps longer, particularly given that technology is everywhere. I guess you've seen Uncle Bob's foreman blog post about ensuring technical quality and keeping all of the craftsman in line?

Re: Most software developers are not architects

Read Rober C. Martin´s article. But it´s strange to see this realization so late. All the "team hype" (every one being equal, not "knowledge islands") - and now: someone needs to stand-out so we get stuff done.

I recommend "The Invisible Hook" for a description of a "trade" which early on realized how important self-organization of teams was - but at the same time knew very well, someone needed to stand-out.

We shouldn´t strive to be cool hackers, or medieval craftsmen. That´s stale metaphers. Why not choose a new one: let´s become pirates of the code sea? ;-)

Re: Most software developers are not architects

"everyone being equal" works if you have a small team of very experienced people, but that's not how most real-world software teams work. Certainly the ones that I've seen and worked within, anyway. I know that certification is a double-edged sword, but perhaps the software industry does need some sort of regulation, standard certification or apprenticeship model in place so that we can at least set a minimum bar (like other industries). Pirates of the code sea... ;-)

Re: Most software developers are not architects

Some of the comment below are appalling to say the least. I am truly horrified by some statements , lack of education on the subject in general and understanding of thereof. According to TOGAF architecture is: - A formal description of a system, or a detailed plan of the system at component level to guide its implementation - The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. Did you notice ? system at component level to guide its implementation.... The statement that 'Most software developers are not architects' is pretty accurate (albeit not entirely accurate) statement in relation to software architects. Software architects ARCHITECT THE SOFTWARE and by definition should, if not must write code with the rest of 'software engineering' team, often called "developers". This statement however is not correct in relation to the following roles not responsible for software architecture: - Enterprise Architect - Solution Architect - Data Architect - Security Architect - Application Architect/Integration Architect These roles are what usually is everyone is referring to as Architect, because typically no one using the term Software Architect in relation to software engineering, unless it's something big, like new platform.

NO software developers are architects

Do any of you realize that the title "Architect" is a regulated title, its use dictated by law in every state. There is a great deal of push-back building in the profession of Architecture against the use of the title Architect in the software business. It causes un-ending confusion among the public, and in the worst cases you have software designers identifying themselves as Architects in casual conversation with out a hint that they are working in software development. You really need to find your own term. Think about it. How long do you think you would get away with "Software Doctor". The AMA would be on you so fast your head would spin. At some point the Architect's various professional organizations will take legal action, and the state boards will begin handing out fines. All state budgets are tight these days, and what a better way to raise capital than to hand down fines to software engineers for misusing the title. You need to get the term off your business cards, and off your organizational charts, and out of your job search postings - all of this is incriminating and believe me, there are those who have already begun to collect evidence.

NO software developers are architects

Greg - These comments are awesome. Not in a "I agree with you" type of way, but more of a "whoa, this dude is freaking out" type of way... Keep the comments coming, I enjoy reading them. This one is the best "...all of this is incriminating and believe me, there are those who have already begun to collect evidence."

NO software developers are architects

The title (as opposed to the word) is indeed regulated. I believe the UK's Architect Registration Board is pragmatic on the subject:
The name ‘architect’ is sometimes used in a way that isn’t connected to building and design. For example, ‘software architect’ or ‘systems architect’ are examples from the computer and IT industry. We take the commonsense view, and accept that no one could be misled into thinking this had something to do with the design and construction of buildings, and we wouldn’t take any action in these cases.

NO software developers are architects

Seriously? Is this a joke? If it is, it's funny. If not, oh well. @simon, great article!

Re: Most software developers are not architects

Even though this might be true - is it of relevance to the topic? I doubt it. "Architect" is just a name for a person performing certain activities during software development. And it´s these activities and their relation to the common software developer Simon mused about.

So whether we call the person "(software) architect" or "(software) foobar"... I don´t care much. The activities belong to the engineering mode of software development.

To acknowledge that there are certain activities other than and before coding, to acknowledge they require certain skills that´s important, I think.

For now it seems ok, to call the person performing these activities "(software) architect". If that´s not allowed anymore... well, then we can look for another term. That would be the last responsible moment to start the search. All else might as well be just wasting time.

PS: I doubt "doctor" is a regulated term. There are so many product/company names containing "doctor" that some lawyer would have sent them a written warning.

Re: Most software developers are not architects

Time to come clean and apologize for being deliberately provocative, and causing the discussion to stray. This was obvious to some of you, maybe not so to others, not a joke, but not sincere on my part. The above comments do not reflect my point of view, but there are people in the profession of Architecture that feel this way, and it would not surprise me if it was taken further than the discussions I've seen. My interest was to see the reaction of the software community. I personally see the appropriation of the title to be complementary. I think I the appropriation reveals a desire to imbue the software role with borrowed status - your own version of Grand Imperial Mystic Poobah (ref: Flintstones!). I think you don't need to borrow cred from the profession of Architecture. If I were in your industry, I'd want to use the word Designer. But you guys do what you want, and I'll continue to enjoy the nod to my profession. I'm done distracting your conversation now, thank you for your patience.

Re: Most software developers are not architects

No worries, Greg. The "stop using our title" perspective crops up every few months and will continue to do so as the software industry finds its feet. You proper architects have a few hundred years more experience building stuff than us though, so it's good that we're at least not trying to reinvent every wheel. And reinventing stuff happens a lot in the software world! ;-)

Re: Most software developers are not architects

Maybe teams need TDD Architects? Where the role of the Architect is more of a teacher than designer? From my experience it is difficult to fail with the architecture of software when developing in a test driven style. Testable design is good. The difficult part is to actually do TDD. What do you think?

Re: Most software developers are not architects

Any of you have the guts to call yourselves "architects"? Preposterous!

Re: Most software developers are not architects

Architects are architects. Architects are licensed, registered, educated, tested, have completed rigorous internships and required to maintain continuing education - all of which are regulated by state law. Architects are responsible for the health, safety and welfare of real people. Every building you enter has an Architect that is responsible for the life safety of every single occupant of that building for the rest of the Architect's life. Software programmers are software programmers. One is not the other.

Architecture is lacking/degenerate in software

I appreciate the last comment about the responsibilities that come with a real Architect title, because it sheds light on some gaping holes in the software industry as a profession, and the backwards view of architecture that is found in software: "Architects are responsible for the health, safety and welfare of real people ... Every building you enter has an Architect that is responsible for the life safety of every single occupant of that building for the rest of the Architect's life". On the other hand the software industry cannot answer to society for it's own product! A business defers to their developers to be the experts of the software, but even among developers, it's accepted as a given that code is just not understandable on the whole. We do ad hoc changes, thinking we don't have to understand every piece that is touched (after all, how can you?), do code reviews going "well, I can't prove your design, but I don't see any immediately obvious issues", and then rely on TESTING to say it's correct. That doesn't fly in any other "profession"! Software's backwards view of architecture is that it's just about frameworks, mechanisms, etc. that have nothing to do with human models. It's firmly established that the workings/shape/design of the code can NOT be understood in terms of human/user models, and in fact such are viewed as naive and lesser to the "programmers mental model". But you sell the patterns in your code, or the benefits it brings to the developers, you sell the ability for the USER to submit a payment or book a flight! I might understand individual slices of the code very well, and grasp the "architectural" layout; but if it's not clear what it's all DOING, then the product (and therefore the code) is NOT clear and lacks real design! It may be "extensible" or "maintainable", etc, but what is being extended or maintained? The developer having a good time, or the human centered aspects that make out valuable at all? Architecture is about PEOPLE; fitting structure of the thing to the needs of its INHABITANTS/USERS. Christopher Alexander (who brought real architecture ideas into software to begin with) talks about seeking a design which will, in some rather obvious or simple way, reveal/make clear the pattern of events (of the INHABITANTS) that occur there. However, contemporary software pushes that off to the side as something that week just "emerge" from different parts, rather than designing it explicitly into the code. Even the concept of "patterns" (which also came from architecture) are degenerate. Architectural patterns solve problems for the INHABITANTS, not the construction workers. Example: lighting on both sides of a room, accommodating lots of traffic without interfering with other needs, opening the for around stairs so you can see between floors, etc. The design should be toward (and make clear) the human events/needs, and THEN you find a way to do so that is structurally sound, etc. Architecture is not the structure, it's the things that go on in it (a place to meet, to travel, to eat, etc.), and then the physical structure makes this clear. "Software architecture" has this all turned on its head though, because there is nothing tying the code to the use cases; we've been taught that if all the individual pieces just "do the right thing", then the system (which is the thing we're after) will just emerge from it. And then we concern ourselves with solving the problems of fitting those pieces together, and fixing the stuff that emerges from it (because you can't reason about out directly, it's not fully predictable, and there is NO proving that the design is sound). The software industry needs to get up to par with other "professions" and be able to reason about their own stuff in the terms that matter, and be answerable to society for it. What a SHAME it is for this situation to ever have been acceptable, especially in a works that now runs on software, and which had now learned to EXPECT poor experience and things breaking down all the time This would never fly at large in the built world, and I understand the insult may be to some when they see the "Architect" label applied in software. There is indeed a lot of lack of ownership/responsibility over what has been coded over time.

Architecture is lacking/degenerate in software

There seems to be a huge difference between a building and software: buildings are inhabitaed, software is not inhabitated. Users are not "in" the software doing stuff. They are always on the outside. They only have contact with a surface, the user interface. Like with a vending machine or a car.<p/> The "architecture" of a vending machine is of no concern to users. But the layout of the surface is.<p/> What C. Alexander ist talking about is the "interaction surface" where inhabitants are in contact with architecture. When software devs talk about architecture it's (mostly) about what's behind such a surface.<p/> That said, software development at large needs to take a different stance on software architecture. It's still too much hand waving and too little systematic design.<p/> And despite interesting influences from all sorts of other disciplines software dev can learn from... it's at the same time something utterly different. Software does not suffer from wear and tear, software has hardly ever a preset lifetime, software needs to change much, much more and at a higher frequency over an indeterminate timespan than any other human product. We've to keep learning how to deal with that.

Add a comment Send a TrackBack