How many modules should be in one Model general?




I'm planing to re-factoring our client's Models as some Models have over 100 modules which is not easy to maintain. Please advise how many modules should be in one Model in general.



Hisashi Yamaguchi



  • Hello,


    100+ modules, in and of itself doesn't sway me one way or the other.  In most models, regardless of the number of modules, there are a handful of workhorse modules containing the most complex logic (or otherwise taking up the most space and/or resources).  Therefore, the number of modules isn't determinitive.


    I typically will separate (an activity or activities) into separate models based on the following factors (in no particular order):

    1. Data Loads - If a model is properly performance-tuned, but is still very large, I will consider opportunities to break an activity or process out into a separate model if it will improve end-user experience.
    2. Multi-user environment - If the user count is very high, I'll consider ways to break models up into logical buckets (this is often related to activity, but can be based on user groups also).
    3. Logical groupings to simplify administration - I work with FP&A models.  Its happening more and more that we view the various FP&A activities (for example, Revenue & COGS Planning, Workforce Planning, Opex, Capex, etc) as independent activities that we may choose to split into separate models.  More and more, clients want Workforce managed in a separate model.  The chief considerations here include: the amount of data, the number of concurrent users, how we expect the model to grow over time (lists and users), customer preference, and complexity of the individual processes.  
    4. User Experience - This is really important.  What good is a model if users struggle?  For smaller FP&A builds, I like to keep the entire process in a single model so that users can see their full budget/forecast roll-up real-time.  Also, having all of the process navigation in a single model (in my opinion) makes things easier for end users.


    Let's see what others have to add!



  • The number of modules is not the primary design feature to solve for.   Focus on useability and the overall manifesto of the use case.  Be especially aware of redundancy and inefficiencies in modules which negatively impact performance and user experience, i.e. don't repeat module structures (line items).