Why Vertical Slice Architecture makes sense

Software development projects are often complex units of work. Often the reasons for the complexity are not always down to what needs to be developed or implemented but often it is most often due to the fact that what actually needs to be developed is not always known upfront. Often the final solution evolves only after several iterations and interactions.

I've worked on many projects, where the clients often don't know what the solution they need is exactly, but strangely they often do have specific time-frame deadlines when the solution should be in place. Often this is because the deadline will actually be determined externally from the project itself and the projects primary focus is to implement a solution to meet an objective. These types of projects are potentially Regulatory or Compliance objectives, new vendor or customer integrations, market conditions, new business opportunities etc.

At the start and even often throughout most software project, it is common for software development teams simultaneously seeking to understand the goals of the work while also creating a game plan to meet the goals of the project. More often than not teams don't know exactly how to accomplish the work when they start, often focusing on working on the problem while creating the solution as they go.

Agile software development is often about embracing change where goals often evolve and shift, resulting in the work to change to meet the goals.

Working against deadlines in software development is entirely normal and often results in a lot of pressure. Teams have to balance work with due dates.

Businesses often have due dates that are real and justified. For example, when new legislation is implemented or other hard deadlines that are inflicted on the business outside of area of immediate control.

In the modern business environment businesses will continue to face torrents of change, market evolution and this will continue at a blistering pace. Business drivers such as mergers and acquisitions, increased competition, increased consumer demand, increased innovation which will all incur changes to a myriad of computer systems. In many cases these changes in computer systems will consequently necessitate changes to the underlying architectures supporting them.

The leading questions for most teams in this situation are:

• How to approach work in an environment like this?
• How do you write user stories to mitigate the issue of being up against tight deadlines?
• What practice will help you write better user stories?
• How do you structure your technical solutions to cope with constant change?

Common problems in software development

• Deadlines often appear to be define arbitarily
• Deadlines are too short
• Work is not understood
• Work is often in too many big chunks to get continuous feedback and incremental updates
• not enough time to test
• Working on things that don't necessarily provide value
• Deadlines set by those not involved with the details of the work required
• Work done without real user interaction and understanding of what gains value
• Work is too complex in order to enable starting the work.

It's not only businesses undergoing constant and rapid change, it's also the technical environment in which computer systems reside. Containerisation, the move to cloud-based infrastructure, adoption of DevOps and even new advancements in continuous delivery pipelines all impact the underlying architecture supporting them.

Software architecture must constantly change and adapt to meet the new demands of modern business and technology environment.

undocumented features

It is very common for software projects to be kicked and started with a number of assumptions or as some like to call non-functional requirements. These are the things that stakeholder etc, will assume that it should go without saying that the new software project will deliver. These are also often referred to as the -ilaties which are

• Observability
• Maintainability
• Scalability
• Evolvability
• Reliability
• adaptability
• Availability
• Extensibility
•  Portability
• Elasticity

What is Vertical Slicing

A common approach used when writing user stories for new systems is to write stories in terms of a Vertical Slice through a system. Vertical Slicing is where you slim down a work item to a narrow focus i.e. breaking work into smaller manageable chunks. This mean focusing on a piece of the system that works on its own. All the pieces have functions that are stand alone, and may not require more features to be useful.

Work items have just enough scope and functionality, plus just enough coverage across all system components involved to be truly functional. The important aspect is that once the feature is completed the system offers some immediate value

All pieces of the system components to be included so that the work can function with this new piece of work

The work item takes piece of the layers, that together deliver a piece of work without being the entirety of any of the separate layers.

Vertical Slicing the across the system layers are key to the consistent delivery in Agile Software Development

Incremental delivery is about consistent, progressive and piece meal progress. With the focus on delivering fully functional features at regular time intervals. This helps to focus on the quality because the work is small and can be easily managed.

What problem are we trying to solve?

Benefits of Vertical Slicing

Getting value sooner

Work is not tied to any other pieces of work and can be delivered entirely on their own, because it has been purposefully broken down into stand alone work items.

This enables teams to focus on highest value items without waiting on other work items that can be done separately and later.

Easier work prioritisation

Higher priority items will deliver higher value. Organising work into smaller vertical slices of work, you can start to understand relative value amongst all the work.

Increasing value over time

Consistent delivery enables you to build value over time

Building understanding

Using vertical slicing it becomes easier to understand the value in the backlog.

Consistent feedback

Doing vertical slicing helps to create a better feedback loop. Feedback is one of the most important building blocks in Agile Software Development. Getting good feedback, consistently and frequently you will end up building the right things and delivering tremendous value.

Avoid working on things of low or no value

Working on smaller pieces of work you enable more frequent course corrections.

If you end up starting work on lower value items, once you deliver this and get feedback your team will be able to determine that it is of lower value and be able to adjust course and move on.

Enables response to changing business priorities

Often business priorities and requirements can change. These may often require the team to adjust and chagne direction. The changing priorities are often directed by potential value to be gained by the organisation being able to shift focus or adapt.

Enables just enough work to meet goals

Vertical Slicing enables you to complete just enough work on something to get value required.

Vertical Slicing user stories is about providing value and doing so step by step. It is all part of incremental delivery to the stakeholder and users. Gain value faster when you boost delivery.

Incremental delivery enables quick timelines. Work can be done in short sprints. Incremental delivery opens the door to good feedback loops, helping with faster learning from the team. Incremental delivery allows for changes along the way. It is flexible and responsive to changing needs and requirements. Responding to change helps the team to build the right things.

What is Vertical Slice Architecture

When developing software applications we typically discuss the features of the application with stakeholders. These are typically the actions or expectations of the what the system needs to be able to accomplish. Developers tend to think about the application’s code in terms of its features, and how they fit together. Discussions about code will hardly ever focus on which layer the code sits in. Ultimately the feature as a whole is working or it is not.

In practice, I find this is especially true when it comes to developing REST based API and services. We never discuss the technical layers below the endpoint, but rather we always tend to discuss the desired functionality that the feature as a whole should deliver.

In How to Implement Vertical Slice Architecture I provided an introduction to Vertical Slice Architecture and how you could start implementing it in dotnet rest based API projects, making use of the API Template Pack. In my opinion, Vertical Slice Architecture is the technical morphing of the concepts of Continuous Architecture and Vertical Slicing.

When we think of applications conceptually we often think about them in layers, with each layer having distinctive Technical concern, which traditionally has always mapped to well to the software architecture of Layered Architecture. The design philosophy of this architectural pattern is that the complex task of communication is broken up into simpler sub-tasks or modules. Each layer performs a subset of the required communications functions. Each layer is dependent on the next lower layer to perform more primitive functions. Each layer in turn provides services to the next higher layer, which in theory at least means changes in one layer should not require changes in other layers.

The layered architecture pattern closely matches the traditional IT communication and organizational structures found in most companies, making it a natural choice for most business application development efforts. 

Software Architecture Patterns - Mark Richards

In the Fundamentals of Software architecture, this pattern is discussed in detail and ranks fairly high for simplicity and ease of use. It is also the pattern many developers will intuitively implement when starting a new project. However, as detailed in the book this pattern ultimately ranks low in all other criteria. In my direct experience it is also a very poor choice of pattern to implement in the ever changing world of Enterprise Applications, Cloud native and Distributed Architectures.

The problem with the layered architecture approach is not only limited to the application architecture it is also often that Product teams may start to think in layers when it comes to the overall architecture of the application.

I have discussed in, why I don't like Layered Architecture when implementing Microservices and API's, this is primarily comes from that as a contractor/freelancer I frequently come across this architectural pattern having being implemented then experiencing exactly the same shortcomings that architecture provides, especially when it comes to implementation of REST-based API's. It is important to add that, I am not entirely against Layered or the Clean Architecture patterns, they are still great patterns, but they can also lead to much complexity, indirection & abstraction when your project may not need it.

It is now a common experience in most software projects that developers no longer work on one big monolithic project of layers, its far more common now for projects to consist of multiple packages and even the interaction of multiple services.

Vertical Slice Architecture for development

Vertical architecture focuses on features. Developers organize the code base by grouping all the technical concerns for a particular feature. Vertical slice architecture is beneficial because it:

• Connects all of the layers necessary for a feature
• Groups the code, thereby simplifying the process of editing or removing a feature
• Makes the code more cohesive

Vertical slicing is beneficial in other forums, such as business operations, because it encourages interconnection between various project elements.

Conclusion

Vertical slicing will improve the quality & outcomes of your projects resulting in making your work process more effective, regardless of whether you are a project manager, software developer, video game designer, or business owner.

Offering stakeholders and users a view of every aspect of a project rather than a glimpse of only one small piece, you can invite more useful feedback, demonstrate your success more effectively, and offer value far earlier in the process.