In 2009, the world changed. Before then, businesses around the world were forced to choose between speed and quality. IT leaders and dev teams would all repeat what was essentially the same narrative to their business counterparts: “Do you want it done fast, or do you want it done well?”
The belief that speed and quality were mutually exclusive outcomes was unquestioned in many organizations. What changed in 2009 was when Flickr showed organizations you could have both speed and quality. This was a foundational moment in the DevOps movement; it proved that investments in automation can help delivery teams optimize for speed and quality simultaneously.
One area where enterprises still struggle to gain alignment is in the governance of distributed delivery teams. The tools for democratizing the creation of digital assets and capabilities have never been more advanced and ubiquitous than they are today, but the tools and approaches to governing delivery at the edge are only recently gaining traction. A few of these are MuleSoft’s industry-leading approach on Universal API management and the release of advanced low/no-code automation tooling within Anypoint Platform.
As IT leaders work through the sets of topics and decisions to further their transformation and democratization initiatives, it is important to remember a key axiom that tech professionals have relied on for several decades: “technology doesn’t solve problems; people do.” What this means in this context is that an enterprise technology team must align on a conceptual framework for the ways of working in the new democratized world of technology development and operations.
Time stays long enough for anyone who will use it
As people and society become more capable of measuring and harnessing every second of the day, organizations are shifting their thinking to optimize their development methodologies and processes around the compression of cycle time and developer productivity. While very few people will argue that optimizing productivity is a bad thing, not everyone agrees on a single model for how to do it best.
MuleSoft has long been obsessed with delivering speed through democratization and is no stranger to the discussion on organizational models for how to align the worlds of rigorous innovation and safety at scale.
Most MuleSoft customers have heard about the Center for Enablement (C4E) approach as opposed to its forebearer the Center of Excellence (COE), but not everyone jumps on board with the change as it often touches on finance, reporting structures, governance, and approval chains. The C4E structure can be thought of as a hybrid between a platform and an enablement team.
This hesitancy isn’t necessarily a bad thing, as not every organization is ready to digest these types of changes and it isn’t even a sure thing that this model of distributed delivery is right for every organization and economic context. In light of the difficulty that some teams have on picking a model that’s right for them, the MuleSoft team has put together a simple guidepost (pictured below) so that decision-makers can align their distributed delivery methodologies with their near-term and long-term business goals.
The grid above compares and contrasts the needs of different organizations along two axes: compliance and scaled development. The mapping is as follows:
- Center of Excellence (COE): A hybrid of “platform team” and “stream aligned team” which can sometimes struggle with scaled demand from consuming lines of business
- Center for Enablement (C4E): A C4E team is a hybrid between a “Platform Team” and an “Enablement Team” that is explicitly designed to support scale and governance by enabling external Stream Aligned Teams with standards and reusable tools/components.
- Centralized development: Centralizing all development in one broad IT team doesn’t correspond to any archetype from Team Topologies and is counter to many of the specific best practices that help to drive scale, governance, and highly productive flow-oriented teams.
- Away teams: A “stream aligned team” that is equipped with guidelines and conventions when working with components built by other teams.
One aspect to notice as you compare the different approaches is to understand that the models are semi-overlapping and do share some specific competencies between them. The point here is that regardless of whether we’re talking about MuleSoft or any other shared SaaS/PaaS technology in use by your enterprise, there are several competencies and activity sets that are required in order for your enterprise to reap the benefits of a shared foundation.
To get a deeper understanding of what the implications are for each of the options above, you can compare and contrast each of the team methodologies relative to typical goals for an IT or SDLC optimization organization.
Advanced topologies for complex needs
As organizations scale their offerings and the industries or use-cases their applications support, the complexity of how they manage their application infrastructure scales as well.
A common method to support emergent technologies while being able to control the chaos that can come from bespoke approaches to technology stacks and methodologies is to establish a COE where one team is granted a license to author and execute upon a set of standards for a conceptual area.
Along this line, many enterprises have chosen to establish a DevOps center of excellence to provide CI/CD infrastructure and a standardized tool chain to all development teams within an enterprise.
While the COE model might be more familiar, it may not align with your enterprise’s needs for scale. For example, if your enterprise is one that is built through frequent acquisitions, rationalizing and re-platforming different applications and delivery teams isn’t always a welcome task. On the other hand, your enterprise may have the need to support a wide variety of industries with different expectations on just how close to the bleeding edge your delivery teams need to be fluent with.
In this context, having a single standard model for teams where the lead time for a centralized team to evaluate and master new technologies and approaches is a non-starter for business units that must respond to the ever-changing competitive landscape. It is in these more complex environments that more decentralized models should be considered.
Without getting into the deep organizational aspects of federated/dedicated staffing models, the two conceptual models to consider within our grid are the Center for Enablement and away teams.
Center for Enablement (C4E) team model approach
If your organizational goals are to emphasize scale and compliance without sacrificing speed, a C4E model is a great choice for achieving that outcome. A fully-staffed C4E team will be a manifestation of a fusion team, where cross-functional and multidisciplinary team members from different parts of an organization work collaboratively to advance project goals (short-term) in balance with enterprise goals (long-term).
Advantages of a C4E approach
The C4E approach shines on long-tail efficiency and compliance. While the implementation of a C4E can vary across enterprises, the main goals usually remain the same: work together to produce and promote shared standards, best practices, assets, components, and methods so that other consuming teams can leverage those reusable resources and components which then accelerate their time-to-market while not wasting time or infrastructure resources.
Enhanced governance is baked into the design of the C4E approach. While teams at the edge have the autonomy to investigate and innovate with new methods and technologies, they do have the responsibility to bring these new methods back to the C4E to ensure there isn’t unnecessary redundancy while also giving back to the core for other teams to leverage what they’ve built out.
Lastly, a specific competency and responsibility that is identified as part of the C4E charter is to provide evangelization to the wider organization, so that the scaled benefits that come from wider adoption are perpetually realized and compounded.
Disadvantages of a C4E approach
Given its matrixed nature, enterprises can sometimes struggle with developing a financial and reporting model to support the C4E approach which can result in the team being short-handed in capacity. This problem, however, may not actually sustain given the recent support of fusion teams by Gartner. As more enterprises align to fusion team models, teams with matrixed funding and reporting structures may become more common across industries.
The away team model approach
The away team model was developed and made popular by Amazon. This type of structure uses “stream aligned teams” to engage with code and componentry that may come from anywhere in the enterprise.
Based on the external reporting for how the away teams concept works, the disciplinary or cross-functional makeup of the team isn’t a consideration or differentiating topic and “Away Team” is more of a set of expectations and mode of work where an outside group can develop against code made and owned by a different team.
Where a C4E is chartered around speed and scaled governance, away teams focus more on ownership and decision rights in an effort to drive short-term speed above all else. There are mechanisms and mitigations that root out duplication and inefficiency over time, but these are secondary concerns in the Away Teams model.
Advantages of an away team approach
The Away Teams approach shines on short-term effectiveness and rapid decision-making. The core goal in Away Teams is to reduce and eliminate shared dependencies from teams and roadmaps. This singular focus allows for clarity in decision-making and lets distributed teams have almost complete control over their own destiny.
Disadvantages of an away team approach
The creation of reusable shared assets may indeed come out of an away teams model, but they are not an explicit objective of the methodology. As such, away teams may struggle at operating on a technical infrastructure that has more duplicative capabilities and more varied patterns for solutioning. While the decision-making models may seem easy to emulate, the labor and talent models at Amazon are not easy to replicate.
Choosing wisely doesn’t mean everyone chooses the same thing
What’s wise in one context isn’t necessarily wise in another. The key to making a good choice from the set of team topologies lies in two factors: knowing your choices and knowing yourself. Each of the more complex topologies has advantages and disadvantages, but neither of these aspects is sufficient to make a decision without understanding the maturity and commitment of your organization.
If speed, governance, and scaled democratization are core requirements for how you model your delivery capabilities, a C4E approach may be the right path forward. If this is the path you’re choosing for your organization, remember that the sword cuts both ways.
Just like the problem where the tools and technologies won’t be successful without a solid approach from a committed team, chartering the team with an ambitious objective, but not giving them access to a comprehensive toolset with advanced sharing and governance features built-in won’t necessarily get you to the promised land either.
The entire MuleSoft organization is committed to helping our customers be successful by delivering not only a world-class product platform that can scale to meet the expectations of the most complex environments but also in helping organizations align and formalize on the development methodology that will scale with their unique needs.
