I’m working for a client that has separate teams for architecture and engineering. Architecture is responsible for defining the long-term direction of the platform and engineering is responsible making that dream a reality, in addition to their day-to-day sprint work. Each engineering pod has a representative from architecture as one of its members but their role is mostly about producing documents and interfacing between the two teams - they don’t touch the code at all.
This architecture/engineering interface is a constant source of tension and I believe this is because the two teams have misaligned objectives.
- Engineering are responsible for delivering value for the business
- Architecture are responsble for defining the strategic direction of technology within the enterprise
Lines of business versus shareholder value. Those are aligned at the top of the house but on the ground, they are not.
Architecture have to rely on the engineering teams to implement their vision because architecture do not have their own implementation teams. The engineering teams are trying to serve two masters: product and architecture, but only one of them has the budget to pay for their work. And there’s the rub.
Architecture approach their work by defining significant changes in a single deliverable, like switching from an outdated on-prem Identity and Access Management (AIM) system to a modern cloud-hosted alternative. They weigh the alternatives, discuss with stakeholders, document the strategy, and get it approved. The question is more interesting than the answer because their role ends once an answer is reached. It’s a step function.
Engineering view problem-solving through an iterative, evolutionary lense. We start with a rock and gradually shape it into a diamond through incremental improvements. We start with an MVP, gather metrics and feedback, refine, repeat. The line is a gradient.
DevOps evolved to reduce the tension between Development and Operations, creating empathy on both sides and encouraging them to work together towards mutually-beneficial outcomes. My client needs an equivalent movement for architecture and engineering. ArchEng? EngArch? Whatever .. naming is hard.
Encouraging architecture and engineering to do each others’ jobs occasionally would go a long way to fostering empathy between the rival factions. Architecture should be responsible for funding and building their initiatives, and seeing them all the way to production. Engineering should be responsible for proposing architectural changes to serve the business, and running the gauntlet of “selling” this within the larger enterprise, and communicating the plan accordingly.
I’ve implemented this in the past by standing up a “platform pod” staffed with both architects and engineers, and everybody codes, everybody designs, and the team is funded by both parts of the organisation. They work on long-term strategic improvements to the system. They don’t work on features. They’re responsible for the entire lifecycle of architectural updates, including review boards, coding, integrating, testing, deploying, and (most importantly) decommissioning the predecessor. They straddle both worlds.