A quick summary of pros and cons for single vs. multiple ERP solution instances when planning to deploy a global ERP. Considerations are based on experiences with Microsoft Dynamics AX 2012 product. Advantages of one approach often reflect disadvantages in the second.Single Instance Pros
- Cost benefits - potentially less investment required with lower TCO - one instance clearly requires less resources and lower ongoing cost than multi-instance.
- Simplified management - setup and processing of various master data and group's transaction data in same set of rules, (global address book, products), inter-company transactions, consolidation processing etc - by having all data and legal entities stored and managed within the same instance.
- Unlike in previous versions, with Microsoft Dynamics AX 2012 release, various standard AX localizations (different functionality per legal entity) are supported within the same instance and do not require additional deployments for supporting local legal requirements.
- Maintaining potentially complicated dependencies and rules caused by modifications and configurations to meet diverse local and regional business specific requirements. Customization for one region or legal entity can have undesirable dependencies for others. Meanwhile, workarounds exist. For example, create a modification for regional enhancement, which determines the user's region and enables respective customizations in the legal entity he/she belongs to.
- Increased impact of maintenance or failures on all worldwide regions and users. If for any reasons, the production ERP instance shall be stopped for troubleshooting or maintenance, this can affect the whole worldwide users in all time zones.
- Database limitations - scaling out of Microsoft SQL server performance in large deployments and collations issues with storing text fields in different ways.
- Availability of network infrastructure to all worldwide users. Network latency and other network considerations for users in various locations are usually raised when considering single instance vs. multiple an may require additional validation before making the decision.
- Easier to implement and maintain more complex modified solutions where such customizations and configurations for one region and legal entity can cause undesirable effects on others if handled within the same application instance. It is often considered better to separate these into instances.
- Mitigate the impacts from downtime risks or maintenance if production system should be turned down for a some time especially over multiple timezones. Industries like retail and other would not be able to afford long downtime of business critical system in one place for whatever reasons causing it in other regions.
- Solution to some database limitations - ability to scale out Microsoft SQL server to improve performance in large deployments and resolve potential collations issues by separate instance of database.
- Higher investment and TCO caused by additional server licenses or subscriptions in ERP platform, staff (especially, for on-premise case), maintenance and more additional deployment environments (e.g., test, validation etc) required.
- Additional complexity in modifying and maintaining cross-instance customizations since same code might need to be promoted and tested across diverse multiple application instances.
- Maintaining and processing cross instance data and rules is not so straightforward as in single instance. For example, consolidation processing would require additional steps with file exports. Master data integrity across companies might require additional steps or solutions. Master data management solution, such as, Microsoft SQL Master Data Services can be considered. Furthermore, if a company wants to implement a global BI & Analytic solution, this will affect the data warehouse and BI solution architecture.
- Lower impact of downtime since instances are separated.
Lower impact of downtime seems to be a pro for Multiple Instances scenarios?
ReplyDeleteNice article, but I would like to state my experience with respect to the so-considered 'cons' of Multiple Instances. Please note that my company is a multi-entity and multinational group but our Vendor implemented a single AX instance for the whole group, only separated on a legal entity level. Even the concept of partitions in R2 was not applied.
ReplyDelete1. Higher investment and TCO: On the contrary, a company like ours which has grown its DB to several Terrabytes just in 2 years (it's expected to reach 10 TB in next 2 years) will have to implement multiple AOS instances on several machines yet would still be unable to get the required performance (because afterall, a single DB is the bottleneck). We currently have 40 AOS instances on 25 different machines. Yes, that's true.
2. Additional complexity in modifying and maintaining cross-instance customizations: On the contrary, our vendor charged us for every customized report thrice (on average). They managed it by re-selling the same report to different entities. Since they could limit the access to the reports entity wise, they hid all customized reports for entity 1 (on purpose probably) for entity 2 and 3.
3. Maintaining and processing cross instance data and rules: On the contrary, not only our central db has become massive; it has become more complex for us to manage data and rules (e.g. if entity1 wants to make a certain field mandatory, they can't because entity2 and entity3 would never agree to it. In some cases, a certain field is only pertinent to entity1. This means that it fills an unnecessary space in the db for entity2 and entity3. Remember that null values hold the same cost and filled values).