Over the years, I have been involved in a lot of discussions with colleagues and clients about the deployment topology of Dynamics AX. Should we deploy as single-instance or multi-instance? For many people the answer was a no-brainer: single-instance, because logically it should provide the lowest TCO, if we only have one system.
However, in my experience, this argument often isn’t true as I would try to explain further down in this blog post. At this stage it is worth pointing out that until version 2012 R2 we have not been able to deploy single-instance if the solution was used across multiple regions, because some regions such as China and Russia could not be combined in the same instance (for technical reasons). Since this is no longer the case, I will, for argument’s sake, assume that we are now free to deploy as we see fit.
For the purpose of this blog post, multi-instance is defined as more than one instance of the Dynamics AX application deployed within the same corporation whether it be hosted on locally or centrally placed hardware.
Before I start discussing the arguments, I would ask the question: Why would you deploy Dynamics AX as a multi-instance solution in the first place?
In my experience smaller businesses with few business units and limited geographical reach should never consider deploying Dynamics AX as multi-instance, but for larger corporations with diverse business units and a significant geographical footprint, it might be the best way to go for a number of reasons, but the main one in my experience is:
When Single-Instance Works
In a single-instance deployment the requirement for aligned business processes and master data structures is significant and not many businesses have achieved this level of alignment before commencing the ERP implementation. Therefore the ERP project becomes the change agent for business harmonization and most times, timelines and budgets do not allow for this causing the projects to fail or at least not meet their objectives.
Let’s be clear about this: in a lot of scenarios, single-instance is the best option!
- If your business is not diverse and
- If you have harmonized your business processes and
- If you have a fairly harmonized and normalized set up master data
then single-instance deployment is for you. Especially if you are deploying to a limited number of business units (5-10), you should be able to create the necessary harmonization to allow single-instance deployment.
Also, if your manufacturing mode is Make-to-Order or Configure-to-Order, the advantage of using an integrated system with intercompany relationships is likely to win the argument for single-instance deployment because you automatically receive the manufacturing data such as BOM, routing and configuration.
Clearly, if you are not able to answer yes to the three questions above, you need to consider the pros and cons in relation to your deployment topology. If you processes are not harmonized before your start the ERP implementation project, they are very unlikely to become so by deploying the same system to all business units. You are more likely to create disruption by forcing business units to align to business processes they are not ready to adopt and could prove inefficient for their business set up.
If you seek to implement the same processes across manufacturing, distribution and retail business units you are likely to create inefficient and even broken processes because a single system will struggle with this diversity range without creating exceedingly cumbersome processes.
The “Writing Mods Once” Argument
Most people would argue that writing a modification once and deploying it to all business units is more efficient and on the face of it, this argument is true. However, if you are a large business where all stakeholders need to have a say in the design and every subsequent change must be governed and retested across the whole business maybe the TCO isn’t quite as attractive. As part of your topology assessment, consider the time you expect to manage modifications across a five period before deciding.
The “Template Deployment Only Works with Single-Instance” Argument
Many businesses implementing Dynamcs AX would like to design and build a template with subsequent deployment across the business. This is, for obvious reasons, a lot simpler if all the business units use the same instance of Dynamics AX and therefore the same processes. However, consider this common business structure scenario: the business has three distinct divisions namely manufacturing, distribution and retail. In that case the concept of a common template across these diverse businesses does not necessarily make sense. I will not discuss template based deployment in this blog post, but just point out that there is a relationship between deployment topology and rollout strategy.
The “Upgrades Will be Less Expensive” Argument
Potentially this is true, but in my experience it never seems to be the case in reality. Upgrading modifications that have been written to serve multiple purposes never seems straightforward nor does it appear easy to upgrade a system that contains the full corporate transactional database. With a multi-instance approach you can stagger the upgrade process allowing a more generous data migration window.
OK, so now I have made a lot of arguments in favour of multi-instance deployment and it is time to put my preferred approach across… I am actually going to put my money where my mouth is.
What Would a Multi-Instance Deployment Topology Ideally Look Like?
In the following picture, I have tried to outline what I have found to be an ideal topology for businesses looking to deploy multi-instance Dynamics AX. The example is based on an example business with individual manufacturing, distribution and sales / retail business units – likely to be distributed across the globe. Obviously, this is only one example, so the point is that the business and geographical spread is significant.
At the core of this topology is a master data management system. Dynamics AX is likely to be the system-of-record in most deployments, but I would strongly recommend deploying a purpose-built Master Data Management (MDM) solution. The above conceptual example does not show all the other systems Dynamics AX must work with when it comes to master data, but things like eCommerce, other ERP systems and PDM / PLM spring to mind. With a proper MDM system, this integration becomes easier and of a higher standard.
As the example shows, Dynamics AX has been split into three (blue boxes) separate instances. To allow coordinate between the three instances, we need three things:
- A system that collects demand and through S&OP strategies propagates the demand to the distribution and manufacturing instances.
- A data warehouse that consolidates information from all three instances into a single harmonized view.
- An integration platform that allows transactional data to flow between the instances.
To be able to feed the manufacturing business unit with the correct orders and forecasts, a demand and supply chain planning such as Logility or Demand Solutions is required to collect demand and calculate requirements based on inventory, constraints, service levels etc. Obviously, this approach mainly works in a scenario where the manufacturing mode of the business unit is make-to-forecast (MTF) or make-to-stock (MTS) instead of MTO or CTO. In a MTO / CTO scenario this approach is also applicable, but a single-instance approach may be more appropriate. I believe that this approach will also work in an assemble-to-order (ATO) context.
For obvious reasons, the multi-instance deployment strategy must be underpinned by a clear data warehouse strategy enabling business decision makers to analyze data, which has been consolidated and correlated across the entire business. With a sensible MDM strategy and appropriate tools, the mapping of analysis categories can be made in the MDM system to allow each business unit a degree of freedom in determining the categorization scheme most appropriate to their requirements.
In the multi-instance scenario, the idea is to allow a certain degree of freedom for each business unit when deploying Dynamics AX. Whether a corporate chart of accounts is appropriate or not, is often a matter of policy, but by including a financial consolidation solution such as Hyperion will ensure that financial data can be fed directly and correctly into the corporate financial platform.
At the End of the Day…
… whether you decide for single-instance or multi-instance deployment is more about the business than a technical issue. Dynamics AX 2012 R2 now supports the manufacturing, distribution, retail and services industries in a single codebase so the argument for single-instance deployment has just become slightly stronger. On the other hand, I have seen numerous examples where lack of process harmonization has made single-instance deployment virtually impossible – or at least very costly, so do not underestimate the change programme required to achieve total harmonization.
Going for multi-instance deployment requires Dynamics AX to be augmented with some best-of-breed solutions to compliment it. This introduces a discussion on best-of-breed vs. integrated suite, but that discussion is for another day and another blog post.
What I wanted to convey with this blog post is the point that before setting out on a multi-business-unit ERP implementation journey, spend time on ascertaining your organization’s readiness in terms of process harmonization and willingness to adapt to common process and procedures.
For more information on the Dynamics AX system architecture see Microsoft Technet.
For more information on planning and deploying Dynamics AX see the Dynamics AX 2012 Implementation Planning Guide.
In coming blog posts, I will discuss some of the issues relating to multi-instance solution architecture including:
- Output management – Mastering the multi-language, multi-channel, multi-brand challenge
- Best-of-breed vs. the integrated suite… What’s best?
- Financial controlling
- Integration architecture
- ERP as the driver for change
- A process vs. information implementation approach
- Template based rollout – are they any good?
- Master data management – The day of the Data Steward has come…