Enterprise Architecture Value Model - Staff the embedded practice correctly
Enterprise Architecture Value Model
Chapter 21. Staff the embedded practice correctly
The effectiveness of your Level 3 practice depends entirely on the quality of the people in it. The staffing profile is specific and non-negotiable — it is not the same profile as a strong architecture practitioner working in a governance or standards role.
The Delivery Track Record Requirement
Every architect in the practice must have personally owned delivery outcomes — not reviewed them, not advised on them, but owned them. They must be able to point to systems they built, programs they led to completion, and technical decisions they made and stood behind when conditions became difficult. Architects who have only ever operated in advisory roles do not have the credibility to walk into a program in crisis and take on architectural ownership. The programs this practice engages with are under stress, populated by experienced delivery professionals who will quickly identify whether the embedded architect can operate at their level. Your Chief Architect and Head of Software Engineering are responsible for identifying, recruiting, and developing practitioners who meet this standard.
Small, Senior, and Selective
The practice should be deliberately small and deliberately senior — typically two to five principal-level architects operating at the highest level of technical and delivery credibility your organization can field. Resist the temptation to build headcount. Build capability. A team of two outstanding delivery-credible architects will consistently outperform a team of eight advisors operating at a safe remove from delivery accountability. The selectivity of the practice is part of what gives it organizational credibility — it is the team you call when the situation is genuinely serious.
The Handoff Discipline
The practice does not permanently own the programs it engages with or the systems those programs produce. Every engagement has a defined conclusion: the program is stabilized, the delivery commitment is met, the architectural recovery is complete. At that point, the practice formally transfers architectural ownership to the appropriate domain leaders and moves to the next engagement. This discipline is essential — a practice that accumulates permanent stewardship of delivered programs quickly becomes a maintenance function rather than an intervention capability. The at-risk queue is never empty. The practice’s value is in what it fixes and releases, not in what it holds.
Copyright for the International Foundation for Information Technology (IF4IT): 2008 - Present
Legal Disclaimers