One of the most concerning trends we’ve seen lately is the nearly complete elimination of architecture teams. We’ve unfortunately seen several clients go down the path of eliminating architecture teams (usually before we are called in) and all of them experience the following issues given enough time:
- Inability to define and build platform solutions.
- Difficulty with service interoperability in a microservices or SOA framework.
- Difficulty with long-term product planning and feasibility studies.
- Problems with component availability and scalability.
- Skew in architectural patterns and approaches between teams leading to competing technologies (and companies) doing the same things, often times better and doing them at a lower cost.
- Difficulty identifying and applying patterns that lead to success and anti-patterns that avoid repeating past failures.
- Skew in standards applied to development that lead to a lack of repeatability across teams and an inability to apply best practices to improve performance over time.
- An overall increase in cost to develop and time to market for deliver
The reasons for abolishing an architecture team often seem sound, but those reasons only address the symptoms of an underlying problem – not its root cause – and further in the abolition new and greater problems arise. Below is a list of some of the more common reasons for architecture team elimination.
Common Reasons Cited for Eliminating an Architecture Team
- Reason 1: Conflict or lack of trust between the architecture team and the engineering or product management teams.
Real Cause: The teams lack role clarity as well as goals and incentives that align them to customer facing outcomes. Too often architecture teams are implemented as “ivory towers” that are out of touch with both engineering and customer needs. The solution isn’t to abolish the team, it’s to create cross functional engineering teams.
- Reason 2: Lack of autonomy or perceived lack of autonomy within the engineering teams (aka the “GSD” or Get Stuff Done teams).
Real Cause: Empowerment is like any other word; it requires a definition for the context within which you operate. As leaders and executives, we must be clear as to what empowerment means and for what a team is empowered to do. This correct definition often is “empowered to achieve outcomes assigned to the team while staying within the principles and standards we’ve set for every team and using the tools we’ve decided to leverage across teams”. This statement helps ensure teams understand that they are NOT empowered to significantly increase the costs the company incurs by making independent decisions that increase technology and process skew (and therefore costs).
Further, teams often do not feel empowered when there is another “decision maker” outside of their team – one that the team feels overturns decisions and slows down delivery for little perceived value. The fix for this is to ensure that the notion of team identity is fortified by ensuring that architects are embedded within the teams and that the architect, engineers, product owners and QA personnel feel that their allegiance is first to the “GSD” team -see the link above for our white paper on developing cross functional teams.
- Reason 3: Slow time to market – stalls and/or significant rework owing to architectural reviews.
Real Cause: The rework and slowness are likely a result of engineering teams not adhering to standards and patterns. It may also be due to teams designing solutions that will cause quality of service problems. If neither of these are the case (in other words if the rework has no value to the company), then you have the wrong architecture team.
Either way, the fix isn’t the dissolution of the architecture team, but rather embedding the right architecture team members into the GSD teams. Doing so means that governance of principles, patterns and anti-patterns will happen in real time rather than in waterfall phase-gate like reviews.
Having discussed the common reasons cited for eliminating an architecture team, let’s now discuss the reasons you absolutely need an architecture team.
Reasons Why You Must Have an Architecture Team
- Cohesive Architectural Strategy
Sending independent and empowered teams off to develop solutions without an architectural blueprint to drive component interactions and without architectural principles, patterns, and anti-patterns to govern their endeavors is a recipe for disaster. Where else, in any engineering endeavor, can you envision teams independently building components without a clear high-level design? The best-case outcome for this scenario is a working albeit “Rube Goldberg”-looking contraption; the solution may perform but it’s going to look like it was never designed to work together and will likely suffer in availability and scalability overall.
The worst-case outcome, and most likely outcome, is that you find yourself with increasingly late delivery as teams try to struggle with each other to define interaction characteristics between architectural components. Similarly, you will run into availability problems and increasing costs as teams reproduce each other’s work and drift apart in terms of technology stacks, languages, and ways of operating. Welcome to Frankenstein’s world. You just created a monster and it’s going to be painful to instill order in your world of chaos.
Put simply, if you want components of your solution to work together, you must design them to work together. That means you need to create some notion of an architecture team responsible for high level design of your product.
- Forward Looking Product Guidance
Product managers can’t do their job in a vacuum. In creating product roadmaps and team backlogs, they need help thinking through the ways to approach various opportunities. This help takes various forms including helping the product manager think through what’s possible and helping them word stories and epics to ensure that the engineering team has multiple paths to success in implementation.
While you could use engineers from the delivery teams to help with this, in doing so you are reducing the capacity (and therefore the velocity) of those teams by limiting the amount of time an engineer has available to spend on design, coding and development of his/her solution. A better approach is to ensure that you’ve paired architects with product managers to help them with the technical aspects of their job. These architects are also ideally embedded within the delivery teams, but their responsibility for hands-on coding is lower than that of an engineer assigned to that team freeing them up for work on designing component interaction, principles, standards, and patterns to be used by all teams.
- Definition and Governance of Standards, Patterns, Anti-Patterns and Tools
To ensure that you consistently hit your high goals in terms of time to market, availability, cost of development, cost of operations, scalability, and latency you need a single team responsible for defining, teaching, and governing your principles, standards, patterns, anti-patterns and tools. Failing to define, teach, and govern you will move slowly to inconsistent practices, inconsistent outcomes and high costs of delivery as tools and processes drift apart.
- Definition of Cross Team Interfaces and Services Contracts
While intimated in the cohesive architectural strategy need above, this point makes clear that you are best off with a single team defining the contracts, APIs and approaches necessary for two teams to interact. Failing a single responsible team, you will rely on multiple teams to (best case) slowly come to a consensus or (worst and more likely case) struggle to come to a consensus in the necessary time. When designing a product, it’s best that a one team be responsible for consistently defining (but not necessarily developing) the interfaces over which interactions happen between teams.
- Platform Definition and Platform Design
Go ahead and try to build a compelling platform without a team responsible for helping product management define the independent components necessary to bring that platform to life. If you let independent teams attempt to define componentry without a team responsible for the overall technical outcomes, we can almost guarantee failure. In fact, we’ve seen well over 20 such failures within AKF across our client portfolio.
Successful platform design requires a team to define the componentry and interaction characteristics to be successful. The right team to do that is an architecture team.
Chaos, Autocracy, and The Empowered Cross Functional Team
Pendulum swings seem to be an unfortunate (and unnecessary) part of organization construction over time. The pendulum always seems to swing between complete centralization of services (alternatively called the Autocracy Region or the Warring Tribes Region) and the complete decentralization of services (the Anarchy Region or the Lack of Governance Region).
You are much better off, when building product organizations, to let the pendulum rest in the middle. This gives you the balance
of real time governance and cross functional team empowerment while avoiding the pitfalls of a lack of standardization, inability to perform forward looking design, and increased costs.
By embedding architects into cross functional teams we can handle the tactical day to day needs or the “transmission” of our product while also facilitating the forward looking strategy elements (the “engine”) necessary to allow our company to maintain competitive advantage long term.
Put another way, you need a group of individuals (a community) that can focus on both the long term strategy and the short term implementations. Attempting to do this through multiple teams, with each team developing a non-coordinated strategy for their component is disastrous as a cohesive picture of that strategy across all elements will not emerge.
The Best Way to Organize an Architecture Team
Our white paper on team organization is the best place to understand the concepts and approaches to building a cross functional team.
Here we will only summarize bullet points necessary to accomplish the tactical day to day needs of your product and the strategic future of your product:
- Align architects to the Agile Delivery Teams (the GSD teams) that do daily work.
- Ensure each team sees the same architect for all needs, both tactical and strategic.
- Architects make all standups and all other team ceremonies including helping with backlog grooming.
- Architects contribute to the code base and/or the infrastructure activities to show that they can do “real work” and to help build their primary identities (both how they see themselves and how the team sees them) as part of the GSD team.
- 30 to 40% of an architect’s time is spent as part of the architecture community – pairing with product managers to discuss future capabilities and refining standards and principles based on practical implementations.
- 60 to 70% of an architect’s time is spent within the delivery teams helping with design to ensure that “governance” of approaches is done in real time and not at repeating intervals that stall progress.
The resulting approach should look like the diagram below. Remember – the “primary” identity of the architect should be within the delivery team, with a portion of their time reserved to work with the broader architecture community and with product management on forward looking capabilities.
Additional key points:
- The architect “community” (or functional group) should be lead by a strong architecture leader helping to organize the architect activities across GSD team alignment (70%) and PM/Architecture work (30%).
- The architect leader should be responsible for the portion of individual architect reviews dealing with “HOW THEY WORK” and what they get done as part of the community, whereas the GSD team leader should be responsible for evaluating their results in the team.
- The community must both meet as a team for principles, patterns, anti-patterns, and cross cutting designs such as platform definition as well as with the product management community for helping with future facing product capabilities.
Need help with your organization construction? Having difficulties with your architecture team or failing to meet your objectives because you don’t have an architecture team? Call or contact AKF Partners – we can help!