I’ve recently been writing about different approaches to project planning and software architecture, and how they can impact software development projects – for better or for worse. With the evolution of processes and methodologies over the last decade, it’s important to keep up with the latest and greatest, whether it’s to improve your own personal knowledge or evaluate ways to improve your team or product’s efficiency and capabilities.

Splitting initiatives into horizontal or vertical slices at first glance may seem like a methodology for distributing workload, but dig a little bit deeper and the choice can encompass many facets of software development, including architecture, project management, team communications, and technologies implemented.

There are definitely strengths and weaknesses to either approach, and one method may work better for specific environments than the other.

Before discussing horizontal and vertical slices, let’s discuss what is being sliced – the application layers defined within the software architecture.

Defining Application Layers

The slices to be divided are based on the application layers. Traditional software architecture defines the 3 main components of your application to be the Presentation, Business, and Data layers.

Presentation Layer

The presentation layer contains the user interface and communications to the business layer, also commonly known as the “front end” of applications. Thanks to modern front end development languages, some of the business logic can be offloaded to the presentation layer, reducing the amount of resources utilized by the other layers.

Business Layer

The business layer contains the core functionality of the application, including majority of the business logic for processing and manipulating data received from the data layer. As part of the “back end” of your application, this layer is the middle layer between the presentation and data layer.

Data Layer

The data layer controls the storage and allocation of the data, usually in database tables – although some databases will use non-relational allocation methods. Also considered part of the “back end”, databases in some more modern applications are divided into smaller, more lightweight data stores to provide more efficiency.

Service Oriented Architecture (SOA)

With the growing demand of Software as-a-Service (SaaS) platforms, architecture has become more complex and reliant on web services and APIs – enough so that these services add their own additional layers to SOA design. There are many ways people define SOA layers, but since these additional layers revolve around communications, the layers focus on the services and integration with other internal and/or external components.

Moving onto the next topic of discussion is the layers themselves.

Most people are familiar with the straightforward horizontally sliced methodology. To properly understand this concept, I’ll break down the differences between the more commonly used method of horizontal slice project approach.

Defining Vertical Slices

The concept for breaking up project work into vertical slices is often associated with Scrum and Agile processes, and is a more modern approach to breaking out your tasks into smaller, more manageable pieces.

Since, as implied, the slices divide the application layers vertically, the slices include all functionality of a particular feature from the back-end to the front-end. The vertical slices should be small – anywhere from a couple days to complete to the duration of a sprint. The work completed doesn’t necessarily have to be an entire feature, and usually isn’t. Once the work is completed, it’s immediately ready for integration and testing, and the teams can move onto the next challenge.

This approach brings a wealth of benefits to software development projects, and paves the way for quick feedback, defect discovery and resolution, and adaptability to changes in requirements. The small slices are also easier to define, estimate, and test.

While you will have a technology roadmap with milestones to accomplish with each phase or release, the slices are usually not divided and distributed until near the end of the current sprint. This constant recurring planning requires a great deal of meetings and communication, which helps keep the project on track with less opportunities for surprises along the way.

There are also many more opportunities to implement different architecture designs and development practices available to you. The building Microservices is an example of architecture that pairs well with horizontally sliced applications, since the core concept is also about breaking down applications into smaller services that operate pseudo-independently of each-other by using web services to communicate. The pseudo part of that is because they will rely on data from the interconnected services to be a fully functioning feature, but they will contain their own server resources, databases, and code repositories.

One of the less tangible benefits is how an environment with less of the traditional limitations and restrictions can spur innovation within teams – whether it be learning new technologies or having more initiative to deliver higher quality code, in my experience vertically sliced teams tend to be more driven than their horizontally sliced counterparts.

(article continues after break)

(continued)

Vertically slicing also brings many of its own challenges due to the added complexity of the process and architecture.

With teams split across multiple sets of technologies – front-end, back-end, and everything in between – developers must be more cross-functional, often requiring them to be of the full-stack variety, or at the very least edge more out of their comfort zone while working with other team members. Finding and retaining this talent is also difficult, and requires a sound vetting process, good compensation, and plenty of perks to keep them there. It’s not surprising that vertical slicing is popular with tech startup companies.

A situation that is very difficult to approach with vertical slicing is when you have large, legacy applications that are distributed across the enterprise. Moving large development teams over to a new process in complex environments is already challenging, and vertical slicing may be an entirely new concept to some, if not many of the development resources on hand.

Conclusion

Both horizontal and vertical slicing have their own use cases, but it’s evident that vertical slicing allows for many new possibilities of a more modern, adaptable architecture while enabling and empowering teams to produce a superior product.

Horizontal slicing still maintains its usefulness for maintaining legacy applications in which it doesn’t make financial sense to undertake the time-consuming effort of re-organization to a vertical sliced approach, or for technologies that simply can’t be divided efficiently that way, such as mainframes.

Moving forward with modern best practices is essential for innovation and producing scalable, maintainable solutions. Is vertical slicing right for your project or product needs? It’s certainly worth considering.