Architect Your Company for Agility

Reading Time: 6 min 



Our expert columnists offer opinion and analysis on important issues facing modern businesses and managers.
More in this series

Recent operational issues at Tesla Inc., the future-forward electric-car maker based in California, serve as a reminder that a great strategy is valuable only if a company is capable of executing that strategy. And whether or not a company can execute its strategy depends largely on whether it is designed to do so. In other words, it depends on business architecture — the way a company’s people, processes, systems, and data interact to deliver goods and services to customers.

As companies now develop digital strategies, they are invariably promising integrated customer solutions. These strategies will be especially difficult to execute because so many organizational elements must be synchronized to deliver an integrated solution. And it’s not just the number of organizational elements that makes digital strategy execution difficult. Speed matters. To keep pace with customer demands and competitor moves, companies must be able to quickly experiment with a potential offering and, depending on customer response, continuously enrich and scale that offering, or discard it and move on to the next experiment.

In other words, business architecture just became more important — and more difficult. In the pre-digital economy, business architecture most often focused on operational efficiency — designing seamless end-to-end business processes. That is no longer sufficient. In the digital economy, business architecture must also focus on agility — designing rapid reuse of individual business components.

Organizational agility won’t happen by accident. It must be architected.

Innovating at Speed Means Utilizing Empowered Teams

To facilitate speed, companies must design themselves to minimize the obstacles to getting work done. This requires empowering and supporting problem-solvers.

To this end, growing numbers of companies are creating small, cross-functional, agile teams. Each team owns delivery of a digital offering or a set of services contributing to an offering. Typically, teams clarify their own objectives and define their metrics for success.

Spotify AB, the digital music service, serves as a model for many companies’ forays into empowered teams. The Stockholm-based company relies on small teams, called squads, to deliver product features and related business components. Squads are assembled into tribes that provide major offerings and capabilities, such as online music offerings or services in support of artists or advertisers.

The concept of continuous release is essential to the effectiveness of empowered teams. At Spotify, squads release new digital features and offerings as quickly as they become viable rather than conform to scheduled release dates. Rapid innovation depends on teams learning quickly what does and doesn’t work. Empowered teams experiment, and the best teams learn how to rapidly respond to the outcomes of their experiments.

These teams don’t fear failure. In fact, critical to the concept of empowered teams is that when experiments fail, company managers do not assume responsibility for dictating how to fix things. Instead, they act as coaches, posing questions and eliciting hypotheses and expected outcomes.

Failed experiments are essential to learning. If an entire concept is deemed a failure, the team can be disbanded and reassigned to a new initiative. This helps to keep team formation fluid. Unlike traditional organizational structures, a design built on empowered teams is in a constant state of change.

The Critical Role of Alignment

Empowered teams invariably contribute innovation — and high energy — to companies. The challenge is ensuring that the efforts of individual teams align to achieve company-wide objectives. Our research at the MIT Center for Information Systems Research has identified three mechanisms for achieving alignment: (1) clear missions, (2) common business components, and (3) fruitful knowledge sharing.

Missions provide direction, both at the enterprise and at the individual team level. At the enterprise level, a clear mission or vision statement establishes priorities for the entire organization. It directs teams’ innovation efforts by clarifying the objectives of the company’s investments in resources. At the team level, mission statements define how the team will contribute to the company’s goals.

At Spotify, managers told us that the company defines a small set of “big bets” that establishes enterprise priorities based on beliefs managers derive from their data. Individual teams then state missions to help achieve the big bets. For example, the mission of a music delivery tribe is “providing fast and reliable access to all the world’s music.” The mission of an infrastructure tribe is “enabling high product development speed while maintaining a highly available service.” A clear mission will guide a team’s choice of metrics, so that the team can easily track its progress in contributing to the enterprise mission.

To respond to changes in customer needs or market conditions, companies can redefine missions at the enterprise or individual team level. Restating a mission enables a company to adjust priorities without necessarily requiring changes in organizational structures.

To ensure alignment across teams, companies need to embrace reuse. Reusable business components such as on-boarding processes, dashboarding, and payment systems, facilitate integration and speed. New business capabilities build on existing capabilities and provide consistency across offerings.

For example, the Dutch electronics company Philips is building digital offerings to enable seamless health care for its hospital clients in accordance with a vision to “build a healthier tomorrow.” To support this effort, an internal platform team reviews all propositions for new digital offerings to distinguish unique business needs from common needs. The team then establishes a road map to ensure that common business components are available when needed.

Technical standards are essential to business component reuse. Standards for application programming interface (API) development, for instance, ensure that teams approach development of their business components so that they are API-enabled and available through the company’s catalogue of internal services.

Finally, empowered teams depend on knowledge sharing to coordinate their activities and share their learning. It appears that when it comes to sharing knowledge, the more mechanisms a company deploys, the better.

Spotify relies on what it calls chapters, guilds, and agile coaches. Every Spotify squad member is assigned to a chapter, which is usually organized around a single competency, such as graphical design or back-end development. Chapter members meet to discuss issues and ideas specific to their roles, which leads to more coherent technical decisions. Guilds bring together people with common interests to share the latest discoveries in their domain and develop specialized skills. Agile coaches, who facilitate team dynamics, can recommend best practices observed in one squad to others.

Other companies rely on weekly stand-up meetings where teams inform each other — and other people in the company — about their deliverables and learning. And many companies provide collaboration tools for communicating within and across companies. These tools are designed to provide transparency and move away from command-and-control approaches that attempt to distribute information only on a need-to-know basis. Although initial attempts to provide transparency can lead to concerns of information overload, people on empowered teams eventually learn which people and tools are the most valuable — and therefore which to pay the most attention to.

Learning How to Architect Your Business

Most companies are still learning how to architect for efficiency. To do so, they must design people, processes, systems, and data that discipline their core operations.

As they learn to architect for efficiency, however, companies must also start learning how to architect for agility. This means designing empowered teams, as well as the systems, data, and processes that ensure the synchronization of individual teams’ efforts. These business architecture efforts will ultimately allow for rapid delivery of integrated customer solutions.



Our expert columnists offer opinion and analysis on important issues facing modern businesses and managers.
More in this series

More Like This

Add a comment

You must to post a comment.

First time here? Sign up for a free account: Comment on articles and get access to many more articles.

Comments (3)
Michael Poulin
I used to follow Dr. Ross for the last 12 years and admired her work. However, this article has disappointed me a lot. Digital is a means, it does not become the ends and we have to approach it from Business Agility to Market. Particualrly,

"business architecture — the way a company’s people, processes, systems, and data interact to deliver goods and services to customers. I was shocked with this ancient view. These “people, processes, systems, and data” have nothing to do with ‘architecture of business’ (which in English means “business architecture”).  These entities are elements of Architecture implementation while actual Architecture of Business comprises intrinsic architecture of business system and business capability-based architectural solutions, i.e. practice of Architects who design business organisation.

“To keep pace with customer demands and competitor moves, companies must be able to quickly experiment with a potential offering and, depending on customer response, continuously enrich and scale that offering…” is required regardless any digital or not-digital strategy.

“In the digital economy, business architecture must also focus on agility — designing rapid reuse of individual business components” – well, this quite out of the point. Digital economy is nothing more special than a factor of accelerated change of market, that requires much stronger agility of business organisation to the market. Individual business components are not frequently reused because of the unique (not standardised) nature of business; these implementation business components are hidden among resources of business capabilities.

Business practitioners know well that problem-solvers are not small digital cross-functional, agile teams.  Modern agile development teams are seldom cross-functional; usually there are several such teams are involved. 

We have to focus on how to make these small disconnects digital agile teams to work not on what they want , but on what the company needs. Effectiveness of individual team is important, but their empowering has to be reasonable. We have to stop “waiving tail” before these teams – they have to do what they were hired for.  Innovations are also important, but not all companies can afford related risks, i.e. digital revolution may not be recklessness, it should be on a leash.

I do agree that modern company should be architected, not an IT only, but the business first, including its structure, operations and TOM. Information Systems are still enablers and supporters. Architects of Business (not Enterprise Architects under the CIO) are and will be the drivers. An agility to the highly dynamic market requires changes in many traditional methods and interpretations of familiar things and methods, where digital is an important but not the only thing that has to be agile to the market.
Robert Merrill
It's interesting to think of an onboarding process as a reusable component, but I guess it is. Thanks!

How many of these reusable business process components and APIs were planned that way, and how many emerged from a process like refactoring of a code base?

In Cynefin framework terms, is an Architected for Agility firm one that has learned to operate in the Complex domain?
Iason Onassis
Excellent article with practical explanation of approaches and why they work. Next to Teams, mission and re-use I would add governance, business model and financing for the different teams at the different levels as also being key.
• Some need to create features (or products),
• some need to drive the business, i.e. growth and profitability, and
• some need to enable re-use and speed.
These are different entities with different goals and therefore should be managed, financed and measured differently.