| Sergey Mikhanov | |
Why I don’t believe in software architects (January 26, 2010)A common train of thought in the employed hacker’s head: I enjoy hacking; I don’t want to become a pointy-haired boss therefore I’m not going for management; I don’t want to have anything in common with suits and meetings and investors and therefore would not go for entrepreneurship; but I still want to do some career management for myself. The option that seem obvious for him is to aim for becoming a software architect. If you ever found yourself in this way of thinking, think again, for there’s no such “software architect” job that you would desire. On the first glance this seems wrong. There are dozens of open positions in software companies bearing this title. A quick search on Amazon for “software architecture” reveals thousands of titles. But first 50 results or so are dealing with the software modeling using some higher-level description language, which is usually UML, and sometimes more exotic choices are presented like Z Notation (anyone?). There’s even a book luring the described hacker into buying it with its title: Software Design: From Programming to Architecture (it is about UML modeling, too). The only exception is the useless collection of developers’ anecdotes named 97 Things Every Software Architect Should Know (carefully cached by Google here), but I tend to think that this is the exception which supports the rule. But wait, shouldn’t software architecture be an activity which involves dealing with software itself and not the models of it? Book authors do not think so. I guess the reason for that is the fundamental dichotomy between programmers in different companies. A former colleague of mine wrote recently a piece on that:
“J2EE enterprises” love “outsourcing-style interview questions”:
For the recruiters or book writers “software architecture” is neither an activity nor a way of thinking, it is a way of determining the job title. In their reality “software architect” is the person squeezing 3rd party code into a conceptual software model. He clearly belongs to the J2EE side of the dichotomy though might not use J2EE at all. It is a person who values dependency on someone else’s software in favor of developing it. This sort of dependency may be good, but for the demanding subject domains this is a double-edged sword (Paul Graham covers this issue with his usual bias towards Lisp in one of his essays). The reason behind all that is simple: “architect” does not write code. Mr Joe Hacker, is this the career path you were dreaming about? A curious reader might ask: why do you proudly claim to hold this title then? Because I believe in software architecture as a way of thinking. I see this as a capacity to deal with the huge problems and significant amounts of code nip and tuck with the in-house development team. I do even know a single good book on the subject: Eric S. Raymond’s The Art of Unix Programming. Even is you never will hack Unix, this is a very valuable book to read. What about career path then? Well, I can’t give any personal advice here except for the “avoid advertised ’software architect’ positions”. The best company will allow you to keep writing code while expanding your area of influence wider and wider into the company products at the same time. This is what really software architecture is about. What others are saying?Leave a Reply |
|
| Entries (RSS) | © 2007–2012 Sergey Mikhanov | |
Below is what I understand of a Software architecture and architect responsibilities: Software architecture is independent of any technologies and is different from programing. Often a programer may not consider hardware requirements and is often restricted to limits pertaining to application he is working on. But an architect would have much bigger view and would consider multiple systems/applications, software and hardware constraints and requirements. He then decides on required technology for implementation which may be J2EE or MS Technologies. Also an architect needs to understand business (finance/telecom domain knowledge) more than a programmer. UML is only one way in which an architect communicates to programers and other stakeholders of the solutions he is proposing.
A developer’s concern is how to implement reliable logic when an user clicks some button. An Architect’s concern is how to implement a reliable system when thousands or more of concurrent users click on that button.
I am one of those developers who hopes to one day switch over to an Architecture type position, and despite your article I think I still hold to that. It seems that you assume that Architects should still be neck deep in code. “The reason is clear: “architect” does not write code. Mr Joe Hacker, is this the career path you were dreaming about?” I’ve never held this assumption. Today, I write highly transactional, multi-threaded, web service oriented software, but I don’t expect to keep doing that forever. I’ve always known that once I take on the Architect mantle I will be drawing block diagrams, writing white papers, and yes drawing UML diagrams. These are a higher level of abstraction from code, but that doesn’t mean that they aren’t important. As you’ve mentioned, the Architect should provide direction with the particulars of third party frameworks, but that’s seems like a minor part of the job to me. The most important job that an Architect provides, in my opinion, is that of dividing an exceptionally large project into smaller workable parts, and providing a sane overarching way to make sure those parts will work together. I also think that an Architect should stay involved with the code on a spot check level. If he/she doesn’t have a good understanding of the code that the developers are producing, there will be no indication of how well they are succeeding, and there certainly won’t be an indication of how good the developers are at their jobs. The Architect is ultimately responsible for what they produce, so it’s in his/her best interest to be concerned.
Some projects don’t need an Architect. If you’ve got a fairly small project, then just write it. But I’m currently working on a project that spans twenty or so servers, each running it’s own set of software. At some point you’ve got to back up from the details of the code and Architecture is great for that. So, don’t try to cram an Architect into every project, but I still think that they are a very useful resource.
Every project has an architect, also known as the technical lead, senior software engineer or core developer. I’m very wary of being described as an architect of solutions because it’s too abstract for my taste. So I do business as a consultant toolsmith, a term I get to define. The lack of career path for software engineers is another problem.
~Matt
Hey, I’m an honest to Bob real live Software Architect. That’s my actual job title here in House Harkonnen. I write oodles of code and even contribute to several open source projects – some of my own, some as part of what I do for my day job. I’m pretty sure I’ll be doing this ’till they pry the virtual reality lenses out of my eyes and take away my secure login credentials for my development platform. There are other architects ’round here which seem to never code and only generate powerpoint and white papers, but they also seem to be in the minority. What I see in the actual consumers of our spawn – i.e. our customers – is a bit different, though. Architect really does seem to mean “someone who doesn’t need to sully their hands with code”. But that could simply be sampling bias on my part.
Drawing from the engineering analogy, civil architects usually don’t get to their positions by starting out laying brick. On the other hand, most engineers I know (civil, nuclear, electronic, mechanical and aerospace) all love to get their hands dirty and don’t seem to ever stop building stuff. It’s really hard for me to imagine someone knowing what they’re doing if they don’t actually keep building stuff. Especially in a field which is constantly reinventing itself and inventing new stuff all the time. I’m sure there’s probably some areas which are well staked out and don’t change all that much, but – as they say – those will probably be automated soon, and won’t require any architectin’
Just my 2cents…
i think is totally depends on who is the architect .. :)
Be wary of the “architect” title; it can lead you down the path to stale coding skills just as fast as becoming a project manager or general IT manager. The issue is that corps don’t know how to use, and probably truthfully have little use for, a software architect (or system architect, enterprise architect, etc.) in the purest sense. Modeling systems is great, and it produces lots of doco, but nobody ever looks at it after you write it down and the final system may or may not look anything like your architecture. Sure, blame the process, blame the architect, but the company isn’t interested. “Just make it work by this date.”
So what do corporations use their architects for? Letsee… Among my architecture assignments at a very large company that prides itself on being “architecture-centric”: planning training conferences (arrange venue, agenda, speakers, catering, lodging, teambuilding exercises, etc), cost analysis, system and interface inventories, financial planning, project management, vendor management and very little actual what-all-the-books-would-call architecture work. I use Powerpoint daily, and EA tools, like those from Sparx or Troux, NEVER.
I am constantly told how my architecture skills are required, but the work I (and all the other architects too) am given, is more of a general IT manager. After a couple years of doing that, can you still call yourself an architect? More importantly, would you still even qualify as an architect if you had to go out and get a new gig?
It’s the same as any time of architecture whether it is buildings or website architecture, it’s about knowing how things fit together, having a true understanding of what it is you are trying to build.
I have only found one Software Architect truly worthy of the title: Roy Fielding
If you’re doing anything Prescriptive, you’re really doing design, for better or worse. Software Architecture is properly Descriptive — it’s an explanation of how a system works, and how to make your work fit its structure. It’s not something you should ever be doing up front: would you do something as foolish as trying to design a national government from scratch?
The GoF had a good idea to describe software in Alexanderian patterns, but they didn’t really understand why and for whom his pattern system was designed, and then they fucked up the implementation in the extreme.
[...] This post was mentioned on Twitter by Hacker News Bot, Nishant Modak, Thiago Arrais, Web Startup Group, Simon Brown and others. Simon Brown said: Why I don’t believe in software architects by @i_am_neuron -> http://bit.ly/9h6MCM (a good read) [...]
I definitely agree that architects and programmers (hackers) can’t be fully separated. I’m found of the idea that code === design, therefore the development team must take elementary part in the architecture. But architecture is unavoidable. There are too many basement geeks in the industry who aren’t participating in the business process of architecture, that is the problem. Because the problems we solve are not primarily technical, but business problems!
If programmers dislike business people, the colleagues, unable or not willing to communicate, understand and decompose huge problems into manageable ones, that’s a problem. Because programmers tend not to spend time in meetings where they could get to know what is really important and what isn’t in the project (just to be able to solve the right problem), businesses then hire pure architects (and managers) who finally tell the programmers that it doesn’t matter how cool and proven their algorithms are, but the website has to scale and work on time, and to take the proper trade offs etc.
Programmers (I’m one) should fix their social and business skills and become architects them selfs.
Design and requirements are unavoidable. You either get involved or someone totally unknown to the project will do it.
TIM: “The reason is clear: ‘architect’ does not write code.”
INSANE!
If you don’t write code, how are you going to keep your skills sharp? Libraries and technologies change so fast in this business, you will be out of date in 2 years or so. And if you don’t write any code, you won’t be able to make good architectural decisions – you have to try and iterate on different ideas.
I read the article as, some companies have poor hiring practices, therefore don’t be an architect. I’ve had the architect title a few times (I’ve got one now) and found that smart companies have good practices that keep architects close to the code. I’ve been an architect on an XP project and coded everyday. My advice: (1) Make sure you interview the company while they interview you. (2) Generate more than one offer so you can pick the best match between you and the company. (3) Don’t stop managing your career, even after you’ve found your dream job.
Totally agree with David, this glorified title is hyped up, it all depends on the type of engagement and the personal choice. If you are lucky you will get a chance to play a role of an architect. Opportunity wise my experience is product companies can offer more to this role than consulting firms. Regardless #3 is very true.
Ok. I hold the SSA title in my presentation card. I get paid as one too. I do teach a fundamentals of SSA class at University. I’m writing three books about architecture (and no, they have absolutely no UML, since that falls mostly into tactical design and Architecture is strategic design). I did contribute one post to the 97 things book, was published on site but not on the book.
I do write code, mostly the fun things (POCs of utterly impossible features, which I can tell later if possible or not). I do check code of peers, and I do coach them to be better than me. I do read a lot and try to be at the edge. I do post a lot and tweet about agile, REST and SOA and any other high level, development trend out there.
And I totally agree that more that half the people with that position does not even understand what architecture is about. And even more than that percentage of employees do not understand what the architect is for. And almost 99% of the agilistas won’t understand it either.
Oh, well. I do still believe what Sharp said at the NATO in 1969: We need architects.
@William Martinez: Could you please post the link to any of your books? I’m really curious what would software architecture book look like if UML would be thrown away. The driving force behind this post was the fact that right now I believe that SA books without UML will be empty. I.e. there’s very few (or none) substance to the SA activity that distinguishes it from the software engineering activity. I would be happy if anybody will prove me wrong.
Hello Sergey.
Sorry, as I mention, the books are in writing process and I haven’t made them into online reading and far from complete.
They are “Architecting REST”, “The Daily Architect” and “SS Architecture Fundamentals”. The first one is a very general discussion of REST from the architecture point of view, that is it does not contain a recipe for creating a REST web service, but talks about the quality properties REST aims to achieve and how to validate your application need those too.
The second one is a handbook with every day tips on architectural work. From how to start a new project, what to document, how to inherit a legacy project, how to work with people, etc. The last one is just a compilation of the topics I teach at the University.
I can assure you, architecture is not about writing UML. If you see the book descriptions, we are talking about tools, techniques for understanding and working with business concepts, with people, with processes, with deployment, a whole bigger, wider view than a class diagram. Strategic over tactical or operational. Actually, the first thing I do in my class is to ask students to forget about classes and packages. In the class we see functional elements, we talk about functionality and concurrency and information, and not about classes and packages. We do not talk about user cases or user stories, we talk about understanding the business environment, the business value. The application may implement all requirements, may be done on time and on budget, and may have beautiful UI, but if it does not provide the expected value, then it is a failure.
So, yes, we can fill a book with all those topics, and never user UML. Well, we do in a sense. When we work with views, functional view for instance, we need a way to model the functional elements and their relationships. For information, we may need to describe the life cycle of an information element or entity. We borrow then some diagram types, like the state diagram, to model that. But the focus is not in UML, but rather on how what we are modeling, makes sense in the business. UML is just then a utility, and we may actually use simple boxes and lines.
Students take two courses on software engineering topic. They learn how to estimate, design patterns, modeling in UML, etc. Regular engineering stuff. But there are two views that are missing, the business one and the structural one. In SSA they learn to see the robot cohesive constructions and why they are there, as a whole, and not just the nuts and bolts. So, as we simply try to forget all seen in the SE class, they end up feeling all that info is somehow complemented with SSA. They learn that creating software is just halfway path. Developing is not just writing code, it means coding a solution that is well structured to save the day. Not all developers may become an architect, but all architects should be developers, and all developers must know the fundamentals to actually get good code done.
Hope this helps your curiosity. :D
— I’m really curious what would software architecture book look like if UML would be thrown away.
I agree with William; you can learn about or teach software architecture without a focus on models and UML. It’s just one option for documenting and sharing knowledge.
I run a software architecture training course and, as you can see from the slides (http://www.softwarearchitecturefordevelopers.com/preview.html), we don’t cover UML and still have more than enough for a full two days! :-)
Sergey,
You spotted very interesting problem with software Architecture. While I do believe into *real* software Architects, I support Your conclusion that often ‘Software Architect’ title means virtually nothing. More on my blog:
http://www.restfusion.com/blog/2010/01/i-do-believe-into-software-architecture/
Artur
I love the way you begin describing what goes on in an “employed hacker’s head: I enjoy hacking; I don’t want to become a pointy-haired boss therefore I’m not going for management; ….” Given this train of thought, woner what you would think about the poor souls who would like to consider themselves “Enterprise Architects”
;-)
What is your definition of a ‘Hacker’? To me it is someone who provides an absolutely minimal solution, with no regard for maintenance, documentation, graceful degradation in the even of failures, the requirements of the other team members, and the non-functional requirements. By definition these type of hackers have no time for Software Architects.
Yes, architects might “squeeze 3rd party code into the conceptual model”, but the reverse is a return to the ‘Bad Old Days’ when C programmers were supposed to spend 20 seconds looking for a function before giving up and writing their own. I’ve seen systems where developers have a Not Invented Here mentality (even with respect to using code from others in the team) and the results aren’t pretty.
Where I do profoundly agree, however, is that the industry desperately needs a new term to use instead of ‘Architect’. This would describe someone who is equally at home making key design decisions and working with the ‘35,000 feet view’ as they are with coding algorithms and other low-level elements. People who know exactly how to use components because they’ve developed with in real systems, and seen the problems at first hand. People, in other words, like you and me…
@phil swenson
Sorry if it wasn’t clear Phil, but that was a quote from the article. I agree with you 100%.
I’ve lost count of the number of heated discussions about what the term ‘architect’ means in IT, that I’ve: caused, taken part in, and sometimes had the last word on (but not that often :-)).
We all seem to know what a programmer is, and the BCS definition of Enterprise Architect is pretty solid IMHO; then there’s this HUGE gap in the middle that contains all sorts of job titles, from ’senior programmer’ to ’systems architect’, perhaps passing through ‘application architect’, ‘team lead’, and maybe even ‘IT Manager’, somewhere along the way (you could even argue the toss on BA vs architect too, as you head further from the code cutting). The fact is that there are very few consistent definitions, let alone usages, for these labels (I got very lost in wikipedia a year or two ago looking into the very same), and there will continue to be endless discussion about what those labels mean for the forseeable future. The problem is made worse by the classic attitude held at many organisations: “Ok, you’ve been a programmer for 5 years now, so you have to be an architect or a project manager (or maybe a BA), which is it to be?”.
Another reason for the huge array of different job titles and understood meanings? Well, we’re all human (apart from the pointy headed ones), and we’ve all got things we’re good at, things we’re bad at, things we like doing, and things we don’t like doing. Coding the Architecture used to have (might still have, I couldn’t find it) a fantastic single page slide that had a box for each constituent of an architect’s role that *might* be there, depending on the particular engagement/project. Part of the the point (iiunderstoodc) was that at different times, and for different projects, different boxes would be important. If I ignore the ‘architect must cut code’ side of things for a second, CtA manages to cover the huge gap I referred to by not trying to tie down the role to specific job titles, and my own experiences tell me that this is an appropriate and productive approach.
I thoroughly agree with David Mitchell’s advice here (as well as the spirit of the article, rather than some of the content) – make sure you get the role you want by using your probing skills during the interview to find out what your potential employer/customer expects from you. Know what you are good at, and spend as much time as you can thinking about what you actually want to *do* next, rather than what you want to be *called*.
It seems to me that an architect is the person who does most of the due diligence for a large system. They’re the ones who figure out how the system will integrate with the current stuff, what new software or additional licenses will be needed, touch base with somebody in IT to make sure there’s enough capacity, figure out the security details, and work out the deployment details. Then they do enough design to make sure the developers don’t get off course, maybe performing some in-depth design for various infrastructure bits (e.g., a security gateway, if there’s a useful abstraction to lay over the top of LDAP/AD/whatever). They may or may not be involved in some of the development infrastructure (SCM repository layout/location, tools & technologies used). I think it’s difficult to be involved in the actual coding if it’s split among a half-dozen teams on three continents using different tools & technologies, but I think the architect needs to be involved when compliance tests are being designed and written, since they are ultimately the ones responsible for meeting the specified targets.
Building a (complex) building without using (proper) blueprints is foolish. So in construction the role of an architect is valuable.
In a software environment, where you also have blueprints, designs and building blocks, a software architect may not be such a superfluous position.
Architectural flaws in software can be as costly as getting the foundations of your house wrong.
Hrm. So back in the day people wrote code in Ada (using a stick to write words in mud). Then people went to Fortran (using a sharp piece of rock to draw of cave walls). Then people went to Cobol (using a chisel to carve things in stone). Then came C++(hammer) Java(jackhammer) rails like platforms (nail gun) and what not. All software systems using these tools in their architecture are retroactively considered useless/broken/unmaintainable/obsolete/etc. What’s to say someone won’t invent some nuclear powered rails on mvc functionally aspected object framework tool that does everything you want (but becomes obsolete in a year) some time in the future? So what’s the role of the architect who always tries to make decisions to use these tools? To introduce the FUD flavor of the week into projects.