3 ms·

Fair points. I would say if it is done well that turnover would go down. I’d think re-architecting from scratch every 4-6 years would be extremely engaging and

by mlac 6y ago

Fair points. I would say if it is done well that turnover would go down. I’d think re-architecting from scratch every 4-6 years would be extremely engaging and keep the role interesting. Or it would be extremely tiring and lead to burnout. Not saying the architects would need to run the application for 3 years - during the three years of run for their cycle they could determine issues with their architecture to fix for next time, work with the other architecture team to make improvements for the next cycle, and perform research for their next design. I think the main drawback is cost - it essentially doubles the cost of staffing for the organization’s IT. I guess there is core functionality that could be shared and stay consistent.

bopbeepboop 6y ago
Not the person you’re talking to, but I want to check my inference. Maybe I misunderstood, but I’m trying to recap your point: The teams are on a 3 year production deployment cycle — 0.5y - design next gen system 1.5y - implement next gen system 0.5y - deploy next gen system 3.0y - production (primary, solo, backup; 1y each) 0.5y - decommission Is that what you had in mind? I think what a lot of people aren’t seeing is what it looks like with multiple cycles overlapping: You begin architecture design on gen3 1.5y after deploying gen1. The coding team rolls smoothly from implementing gen1, deploying gen1, and running gen1 into implementing gen3, deploying gen3, and running gen3. (Assuming minimal coders for the backup phase.) It even works out roughly for promotion cycles: an SDE 1 at the start of implementation for gen1 manages a service as an SDE 2 (2yr experience) and can get promoted to SDE 3 part way through gen3 in time for them to design gen5 (having seen two implement-to-maintain cycles). On the production side, operations are continuous: your 3 years of production overlap with the other team by 1, making the entire cycle for a single team 4 years in length. Your production crew spends their entire time on a commission-operation-decommission loop. There’s no downtime: they go straight from decommissioning gen1 to commissioning gen3. Expense is the negative: each team needs a full set of architects, coders, and operators. But nuclear submarines have two teams for a reason, so I think there’s certain domains where operating two full development teams in lockstep like this makes sense. I think it would help a lot with “legacy” bloat: to have upgrade cycles be a fact of the business structure.
- mlac 6y ago
  I wrote this in another comment, but I should have been more clear. Since this is the discussion about the Exchange hack, I was thinking in the context of large organizations and their internal IT architecture and being able to build from scratch without legacy bloat. The challenge is “how do we run this organization as efficiently and securely as possible? What tools does the business need in place to get the job done? Is our current set sufficient?”. The fact that any company hands a new employee a Windows 7 laptop in 2021 shouldn’t be happening, but a surprising number of Fortune 500 companies are in that state because of legacy dependencies that require Win 7 to operate. I think the ability to give an organization the opportunity to reset every 3 years would keep things efficient, better integrated, and identify legacy issues that often come up and cause emergencies (the guy who wrote that script left the company 5 years ago and it runs on a server under this desk... we just don’t touch it). Right now, upgrading a payment system may be difficult due to certain dependencies or other legacy internal systems. If the whole architecture is being re-done, there is a lot more flexibility.
  - bopbeepboop 6y ago
    Yeah — I agree that it’s an interesting idea. I was trying to understand if I’d pictured what you said right: you have two teams each doing that cycle half a phase out of step so one team does systems 1,3,5... and the other does 2,4,6.... I was picturing situations like finance, data centers, SCADA, etc. I think a lot of people don’t realize that when you have a cycle timed right, your eg architects don’t just sit idle. They’re only on “maintain” for a year before they start on the next system upgrade. It’s a good idea.

by mlac 6y ago

bopbeepboop 6y ago

Not the person you’re talking to, but I want to check my inference. Maybe I misunderstood, but I’m trying to recap your point: The teams are on a 3 year production deployment cycle — 0.5y - design next gen system 1.5y - implement next gen system 0.5y - deploy next gen system 3.0y - production (primary, solo, backup; 1y each) 0.5y - decommission Is that what you had in mind? I think what a lot of people aren’t seeing is what it looks like with multiple cycles overlapping: You begin architecture design on gen3 1.5y after deploying gen1. The coding team rolls smoothly from implementing gen1, deploying gen1, and running gen1 into implementing gen3, deploying gen3, and running gen3. (Assuming minimal coders for the backup phase.) It even works out roughly for promotion cycles: an SDE 1 at the start of implementation for gen1 manages a service as an SDE 2 (2yr experience) and can get promoted to SDE 3 part way through gen3 in time for them to design gen5 (having seen two implement-to-maintain cycles). On the production side, operations are continuous: your 3 years of production overlap with the other team by 1, making the entire cycle for a single team 4 years in length. Your production crew spends their entire time on a commission-operation-decommission loop. There’s no downtime: they go straight from decommissioning gen1 to commissioning gen3. Expense is the negative: each team needs a full set of architects, coders, and operators. But nuclear submarines have two teams for a reason, so I think there’s certain domains where operating two full development teams in lockstep like this makes sense. I think it would help a lot with “legacy” bloat: to have upgrade cycles be a fact of the business structure.

mlac 6y ago
I wrote this in another comment, but I should have been more clear. Since this is the discussion about the Exchange hack, I was thinking in the context of large organizations and their internal IT architecture and being able to build from scratch without legacy bloat. The challenge is “how do we run this organization as efficiently and securely as possible? What tools does the business need in place to get the job done? Is our current set sufficient?”. The fact that any company hands a new employee a Windows 7 laptop in 2021 shouldn’t be happening, but a surprising number of Fortune 500 companies are in that state because of legacy dependencies that require Win 7 to operate. I think the ability to give an organization the opportunity to reset every 3 years would keep things efficient, better integrated, and identify legacy issues that often come up and cause emergencies (the guy who wrote that script left the company 5 years ago and it runs on a server under this desk... we just don’t touch it). Right now, upgrading a payment system may be difficult due to certain dependencies or other legacy internal systems. If the whole architecture is being re-done, there is a lot more flexibility.
- bopbeepboop 6y ago
  Yeah — I agree that it’s an interesting idea. I was trying to understand if I’d pictured what you said right: you have two teams each doing that cycle half a phase out of step so one team does systems 1,3,5... and the other does 2,4,6.... I was picturing situations like finance, data centers, SCADA, etc. I think a lot of people don’t realize that when you have a cycle timed right, your eg architects don’t just sit idle. They’re only on “maintain” for a year before they start on the next system upgrade. It’s a good idea.