6 ms·

Whenever I hear the title "Architect" I have to think about certain segments of the IT department at my company and also the participants at my scrum master tra

Whenever I hear the title "Architect" I have to think about certain segments of the IT department at my company and also the participants at my scrum master training. Both were full of "senior architects" that were good at talking but were so out of touch with reality that they couldn't contribute anything real. It's pretty easy to architect a system if you ignore the little, annoying details that make an implementation difficult. And to know what's hard you need hands-on implementation experience. These guys get away with their nonsense because often the implementation is outsourced to developers who just implement what they are told to do without asking questions. Never mind that the bad design decisions make the system much slower than it has to be and takes way more effort to implement.

hu3 4y ago
Gotta love those over-engineered projects where to add a text field to an existing form requires editing more than 15 files. So may layers of indirection that debugging is a nightmare and callstacks look like the full lorem ipsum.
- oaiey 4y ago
  That is overengineering and bad technical design. Can happen completely independent of the architecture profession.
  - contingencies 4y ago
    The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. - Joe Armstrong ... via https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
oaiey 4y ago
I am an architect. Proud of my profession. I code only for fun. I do solution architecture in a scope with 100s of impacted developers. I highly suspect that dozens of them are describing us exactly like you do. However, once they challenge us and we elaborate the problem to them, their solution usually falls apart and they align with our solution. Why: because in that scale of complexity we operate in not every engineer can maintain the necessary knowledge. I highly respect the approach of architecture in the team/agile environment and seniority in engineering. But at a given scale, someone is there to orchestrate all of it and does the overall plan. That person is a solution architect.
- Adiqq 4y ago
  How deeply do you go in details with that kind of scope? Do you regularly discuss architecture decision with all these developers, so they're all aware of impact? Do they actually understand impact? How do you actually verify that created solutions comply to architecture? Do you support yourself with solution architects? Personally I noticed, that there's always something to analyze more in-depth, something to document better, yet another thing to teach others, however other engineers that I work with don't really care about creating coherent view of solutions they create and they don't care about providing clear description/instructions/guidelines for their solutions. So do you depend on developers to prepare complete solutions and only verify, if they do everything that you would expect or do you actually have to guide them through details and support them in design, so you can together create something that works according to architecture?
  - oaiey 4y ago
    That is the art. Finding the right degree of detail, communicate and verify it correctly. Adapt to changes and refinements of the engineers. We expect engineers to refine and review the architecture. They are engineers. However, they are busy delivering something while the architects talks with business and define the solution for the next iteration. Solution design takes time, soft skills and expertise. You cannot do that and deliver something. One of our best solution architects is not capable of programming. He holds a degree on physics. But he is good with finding solutions, managing information and also excellent in communication.
- niatrecsa 4y ago
  As someone who has held both roles I agree with this point, though the same vice versa can be said about operating with certain complexity. Developers need to deal with a considerable scale of complexity too, with regards to various technologies and practices, that architects can't be expected to be proficient in. The key to success is your architects and developers having an affinity for each others role and responsibilities, and management ensuring appropriate conduits to keep the two engaged. I've been a solution architect embedded with a team of 4 devs, but was constantly dragged into meetings by more senior architects collaborating on the wider platform we were re-writing. That collaboration was important, but it consumed too much time. At the time I lost connectivity with the developers and they were to a degree twiddling their thumbs while a design was nailed out. Since then I've come to see the benefit of design and architecture stages including the actual developers as much as possible/as much as they want to be included. By that I mean specifically things like getting developers to pair with you on proof of concept work, where you need some form of discovery that will lead to a design decision; pairing with developers on pieces of analysis and documentation around the current state of the system/application, or business/user workflows (in teams where there has been no business analyst). With conceptual/high level design you might not need much developer input, but when you get into the detailed design/logical design dev input can be crucial (especially if you don't know a lot about the current state of a system). When I'm putting together a design I like to go as wide as possible first with the scope, and then fill out the scale of each area with details after further analysis. Getting your developers (if they're available), to help fill in some of those gaps can be beneficial. Getting that early engagement with the actual developers is key, and in my opinion taking a more agile and scrum approach to the architecture is much better than doing all the big design up front with zero developer input and then throwing it over the fence. That said, your development team needs to be geared for this, and some might not be, if all devs are busy delivering feature A while the architect looks ahead at what's next. But if I can get time from at least 1 developer who has a good handle on the current code and tech stack, then that's definitely something I capitalize on.

hu3 4y ago

Gotta love those over-engineered projects where to add a text field to an existing form requires editing more than 15 files. So may layers of indirection that debugging is a nightmare and callstacks look like the full lorem ipsum.

oaiey 4y ago
That is overengineering and bad technical design. Can happen completely independent of the architecture profession.
- contingencies 4y ago
  The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. - Joe Armstrong ... via https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup

oaiey 4y ago

I am an architect. Proud of my profession. I code only for fun. I do solution architecture in a scope with 100s of impacted developers. I highly suspect that dozens of them are describing us exactly like you do. However, once they challenge us and we elaborate the problem to them, their solution usually falls apart and they align with our solution. Why: because in that scale of complexity we operate in not every engineer can maintain the necessary knowledge. I highly respect the approach of architecture in the team/agile environment and seniority in engineering. But at a given scale, someone is there to orchestrate all of it and does the overall plan. That person is a solution architect.

Adiqq 4y ago
How deeply do you go in details with that kind of scope? Do you regularly discuss architecture decision with all these developers, so they're all aware of impact? Do they actually understand impact? How do you actually verify that created solutions comply to architecture? Do you support yourself with solution architects? Personally I noticed, that there's always something to analyze more in-depth, something to document better, yet another thing to teach others, however other engineers that I work with don't really care about creating coherent view of solutions they create and they don't care about providing clear description/instructions/guidelines for their solutions. So do you depend on developers to prepare complete solutions and only verify, if they do everything that you would expect or do you actually have to guide them through details and support them in design, so you can together create something that works according to architecture?
- oaiey 4y ago
  That is the art. Finding the right degree of detail, communicate and verify it correctly. Adapt to changes and refinements of the engineers. We expect engineers to refine and review the architecture. They are engineers. However, they are busy delivering something while the architects talks with business and define the solution for the next iteration. Solution design takes time, soft skills and expertise. You cannot do that and deliver something. One of our best solution architects is not capable of programming. He holds a degree on physics. But he is good with finding solutions, managing information and also excellent in communication.
niatrecsa 4y ago
As someone who has held both roles I agree with this point, though the same vice versa can be said about operating with certain complexity. Developers need to deal with a considerable scale of complexity too, with regards to various technologies and practices, that architects can't be expected to be proficient in. The key to success is your architects and developers having an affinity for each others role and responsibilities, and management ensuring appropriate conduits to keep the two engaged. I've been a solution architect embedded with a team of 4 devs, but was constantly dragged into meetings by more senior architects collaborating on the wider platform we were re-writing. That collaboration was important, but it consumed too much time. At the time I lost connectivity with the developers and they were to a degree twiddling their thumbs while a design was nailed out. Since then I've come to see the benefit of design and architecture stages including the actual developers as much as possible/as much as they want to be included. By that I mean specifically things like getting developers to pair with you on proof of concept work, where you need some form of discovery that will lead to a design decision; pairing with developers on pieces of analysis and documentation around the current state of the system/application, or business/user workflows (in teams where there has been no business analyst). With conceptual/high level design you might not need much developer input, but when you get into the detailed design/logical design dev input can be crucial (especially if you don't know a lot about the current state of a system). When I'm putting together a design I like to go as wide as possible first with the scope, and then fill out the scale of each area with details after further analysis. Getting your developers (if they're available), to help fill in some of those gaps can be beneficial. Getting that early engagement with the actual developers is key, and in my opinion taking a more agile and scrum approach to the architecture is much better than doing all the big design up front with zero developer input and then throwing it over the fence. That said, your development team needs to be geared for this, and some might not be, if all devs are busy delivering feature A while the architect looks ahead at what's next. But if I can get time from at least 1 developer who has a good handle on the current code and tech stack, then that's definitely something I capitalize on.