As software programs grow larger and more complex functions are added, maintenance of the code base is a big challenge for Independent Software Vendors (ISVs). New upgrades, version releases and go to market strategies are greatly dependent on how quickly one is able to make the desired usability improvements and fix from previous releases. In this competitive age, it is commonly seen that a B2B software release is made once every 12-18 months and a B2C software release happens every 6-12 months. With such short turnaround times, modular programming aided by separation of concerns helps ISVs manage their code better and greatly reduce their coding and testing efforts between releases.

Modular programming aims to divide the entire gamut of functionalities offered by the software product into various independent modules. The modules are by and large self- contained. A higher level module may use one or other modules, but at all times, there is a logical separation of concern in terms of the functions each module performs. This logical separation between modules ensures that discrete functions of the product can be developed independently and in parallel thereby accelerating development time. Bugs or defects in a module are easy to detect and fix and the risk of defect regression is almost zero. Separation of concern is achieved by using suitable architecture framework like MVC which clearly separates the presentation layer from the Business logic. The Business Logic can further be modularised by adopting a Service Oriented Architecture.

One major challenge faced by product teams when doing deployments for different customers is each of them is on a different version of the product. There are specific changes requested by one or a set of customers while others don’t want the changes. When a new feature already implemented for an existing customer is requested by a new customer and if there is a monolithic design with no separation of concern, the developers tend to spend additional effort and there is also duplication of code. A modular approach will simply include the interfaces already built for the module.

Similarly, an ISV entering a newer market will have to customize only those features relevant to the new market (changing the skin and other attributes like currency, language etc.) reusing the core Business functionalities.

ISVs looking to extend the lifecycle of the product can easily embed newer features without having to drastically alter existing code. They can simply switch off unused interfaces/modules and call the newly built interfaces/modules.
Product Managers don’t have the clarity on how requirements for future versions would shape up while defining requirements for current version. A modular approach to design will keep the product open to changes.

Sample Case study:-
An application offered by bank to a SMB consolidates bills set up in various accounting software. A workflow for payment and approval is provided. A single login screen authenticates the user based on role and directs to the application to which he has access. A dashboard gives a consolidated picture of pending bills and payments made. Search feature is available whereby user can search bills or payments by vendor name, associated documents, bill/payment amounts or the associated due dates. User can run reports by defining a date range. The application branding can be customized for various banks.

The initial release only had the core functionality of syncing the application with accounting software.The dashboard, common login, the search and reports features were added in 3 subsequent releases. Number of lines of code in base release: Approx 80000. We have seen an average reduction in effort to the tune of 34% on subsequent releases for an application following modular design to an application without one.


At Aspire, Modular programming is one of the key elements of Producteering practices and we use this approach for modernizing software products.

For more information, please mail me at