4 ms·

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

by ukigumo 12y ago

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.

br3w5 12y ago
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.
- ukigumo 12y ago
  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.

by ukigumo 12y ago

br3w5 12y ago

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.

ukigumo 12y ago
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.