Hacker News Reader

Comment by br3w5 | Hacker News Reader

It's certainly true that if someone in a an architect position does not know the technologies intimately then how can they make informed decisions about it.

They can certainly maintain consistency at a high-level e.g.this next solution will have a REST API, but people still shouldn't be making those decisions without a detailed understanding of the impact of those decisions. I have seen devs move into a pure architect role but as time goes on it does become apparent that they need to be closer to the detail.

I think the definition of architecture should be a dev team effort with the architect role making the final decision (be that lead dev, CTO, whatever job title for that person).

I like the idea suggested in the thread of making the architect a product team/project role.

View on HN

An architect, at least one worth his title, does not work in isolation.

The article talks about a type of architect that I call tech lead. It has as much to do with the architecture process as a front-end developer has to do with mechanical engineering.

There are many types of architect, with vastly different roles and functions within an organisation from pre-sales to business strategy so I strongly argue that people should stop looking to become architects as a step up from being engineers in the same way that fashion models should stop looking at picking up acting as some sort of a graduation when when they get too old for the catwalk.

Some can do it because they have picked up enough knowledge and insight along the way but, for most, it's a new career with a whole new set of skills and responsibilities.

An architect needs to keep learning in much the same way as developers do. I would look to this person to make the decision on the high-level system design/architecture for each solution. I think they should also be pushing the dev team to look at new tools and technologies, and it would really help if they had some understanding of those technologies.

I think there is a similar debate (but from a different angle) around should your project manager or scrum master be technical. Obviously an architect should be technical but how much familiarity should they have with the technologies being implemented. I would say they should have a good understanding of them.

There is some benefit to being conceptually removed from low-level technology concerns, in that the architect won't get caught up in design patterns intrinsic in the technologies the devs want to use, that could actually be detrimental to the overall design - the old 'the devs can't see the wood for the trees' argument.

A technology architect should be technical and be able to keep himself on top of new developments in his area (software, networks, storage, etc) as well as having a good solid understanding of the adjacent or related areas. The focus is how newer and greater things fit together into the big picture.

A solutions architect looks over the fitness for purpose and is accountable for the delivery at project level which means that he might have to make decisions (together with his stakeholders) about which technology, framework or methodology to be employed in order to ensure the deliverables are mapped to the requirements with minimal or no slippage. The focus is business benefits from technology.

An enterprise architect is a whole different beast and I'm not even going to go there at this stage. I'll just say that being technical is as useful as being tall in that it makes for a good first impression but does not correlate to quality or effectiveness overall.

I am of the opinion that everyone involved in IT should have a good understanding of the past, present and future of technology as well as a systems thinking capability that allows one to understand how different systems interact and react to his own area of expertise. The balance of knowing how to do it and why do we do it is the difference between slave labor and expert work.

>I think the definition of architecture should be a dev team effort with the architect role making the final decision (be that lead dev, CTO, whatever job title for that person).

I find the quality of decisions made by a single person in this role are never as good as decisions made by team consensus.

Architecting is by its nature a job that often requires subtle and delicate trade offs, and the more you concentrate the role in one person, the less experience you have to draw upon to make those trade offs.

I find that giving somebody authority to make the final call when there is still team disagreement is something of a false economy, too. The whole idea that discussion should be minimized for 'cost reasons' is how a lot of fantastically expensive bad decisions get made.

Yes but the reality of decisions is that one person needs to drive that decision - a group of people will often struggle to make a clear decision every time

Agreed, but that person doing the driving is often different from one discussion to the next.

And it's better that way - especially when people speak up about issues that they personally feel invested in or passionate about.

This has been my experience, anyway.

I've had "architect" in my job title for ~15 years and I'm very clear that my job is not to make the key technical decisions, but to facilitate the process for making these decisions.

Agreed. An architect should be a knowledgeable generalist able to facilitate the discussion. Personally I'd hate to be the "smartest guy" in the team about anything.

However I spend a large part of my work days collaborating with all different stakeholders and different subsystem vendors and what I as an architect bring to the table is the requirements based on the context of the subsystem we work on. Rest of my days I design, code and debug just like the rest of the team.

Reply on news.ycombinator.com