Configuring outbound mail / notification providers in tools (just like any other configurations) should be easier as you move higher up the application layer (Think configuring sendmail command line program vs...
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.
Top Down and Bottom Up Design in IT
Top Down 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
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.
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