A common pattern observed when solving problems is to split pieces of work vertically instead of horizontally.

When is business value delivered?

In order to achieve a meaningful piece of work, you need to work across multiple domains. However, value is not found in the individual work done in each domain. Value is produced when work is orchestrated across domains.

For example, consider that you want your users to add products to a cart. Such a feature might include tasks like:

• Create an “Add to cart” button in the UI, that makes an API call to the backend
• Create the backend API
• Test the integration of the backend and UI together
• Roll out the feature in production

In many organizations, these tasks are tracked separately with different individuals performing each task. Such a split of tasks is called horizontal slicing. Yet, none of these tasks produce any business value by itself for the end customer. Value is only produced when all tasks are complete and the feature is finally usable.

Vertical slicing a problem helps you to treat business value as a unit of work. It is a way for you to divide and decompose your work into smaller chunks. It allows you to work on a high level problem, rather than complete a disconnected low-level task.

Vertical slicing is a general pattern

Now, there are many instances where vertical slicing as a concept is usefully applied:

Stories

Vertically sliced stories are a mainstay for agile teams. “User Stories” start by capturing a small slice of the user’s requirement into a story.

The problem with vertically sliced stories is that the slicing is difficult when a relatively simple story (based on the end-user experience) hides a lot of the underlying complexity required to make it work. The solution is to “thinly-slice” the story skillfully. This is more of an art than a science, and experience goes a long way in successfully thin-slicing stories.

DevOps

While definitions of the term “DevOps” vary, the original and the most useful definition is that of a full-stack team with developers picking up skills to work on Ops tasks.

With developers working across both the domains, a very deep Dev/Ops horizontal split is resolved. Work is now done along vertical lines.

Some advantages of DevOps are:

• Developers using development practices to approach Ops problems
• No more “throwing over the wall” of developer output to the Ops team
• Optimum solutions to problems across the stack

Team structures

There is a tendency in organizations to start off with horizontally sliced teams, for e.g. Frontend, Backend, DBA, Ops, etc.

The inefficiency of such a split is encountered the moment value is to be delivered in a project. A project requires people from all these roles to work together to deliver something meaningful for the customer.

Instead of splitting teams in this way, prefer splitting based on business domains. Identify domains of work in your company and create teams that are a vertical slice across roles and self-sufficient to deliver value independently.

Microservices

Microservices is an architectural style that structures an application as a collection of services that are organized around business capabilities. The alternative is a monolith that bundles a lot of disparate business capabilities into one big service.

Monoliths have certain problems:

• Because of he high density of features, it becomes progressively unmaintainable.
• There is reduced flexibility to adopt alternative technologies that are better suited to solving a particular problem. For example, once a monolith starts using a database, all features end up using the same database. It is difficult to adopt a different database for a new feature.
• A localized issue with a service can bring down your entire application.
• Scaling the monolith involves horizontally scaling memory and CPU. Sooner or later an upper limit will be reached.

To fix these problems, we can vertically slice various business capabilities within the monolith and carve out various microservices. The microservices are independently scalable, and issues are localized and easily fixed.

What makes horizontal slicing inferior?

• Working on a specific domain continuously can make you lose sight of the high-level goal. This may make you blind to certain optimizations or you might end up with some wasted effort.
• Having different people work across multiple domains in parallel means that there is more effort to bring all the pieces together at the end. This may result in delayed feedback. It also defeats the purpose of continuous and early integration.
• It makes it easy to be more invested in the specific domain instead of being invested in the problem. You end up creating bureaucratic groups of people with lots of infighting and turf-wars.
• For a product owner, it is difficult to see the larger picture of progress and reason about priorities. The board is filled with tasks that are “low-level”, which impairs the ability to work on high-level structuring efficiently.

Not a panacea

With all that said, there are some situations where blindly choosing vertical slicing is not a good idea:

• You have a team full of specialists, and very few generalists
• When you need to go very fast with a well-understood solution and there is more value in working on different domains in parallel
• When you require dedicated focus in certain domains. For e.g. in Google, scale is a pervasive problem that requires dedicated focus in the form of SRE teams.