An architect? According to Wikipedia, an architect is a person who plans, designs, and oversees the construction of buildings. So, we obviously have derived the role from civil engineering. In parallel, we derived software architecture which refers to the high-level structure of a software system. As you might guess, I don’t think we need a formal architect role but an architecture. Before starting another dispute, let’s watch Matrix Architect Scene.
The Architect in Matrix
Cool stuff? That’s well deserved for anybody who built a piece of software. Yup, you got it. I think any working software has some kind of architecture. Whoa, then everybody is an architect? Well, yes and no. Yes, an architecture needs architect/s. No, I don’t think we need to define a formal role and call everybody architects.
Comparing To Civil Engineering
Going back to civil engineering. An architect designs a building more concerned about aesthetics, artistry and overall shape of construction. A civil engineer concentrates on the structural elements of the design. A builder makes the structure. That’s it. No more definitions. As you can see, these are well-defined roles and they are somewhat hierarchical. Do you think we have or should have such hierarchy while developing software systems? Well, no. Of course, an experienced engineer would have a different perspective than a recent graduate. However, these two engineers would both influence the software system they are building and should contribute to the architecture of the system. If you want to name one of the architects and not the other, do you think that it’s fair? Nope! So, a formal architect role isn’t really fit in software development.
If you think we only need “software architect” title to emphasize seniority level, then I disagree. Most of the big companies have a good development path. They more or less look like software engineer 1 -> software engineer 2 -> senior software engineer -> principle software engineer. Let me note it down, they don’t have formal architect role.
Bunch of random questions and answers:
Let’s take principle engineers as architects and ask. Do we really wait for principal/senior engineers to evaluate each piece of software we build? The short answer is no because they are working on their own projects.
Do we really need a proxy between customer and team? Why can’t we sit all together with the customer and make a decision? I think it should be the team effort to understand fussy requirements and make concrete tasks out of them. Certainly, there will be people who will have more experience and can lead others from time to time but yet we don’t have to call them architects. They are seasoned engineers.
In a team without an architect, do people struggle to write clean and quality code or is system design phase abandoned? I think a good team should do design reviews first; then code reviews to share knowledge, increase code quality and hear all voices. With good communication and good distribution of engineers according to seniority level, the quality software can be delivered without a formal role of an architect.
Do we really need a formal architect for leadership and strategy? Well, aren’t managers supposed to be the leader of the team and decide the strategy? I guess these two aspects are one of the reasons why we have managers. What about technical leadership? Since software development is like craftsmanship, craftsman(senior engineers) should share how to develop well-crafted software. So, we still don’t need a formal architect role.
In consequence, I don’t think we need the separate role for just designing the architecture of a system. In my opinion, every member of the team should take part in architecture discussions and a team should come up with a design. Moreover, the architect role doesn’t really need to indicate one’s seniority level. All in all, goodbye architects, let’s talk architecture.
Edit: I think I owe many thanks to anybody took time in discussing this topic. I love all the answers. They have great points.
If you have ever worked in construction you will realise that the builders have a huge input as to how the building is actually built, Architects sometimes have an idea in mind that can’t easily (or within cost) be built as intended, the builders will often come back to the architect and suggest different methods of implementing it. It is a team effort.
Let me just say one thing first of all – the Senior Developer should not just have the job title of “Architect” – It is not a question of seniority, although in practise it is often like that because an Architect has their own set of skills and have usually already spent a few years as a senior developer.
As an Architect myself (for software), my job isn’t just to design the system, it is to take the clients (often airy) requirements and design them down to functional specifications. Then, unlike a building architect I am also leading that team (through the senior software engineer) to ensure that the code fits in and solves the.
If you are a small team who work on small projects then I agree, you don’t need an architect, Most software developers (by nature) have a great degree of problem solving ability. Therefore no-one should be given that title.
In the same way you wouldn’t hire a building architect to design a shed, you wouldn’t use one to design a blog. However, once the project gets past a certain size then you need someone to take control of the big picture, to manage client expectations of what the company requires. A senior developer can not do both efficiently.
As a real software architect, I am not sure where to begin in my rebuttal. Basically, what you are asking for is cowboy coding. An if-it-feels-good-do-it style of complete chaos with no concern for the future costs of supporting an albortros of an implementation.
Clearly you’ve never seen or have blocked it from you memory, 200+ line methods with an off the charts cylomatic complexity. Let’s not even discuss test coverage or enforcement of SOLID principles.
Architects are more than code standard agents, or software designers; they are a vital part of a healthy development culture, always on watch. While the dev teams implements the now the architect is steering the course to the future.
It is the architect who intercepts the inbound vulnerabilities that are discovered every day and engineers the strategy to overcome it all the while the dev team just trucks along unaware of the pitfalls the architect has nuteralized.
The world you describe is rainbows and unicorns and I would love to have a slice of that heaven. But I live in a place called Realville and free style get-r-done code is actually why am gainfully employed because companies are being crushed under the weight of the technical debt being created in the wild-wild-west you condone.
I completely agree. I think many people are nodding in agreement with you.
The mindset of architect is different from a developer. The need of an architect cannot be denied, as Risk evaluation, mitigation and QoS are some areas where architect is required, as architect is a visionary who can conceive the systsem before it is born. In Enterprise applications, there is a need of specific role, an architect who needs to do much more than code reviews…and much more…
Saying we don’t need an architect sounds like saying we don’t need leadership. I’ve been on teams that had great developers but lacked good leadership and the project failed. I’ve been on teams with ok developers and a great lead developer and the project was a great success by all accounts; customer satisfaction, internal structure, teamwork. In my experience an ideal team needs good developers and a really good lead developer. Call that lead developer by any name you want, as long as long as he brings his expertise in designing a robust, maintainable, scalable system.
Turning all design decisions to a democracy can sometimes lead to a very inefficient way of building software.
After 17+ years working with software development groups I think that one of the primary issues with software development is the lack of a clear decision making process (about how it should be done, not about what it needs to do). In many groups this is simply delegated to a single Architect, Manager or Team Lead which may not be ideal and may cause some tension between Developers, Leads, Managers and Architects. After all many decisions are at least somewhat subjective having no absolute best answer, with many design trade offs.
From the (Senior / Head) Developer, Lead, Manager an Architect points of view I think one of the primary reasons for various titles is career advancement (including raises). After all why work hard if your in a dead end career?
From the organization (business) point of view these titles help the organization stay organized, so that it can fulfill it’s goals.
There are a few very successful organizations (i.e. Google) where ‘Software Developers’ often have Phd’s (apply to become a Software Developer at Google to see this). Although I would guess that the decision making process there is more of a innovation free for all (i.e. Angular.js vs GWT with both lacking support for AdWords and most Search Engines).
On the other hand Scrum defines the Architect role (note this doesn’t need to be a job title, as many people may take on the role).
I think the best way to make decisions is to have an odd number of peers (Odumverate) vote and document why the decision was made. I also think that organizations should try micro teams where each team has a leader with an even number of four or less regular members. This could simply scale as follows using any titles appropriate for the organization;
Development Team 3 people, 1 Lead Developer and 2 Developers
Odumverate (the whole team)
Lead Development Team 7 people, 1 Architect and 2 Development teams
Odumverate (1 Architect and 2 Lead Developers)
Architect Team 15 people, 1 Lead Architect and 2 Lead Development teams
Odumverate (1 Lead Architect and 2 Lead Developers)
etc.. Adding more titles for larger organizations for infinite scaleability.
After reading the article and the comments I think the main point that creates conflict here is the definition of the software architect role and its functions.
In one moment the author compares the software architect with the civil architect saying that he’s more concerned about aesthetics and art. Well, yes and no. Though as any other activity software architecture has its artistic part (so does the coding, testing and any other) it is also about seeing the bigger picture of the project and all the stuff it involves, something that a dev team involved in the project can’t do. Besides aesthetics a civil architect also has to think how a particular construction would fit into the surroundings involving the environment (sun, light, terrain, seismic, etc.), other constructions close by and local infrastructure (roads, pluming, electricity, communications, etc.). Engineers usually are not concerned about those things, they come to do their job and that means all the activities inside the actual construction boundaries (that can also involve aesthetics but on an “internal” level).
Personally I hate the terms “macro design” and “micro design” since they are too dependent on each particular context, but in this case I think they would be adequate for my explanation.
So why should an architect stay between the dev team and the customer? The answer is: It should not completely isolate the dev team from the outside world because he cannot give every detail to the devs they need, still usually the dev team’s concern is only the project they develop and the rest can, and usually does, go to hell. In real life big projects normally there are dozens of dev teams, each one developing some component of a bigger system where the “micro design” is involved, while the primary function of the architect is to design and oversee these components so they all work together and “speak” the same language, in other words one of the architect’s functions is “macro design”. In terms of one component the architect should see it just as a part of a bigger system.
If we skip this position and just invite a bunch of tech leads to a conference explaining them what we want and assign them some tasks they will distribute them and start working. But the problem here is that they are just people, and people think and do things differently, and they are not always agree. And if something goes wrong usually they start blaming each other where you as a customer won’t find the ends. Following this approach we’ll surely face the following problems:
1. The design of each component would be very different from the rest that would compromise the uniformity of the project and create problems during the post release phase (extension, support, etc.). In street language it’s called “Frankenstein Design” where each part of a bigger system looks and lives by its own rules, and while it can function (actually it’s a very common case in real life) it would be far from perfect.
2. Integration phase problems, where each component works alone but joined together because of their design differences the components could simply face compatibility problems.
3. Most of big systems cannot be completely “internally decoupled”. You send something through the portal, then it goes to security module, then to the service bus, then to the business layer (which itself can be formed by several independent modules), etc. And the whole time you have to maintain at least the user state and the security. Thus we are taking about sharing data that should mean the same thing on all levels. This cannot be achieved using the mentioned Frankenstein design since every dev team will treat these concepts differently depending on their module’s role. Sometimes they even give those different names, so when a front-end developer from one team talks to a business layer developer from another team they simply speak different languages and cannot understand each other, even if they talk about the same damn thing.
The software architect’s function is to see the big picture that involves business, hardware and software of the entire system linked together. This role involves the responsibility of the whole solution, so if anything goes wrong the customer knows whom to speak to. The architect also serves as an internal remediator solving all kind of conflicts between the dev teams: design, technical, sometimes even social.
I’ve spent my entire life designing and developing systems and can say that one person simply cannot do everything good. If you want to develop a critical component “correctly” you spend all your time designing it, controlling its development and giving support to other dev teams. You simply won’t have time for the “big picture” stuff. And that is the other reason why the architect positions exists.
Jerry, can you clarify what your job involves?
“intercept[ing] the inbound vulnerabilities that are discovered every day and engineers the strategy to overcome it all” is pretty vague, and the specific examples you give – cylomatic complexity, test coverage or SOLID; are things that most junior developers are aware of.
As one who has dealt with software created by teamS (plural is important) without architects, one specific comment is that without architects, the the codebases and APIs that are created are a horrible mishmash of conflicting principles and styles. The API structure from service to service look like a Jackson Pollack painting, the dependencies show no consistency, and each time you start working on different project, you are starting from scratch.
Architect here (civil engineering).
You clearly have no idea of the role of an architect.
Yes, it’s the one designing buildings, not just based on aesthetics but on functionality (form follows function), aspects of city planning, social behavior, laws, material sciences, monetary limits and deadlines.
It’s also the one doing the structural engineering that gets double checked by a structural engineer later on.
It’s the guy who manages all the legal stuff (building application etc) so others don’t have to.
It’s the dude that, in the end is held responsible if there is something wrong with the product (building).
Architects are the ones talking to the customers so that the customers don’t have to talk to everyone that will be involved in the building process, because this would be a lot of ppl the customer would have to talk to and it increases the chances of miscommunication – resulting in a shitty product.
Also the Architect is the one advising all the shareholders on the construction site. Ordering stuff. Making sure things are well build. Organizing, orchestrating… not bossing around but rather moderating the process.
Architects are generalists, knowing a little about everything that is involved in building a product. They connect the dots and validate developments from various perspectives.
Can you build a house without an architect? Sure, if it is small enough. For larger projects you definitely need one… Without Architects there would only be chaos.
Now that you know what civil engineering architects do, I think you should reconsider your neglect for architects in software development.
Most important don’t get caught in the thought that it’s architect vs. developer because actually it is architect + developer = lots of <3 from the customer!
I agree with Jerry. In my last job, I was always surprised by how little the developers knew about how the entire system worked. I think of an architect’s job as the ability to bridge the gap between Operations and Development. People who say you don’t need it – they’re developers.
“So, a formal architect role isn’t really fit to software development”
An SA would not have allowed the construction of this sentence. It produces an error…
So, we DO need architects. We make sure everything fits within the construct of the product, and that all rules are followed with design of an agreed upon manner.
Boo Yaaaaa
A good collaborative developer team doesn’t need an architect. A clumsy designed architecture, developers have pretty much no say needs a dictator kind of architect. Period. PS: From my twenty years of experience.
o/ Straight from the horse’s mouth! Well said! (No disrespect meant)
Imagine someone who wants to plant a tree and in the end you see that the entire road is being dug up for the tree saplings
(My first impression: I am not a native English speaker but the spelling/grammar in this article is not perfect IMO. And if I spot problems then either I am wrong or there really are issues.)
With regards this teamwork sh*t the software making industry is always emphasizing lately, everyone keeps silent about the typical group dynamics that the loudest wins. In the heads of management groups will produce the same result because many people make up a group and they even things out. But if you ever worked in a group in which you were not the loudest and then switched to a different group you must have observed that groups and the decisions they make can be completely different. It does matter what people are making up the group and politics within the group will become way more important once the hierarchy is not established. Hence by saying “the group will take care of it” you say I’ll leave it to luck in that it is not IT skills but social skills that many decisions will be based on. God please let the loudest be smart enough.
The team will take care of it approach is good for management and business of course, they can sack 80 percent of the team and 1 year later hire the same number of guys and things will carry on. This or that way. However we should not pretend that this is the ideal way to make software assuming the group membership is constant. This approach is ideal if business and management cannot provide a constant environment. So this is a conflict between management and devs in that many devs would expect a constant and safe environment in their jobs and of course when a job is advertised we are often told that this will be a stable long term position. This is only told because this is what we are often looking for.
While in the US the laws are terrible (free country if you have a few millions on your bank account, not so free when you live month by month), in Europe they do protect the workers this or that way. And look at this in Europe: new programmer positions are often opened in small subsidiaries of large companies that they can be shut down at any minute, they just need to close the company. Are you working for SAP/Siemens/HP/anybigname but do not have a contract with those companies but with XY ltd? Well if the operational and development costs are too high at anybigname then good luck – you will be the first one to go. This typically happens when there is an economy downturn, so just know what to expect. Scrum and the team will take care of it is a part of this new strategy. Would be great if people were aware of this.
The trend this industry is heading to is that people would be fully replaceable. Development is slower and the result is not perfect, however no matter how lame management and business are the show can go on. Scrum and the team will take care of it is practically planning for fluctuation.
If the architect has to manage code quality then you need hire new developers.
Code quality component design, review those are responsibilities of the (senior) developers.
The architect has to manage architectural concerns.
Service level architecture, SLAs, converting strategic Visions to requirements.
He has to be able to code to inspect the general trends og the codebase but he is not responsible.
I believe you are totally mistaken and frustrated with architect position but let me tell you my friend architect is backbone of software industry. If you are easily able to design scalable, distributed and fault tolerant system on your own, you can be architect by definition and Karma.
We also see most of the testers are able to code that doesn’t mean they are only testers they are testers because their profile says so but they can be good developers as well.
You are getting confused with the designation. Some people are architect by designation but not by Karma. It comes with a lot of experience. Sometimes we think we can do better than the architect may be you are right because there are companies who hire blindly and provide designation blindly so if you compare yourself with them that’s your problem.
The comments here defending the architect in software development have pretty much set the record straight, but I can’t help myself from reinforcing it.
I spent several years as an architect and having to help lead 4 software teams of 6-10 developers each. Experienced developers do not equate to sound, flexible, and scalable systems. The reason I was put into the “architect” role was because of my ability to understand integrations in a “buy vs. build” enterprise where there were a lot of tools/platforms that all had to come together at one point or another, and also because “senior” developers had proven over many years of time that they are incapable of making sound decisions for growth and typically want to keep doing the same crap they always have done. I worked with senior devs who literally told me “Well i don’t know about you but i personally try to avoid javascript whenever possible” and that was in the year 2014 when we had already gone way past the fact that JS is now a first class citizen in the development ecosystem.
I also was in charge of developing the overall 3-5 year strategy for application architecture – so things like “how do we plan and manage our migration from Weblogic to Tomcat? How do we right size the cloud for our organization? How do we iteratively tackle technical debt? How do we make our software flexible enough to respond quickly and with quality to the way our particular business rapidly spins up requirements demands that have historically resulted in “all hands on deck” 16 hour work days for 2 months straight?”
Developers don’t understand that broad view and they aren’t supposed to. They are typically more narrowly focused and that is how it should be. They are part of the team and fill a skill gap of “somebody needs to code this!” They are very important and if you try to make them multi-task in such a way that they also do architect-things, they will become far less productive. Developers need focused time to do their coding. They do not need to be interrupted for meetings all day.
I’ve never interviewed a developer in recent years who doesn’t “know about” unit testing, build pipeline/CI/CD, or talk about “quality code”. The reality is developers en masse and like any large group of people – I’ve found that only a few of them actually know how to effectively manipulate these practices. I’ve seen those same devs who talk a big game in interviews come in and write classes with 15 dependencies injected and then end up with 500+ line “unit tests”. When I ask them (as a coaching exercise) what this tells them about their code, they look at me blankly. I can count the number of developers on one hand who actually know that unit tests need to be used to also INFORM you about how complex your code is and give off smells that it should be refactored.
Part of my job as an architect was also to help build the ecosystem that ensures metrics and encourages discussion for code quality because in reality, even experienced developers tend to suck at writing good code. I pushed systems in the Atlassian stack like Crucible and SonarQube and work with the developers to get through the results of the discussion threads from Crucible in code reviews as well as the objective metrics from SonarQube as learning exercises.
I see architects as people who take down barriers. Developers should not have to deal with how new frameworks impede progress. Architects work to smooth that out and empower developers to be more productive. Developers should not have to worry about politics between teams working together on a project. Architects work to smooth those relationships and find middle ground. Developers should not have to worry about having to build the ecosystem for change management that create the gates to production. Architects work to create those tool sets for measuring quality and provide eyes (even to experienced devs) to help raise the overall quality of the codebase.
I think anyone who says we don’t need architects is absolutely advocating for wild-wild-west development where there is no consistency and pragmatism outside of whatever a person has learned/knows and is never going to push themselves to do anything differently. You will have chaos and that has been proven over decades of time, which is precisely why the role of architect was created in the software space. There never used to be architects as we know them today. The role was created because organizations eventually felt the crippling pain of technical debt from egotistical, non-pragmatic “senior developers” who think they can carry the weight of the world on their shoulders just as long as they stay employed as a key-man dependency at the organization. They’ll work 12 hour days to make changes to their horrible code and come in to the standup the next day claiming they are a hero because they worked so late into the night to fix this problem………(that they created but won’t tell you that).
The only reason I see why we don’t need the architect role is because every developer should be one or at least aspire to be one. Ask a senior developer what is the main learning over the years. For me it’s not the languages, the frameworks, or the libraries. It’s the best practices, the principles, clean code, structure. These are architect roles. If you don’t want to call them architects, then call them simply software engineers (they are actually software architects anyway).