Top Down and Bottom Up Design

There are number of ways you can approach a problem and try to solve it – whether the problem is in real life (like building a house, build a craft or product) or in IT (like software to capture business information, workflow or marketing). Two major approaches to solving problems are top down and bottom up design.

Contents of this article are

Methods of Reasoning in Logic?

We have always been trying to logically solve and understand our problems & environment using reasoning approaches. Let’s take a look at two major methods of reasoning in a bit more detail.

Deductive Reasoning

Deductive Reasoning refers to the process of coming up with a theory and trying to prove that theory into a confirmation. In other words, think of it as a way of making vision into reality. When this is applied to problem solving, this branch of reasoning makes sure that we start at a higher level first and gather more details at each of the below levels – fine tuning and solving problems, till you reach your desired outcome. In terms of practical example, think of it as building a bridge or a tall story building. You need to design it first, understand all the requirements and then start building to make it into reality. Advantage of this approach is that you are not bound by anything – since you can start with your any desired outcome and try to get there.

Inductive Reasoning

Inductive Reasoning on the other hand starts with observing what you already have and try to come up with a theory – which can help you with understanding what all is possible and where you can head towards. In terms of practical example, think of it as re-decorating your home or trying to design things (like crafts) based on things you have. In this approach, you are not starting from a clean slate – rather you start with an available component or resource and try to come up with what all you can do with using it. 

 

Top Down and Bottom Up Design in IT

Top Down Design

Top down design requires enterprises to have a vision of what the enterprise needs to achieve – it could be the enterprise strategy, business goals, project goals or any other desired outcome. With this in mind, the problem is divided into smaller components (think of it as solving bigger problem by dividing it into smaller problems and solving smaller problems one at a time) and each of these components are understood in greater detail. Note that no development or coding starts understanding of all the requirements and then you start building components based on the design. 

Simple example you can use to understand this is a company trying to design and launch a completely new campaign or product. You are usually not constrained by anything – you can envision, design and build the product you desire.

With respect to SOA, this means that when a new requirement comes in, first you design the service description or contract. Once the service interface or contract is agreed between all, the code is developed to implement the contract. For example, if you think of web service implementations, top down approach requires you develop the WSDL first (usually done by an architect by hand and it goes through SOA Governance board for approval). Developers will write code to match the WSDL & testers will write test cases to match the WSDL.

Bottom Up Design

In Bottom Up Design, enterprises start with what is already available in the enterprise. Using the existing application or features, the capabilities are made modular (or re-usable), and using this the business problems are solved. Note that in this model, the coding starts first to solve the short term requirements first. After the short term requirements are met, the code is made modular and reused to solve bigger enterprise problems.

Simple example you can use to understand this would be an organization trying to understand what capabilities it already has and launching new feature or services based on its existing capability.  For example, a telecom company trying to launch a new marketing campaign to existing customers. Note that even if you want to launch a brand new campaign, in this approach, we first identify the current capabilities in the organization and try to fit the vision based on the existing application (complete reverse of top down methodology). 

With respect to SOA, this means that the code is first written to solve the project needs – with the desired programming language (like C, C++, Java, etc). Using the libraries (or custom code) the code is exposed as services – which are then reused to solve enterprise needs. In other words, code is written first and then these are exposed as services and used in the enterprise. Since the service generation is usually tool driven, this means that services might not fit exactly to SOA design principles and to enterprise data and SOA guidelines.

  

Conclusion

Some of the things to conclude from this example are:

  • Top down design validates the solutions from day one to conform to enterprise guidelines and governance
  • Top down design speeds up time to market (to some extent – especially with respect to SOA), since multiple teams can work in parallel to solve business problems
  • Bottom up design waits for the code to be written before you can validate the solution
  • Bottom up design forces teams to work sequentially – since code needs to be written before its used by other teams to integrate

Share this:

About Chethan

I am the Founder and Director of Expertz.me! I am an Entrepreneur, Architect, Problem Solver & Techy - All rolled into one!!