Move to the Package Development Model
Learning Objectives
After completing this unit, you’ll be able to:
- List the benefits of modular architecture.
- Explain how unlocked packages enable modular architecture for Salesforce.
- Describe Conway’s Law.
- Explain how to align teams, packages, and the value you deliver.
The Benefits of Modular Architecture
You can make many improvements during your DevOps journey. One of the most challenging—yet powerful—is moving to a modular architecture.
When we build systems, it’s easy to focus on one piece at a time and overlook the bigger picture. But systems that grow to have dozens, hundreds, or thousands of components become increasingly unpredictable and hard to understand, unless you start with a thoughtful architecture.
Salesforce metadata is a system of interconnected components. Each time a piece of metadata references another piece of metadata, the reference establishes a dependency. When thousands of components are connected, you get a tangled web of dependencies like that shown in this diagram.
We say this network of dependencies is “tightly coupled,” because parts of the system can’t exist without other parts. “Loose coupling” is when multiple systems can interact but don’t directly depend on one another.
One of the biggest risks in Salesforce systems is that you accumulate too much tightly coupled code and configuration.
Salesforce makes it easy to connect any part of the system to any other part. But keeping components independent wasn’t always easy. Before Salesforce introduced unlocked packages, enterprises didn’t have a simple way to create long-lasting boundaries between components in an org. Without package boundaries, metadata tends to develop complex interrelationships, and you can’t subdivide it easily. We call such systems monolithic; to understand them, you have to analyze the details inside them.
A modular architecture, on the other hand, organizes metadata into a small number of modules. You can understand a modular system at a high level by looking at its modules and how they connect. Modules organize system details into simpler units.
If you have a monolithic architecture, you can’t always predict the impact of changes you make. Development teams need to coordinate their work carefully and do extensive testing to make sure they don’t break anything. This problem gets worse the more metadata you add.
Moving metadata into unlocked packages reduces this complexity, and reduces the need for teams to coordinate deployments. Unlocked packages establish clear, long-lasting boundaries between groups of metadata. Such boundaries limit risk. If you make changes to only one package, you impact only that package and any dependent packages. Teams can deploy independently of one another, and your organization can innovate more quickly and safely.
Migrating to Unlocked Packages
You can learn how to create unlocked packages in the Build Apps Together with Package Development trail. If you develop a new, independent Salesforce app, you can use unlocked packages from the beginning. But if you want to divide existing metadata into packages, you have to do some gradual refactoring.
To build an unlocked package, you use a scratch org. Unlike sandboxes, scratch orgs don’t contain metadata from other orgs. Because you can’t push metadata to an org if it's not valid or is missing components, pushing metadata to an empty scratch org confirms that you can package it.
The Package Development Readiness module gives great tips on how to move to packages. And if you’re working in a complex org, you need advanced techniques to adopt unlocked packages, including Apex enterprise patterns. You also want to think about how your team structures and package structures relate.
Conway’s Law
In 1967, Melvin Conway made a simple observation that influenced a generation of software architects: The structure of systems reflects the structure of the organization that builds them. The book Team Topologies combines that insight with other research to offer recommendations, summarized here, on how to structure both your teams and architecture.
Stream-Aligned Packages and Teams
In the Salesforce DevOps with Copado module, we looked at how you identify the value your Salesforce applications bring to different groups. Your IT organization serves many different internal and external customers, building different customizations for each group. Think of the customers you serve, and work backward. What metadata do you create and maintain for each group? By dividing metadata into packages aligned to the teams you serve, you set a clear boundary and define the “product” that you deliver to that customer.
After you think about your architecture, think about your teams. Several people may work together to maintain each package. Some work with business stakeholders to understand their needs, others build configuration and code, and still others test the changes. By organizing your teams around specific packages—"stream-aligned teams"—you align team goals around delivering value to a particular customer.
By aligning team structure with architecture and architecture with value delivery, you free each team to innovate on the customer’s schedule.
Platform Packages and Teams
Salesforce comes with standard objects like Account, Contact, User, Case, and Opportunity. Your organization may also have custom objects, utility classes, and other customizations that multiple teams use. Shared metadata is effectively a “platform” for the teams that depend on it.
To manage this platform, establish a platform team to implement requests from the stream-aligned teams. Since platform metadata impacts many teams, changes to this metadata require more time and care. Keep platform metadata as small as possible.
The Two-Pizza Rule
When teams grow larger than five to eight people, coordinating work gets harder, and the extra difficulty erodes the benefit of adding more hands. Consider adopting a two-pizza rule: no team gets so big that you can’t feed everyone with two pizzas.
Conway’s law suggests that you should also keep your packages from getting too big. You want modest-sized teams working together to build modest-sized packages, so you have an architecture you can maintain. When things get too big, it may be time to break them up.
Enabling Teams
With small independent teams aligned to your architecture, you can innovate more quickly and safely. You may also want to form enabling teams to train and assist other teams as your organization gets comfortable with DevOps, packaging, and other new practices. These enabling teams can also share insights and experiences across the organization.
Org-Level Metadata and Management
While unlocked packages reduce complexity for your teams, you still have to manage some metadata and package installations at the org level.
The Salesforce DevOps with Copado module describes how to use a tool like Copado to create an org-level metadata pipeline. Copado also lets you track package versions and systematically promote package versions to testing and production environments.
Continuous Integration on Scratch Orgs Using Version Control
In the org development model, you use version control and automated deployments to set up continuous integration between development sandboxes and an integration sandbox. But deploying to and from sandboxes is slower and more complex than using version control alone to integrate.
Fortunately, in the package development model, you need only version control to perform continuous integration and share changes quickly and easily. Create a simple branching structure and make sure everyone merges and integrates their work with the main branch at least daily.
You can then use a tool like Copado to automate test execution in a scratch org. You can automatically run a subset of Apex unit tests against the code in the main branch every time that branch changes. You can also automate the package publishing process. For example, you can automatically publish a new package version when you add a tag to a commit in version control. 
You still need to install package versions in a sandbox to test them and make sure they’re compatible with other packages, unpackaged metadata, and other org configuration. Sandbox environments provide a production-like environment that enables more realistic testing.
