This content is part of the Essential Guide: ALM best practices for advanced DevOps organizations

Choosing your application development strategy

Which is more effective: the top-down or bottom-up application strategy? Tom Nolle explains why choosing one requires an in-depth understanding of application requirements.

Every software architect, development manager and developer has probably run into the "top-down versus bottom-up" debate in software design and development. The right answer is there is no single best approach.

Applications are built with both top-down and bottom-up approaches, and proponents of each method are at odds with those who support the other. But deciding which application development strategy an organization should take requires a review of both requirements and resources, consideration of how the application might change, an understanding of the two unifying approaches to application design, and risk-mitigation steps.

Modular programming concepts and enterprise architecture have both influenced software development to start at the top, with business requirements and expected benefits. In practice, this means listing the business goals, framing these in very general software terms based on a division of functions that map to worker behavior, and then dissecting these functions downward to align with hardware and software requirements. For the last 10 years or so, this has been accepted as the best method for application design.

Top-down and bottom-up explained

Top-down application design and development is also easier to coordinate with the organizations and workers who will use the application. People understand what they do and how they do it, meaning they identify with a function-driven view of an application. If you start with that view, you can solicit input from line departments on the utility of your approach, and also gain insight into how business-practice changes over time might influence software design.

The problem with this top-down approach comes about when a project's goal also includes utilizing a specific technology or set of resources -- especially the cloud. Applications are not automatically optimized for the cloud; they have to be designed to take advantage of the special features of the cloud and avoid cost traps. By starting at the top, it's possible architects could end up producing something that's not well-aligned with the platforms and hosting options that were targeted from the first. A bottom-up approach ensures hosting and resources are used appropriately.

A bottom-up application development strategy is easier to align with a component library that was developed through the use of service-oriented architecture or microservices. If you can assemble an application -- or a large part of one -- from existing software components, then development burdens and ongoing application lifecycle management requirements are eased. A top-down approach can lead design in a direction where current component models are less useful.

The approach debate

Experienced development teams have learned to accommodate this application development strategy debate of top-down versus bottom-up in many ways, but two basic approaches stand out. One heavily considers either resource or platform goals as coequal to functional requirements, and the other more of a "meet-in-the-middle" approach.

It's easy to see that if things like a need to optimize the use of current componentization models or prepare for cloud computing were elevated to requirements, then application design could include these needs from the start and accommodate them as much as needed. However, not all development teams have found it easy to mix functional and technical requirements at the highest level of design. How does the goal of utilizing the cloud align with the need to support a specific work behavior? If that question can't be answered, then there's a tendency to prioritize one set of requirements over the other. This can lead to a design that has very limited utility.

The "elevate" model works best when business requirements are fit into a presumed application model based on the resource, platform or component reuse goals. For example, a basic software model of a Web front end that manages the specific system-to-worker relationship linked to a set of application processes that address the functional needs of the organization can frame development enough to make reuse needs visible, while not compromising functionality.

In the end, it's best to pick the approach that aligns with your primary goal, and then take steps to ensure that you don't lose touch with the other side.

The "meet-in-the-middle" approach assumes platforms and components create a toolkit that can be abstracted upward into a set of technical behaviors. For example, available components can be assembled to update databases or complete reports. These higher-level behaviors can also be related to cloud features, such as horizontal scaling or instance replacement, in case of faults. While they are not likely to be directly mapped to the functional needs of a new application -- or there would likely be no need for a project -- they are more functional than primitive technical requirements. An architect can then compose the second or third level of the design based on these behaviors.

The question with the behavior-based, meet-in-the-middle application development strategy is how to reflect behavior awareness upward, without letting the low-level issues dominate. The best way is to start assembling useful behaviors from the bottom, and then make them available as tools to the architects who are starting functional design from the top. This approach works best when there is a very explicit set of top-level functional requirements, which might be obtained from a good EA model. Without very strong functional requirements, it's easy to let the design process be dominated by bottom-up exploitation of resources and component strategies.

The bottom line

Top-down designs readily align applications with business goals and optimize worker quality of experience, but they can create suboptimal componentization and limit the application's ability to exploit technologies, such as cloud computing. Bottom-up designs optimize resource and componentization utility, but can stray from optimum worker quality of experience. In the end, it's best to pick the approach that aligns with your primary goal, and then take steps to ensure that you don't lose touch with the other side.

Next Steps

How app development models are shifting in the face of the cloud

The three IT hurdles associated with DevOps

Test your knowledge of app development trends

Dig Deeper on Development platforms