In this post, following on from Part 1 we continue by exploring the types of accelerators on the market, configuration, software based and methodology.
It is important to note that as the word accelerator is not a standardised term, there isn’t an expected or default accelerator type, these are the most common accelerators I have seen on the market and an explanation of what they are. It is also important to know that organisations promoting accelerators might well be presenting an “accelerated” approach based on a combination of these accelerators, with methodology, standards and software working together. More reason to be more informed of what the accelerator means.
Configuration based accelerator (rapid configuration)
These one-time accelerators provide a pre-configured environment or base configuration (template) of standard software that you use to start the deployment with a form of pre-configuration. They are intended to expedite the delivery of a solution by replacing, let’s say 100 days of services, with a configuration that can be delivered in a much shorter timeframe, let’s say 5 days (or potentially fully autonomous and instant). Configuration based accelerators therefore save you 95 days of effort as per the previous figures, along with the time saving.
Configuration based accelerators should utilize standard software only, and not introduce third party IP such as solution packages (black box) and therefore simply apply a particular configuration rapidly, that you could attain yourself should you want to expend the 100 days effort mentioned above (and possess the relevant expertise). In the context of F&O this should therefore be a series of DMFThe D365 F&O Data Management Framework simplifies data migration, setup, and integration through data projects and entities. packages containing configuration data alongside potential run books and other configuration documents for manual changes outside the scope of the DMFThe D365 F&O Data Management Framework simplifies data migration, setup, and integration through data projects and entities. module, and not contain any customized entities, classes or other X++ which starts to move into being a software based accelerator.
An example of a configuration based accelerator would be the application of a predefined P2P set of standards, where procurement categories, supplier categories, approval processes, payment terms and other associated attributes are already setup and ready to be adopted as deployed, right out of the gate (or very rapidly). This accelerator when deployed could then be enhanced or changed at will, to refine small parts to the organizations needs, such as adding a few more procurement categories, or changing the approval workflow for a certain division.
Configuration based accelerators do not contain any persistent IP that requires either licensing or ongoing maintenance delivered the IP owner, as by their very definition should leave you with an environment that is a configuration of the vanilla software, making them very portable should you wish to move onward support to another service provider. Additionally, as only vanilla software is implemented, they leave you in a position where you are best placed to adopt new standard features being released as part of the release waves, as you are less likely to encounter conflicting functional capabilities.
Due to the fact that the configuration based accelerators are not software, and only configuration, it means that there is no software to maintain or upgrade beyond the standard Microsoft releases, this means the base configuration itself is usually a “one off” deployment, and you are unlikely to benefit from the vendors ongoing changes or enhancements to this base configuration (not impossible but just less likely).
Software based accelerator (the undercover ISV)
These accelerators can be the wolf in sheep’s clothing, if they are not fully understood, or the true value added component that makes your F&O (or CECustomer Engagement is the collective title of D365 first party apps built on CRM technology (Sales, Service, Marketing, etc). for that matter) solution sing for your industry or use case. Most organizations when looking for accelerators are often not looking for third party software (ISV’s / addon), they are under the perception that the accelerator does not require any ongoing maintenance, licensing or create a vendor lock in situation.
Software based accelerators deploy vendor IP and solution packages (black box), that likely need to be licensed and will need to be maintained in conjunction with the Microsoft standard releases. They have the greatest possible amount of flexibility in the solution that they deliver, as they can deviate as much as the software vendor / accelerator provider can justify from standard capability.
The hallmark of a good software based accelerator (as opposed to an ISVAn Independent Software Vendor is a partner that builds, deploys, and sells industry-specific solutions.) is the adoption of as much vanilla software capability as possible, and introduction of as few customised components as necessary to meet the industry or use case. Biasing standard functionality over the option to introduce overlapping capability and providing control back to standard software at the first opportunity.
An example of a good software based accelerator (in my opinion) could be a P2P addition for Retail, specifically for apparel and fashion, where at point of raising a purchase order for next seasons trainers (or sneakers for our friends over the pond), the purchase order entry form presents a new line based interface for creating the many lines required for the purchase order, providing a grid of colours, sizes and styles, beyond that of the standard solution, and automating the apportionment of quantities based on industry specific deviations (for example if you are buying 1000 pairs, how many should be of each size, style and colour for each country?).
This sort of solution would be used to create the multi line purchase order, based on specific industry practices, but then hands back the lines to the standard solution for onward (and standard) purchase order processes. Saving the user several minutes (or hours potentially) to complete the procurement activity. This is just an example for the sake of discussion, I appreciate there would be several ways to achieve this outcome in F&O, and different configurations of standard that might accommodate a similar time saving, but the principle remains.
Software based accelerators present a few advantages, firstly they can provide solutions and capabilities that might not even exist in the standard product. Secondly they should be upgradeable as a solution, meaning that when the software vendor / accelerator provider is investing in the solution, you could take advantage of that ongoing enhancement and roadmap to provide greater benefit to your organization, after all, this is what you should expect from an ongoing licence fee.
These accelerators, but their very nature create a high likelihood of vendor lock in, obligating you to license their IP and support packages, or at a minimum create a commercial tie to that organization that can only be broken when the solution package is removed. Some accelerators may be portable between implementation partners, if for example the solution is marketed as an accelerator and an ISVAn Independent Software Vendor is a partner that builds, deploys, and sells industry-specific solutions. solution, but the risk (and benefits) remain high on both sides. The more pervasive the accelerator in this case, the higher the benefit and risk.
It’s important to take software based accelerators for what they are, traditional ISVAn Independent Software Vendor is a partner that builds, deploys, and sells industry-specific solutions. solutions extending the core software to add value above and beyond for a given industry, they are being marketed as accelerators in some instances, because they do accelerate your implementation, if you need them, your implementation will definitely be longer if you do not buy them and decide to build it. These should not be considered as accelerators, as the risks and benefits should be known, and out in the open.
There are many areas when the standard solution just won’t be able to achieve the desired level of efficiency and capability, even with the infinite possibilities presented by the Power Platform, there are still many good reasons why ISV’s exist, and will continue to do so, you just need to know its an ISVAn Independent Software Vendor is a partner that builds, deploys, and sells industry-specific solutions. solution so you can factor in the ongoing costs, vendor lock in and maintenance requirements into your overall decision.
Methodology based accelerator (aka Implementation Methodology)
Accelerators also contain implementation partners with no specific configuration or software to expedite the project, instead they possess a unique or industry tailored implementation methodology, or proven solution blueprint that reduces the overall implementation time and associated risk. This could be thought of as a process based (documentational or otherwise) implementation methodology where focus is applied greater to the known variable areas for your organization.
Implementation partners in these categories will either have a unique process to follow, perhaps a variety of an Agile project, with various templates or project activities that seek quicker time to value. This could also be complimented by a specialism or large resource capability in a given industry.
Partners operating in this category often end up creating configuration or software based accelerators as a natural evolution to their focus on a given industry or technology, and may have well established “industry templates” which are more of a high level architectural blueprint identifying recommended Partner ISV’s to provide an end to end solution.
In the next post (Part 3) we will look at drawing some conclusions around what to consider, and some questions to ask ensuring you are fully informed.