Cloud Control – When More than One could be a Crowd!
Too many cloud applications can quickly lead us to the same level of complexity as managing multiple On-Premise applications. Adding more cloud apps to your enterprise IT ecosystem may be too much of a good thing.
The CRM cloud application (It could be
Salesforce, Oracle Sales Cloud, or MS Dynamics, etc) is normally at the centre
of your solution. Typical challenges we see in maintaining these alongside multiple
‘edge’ cloud apps:
1.
Integrations and Data
Migrations: Many ‘edge’ cloud apps use a
custom object for the same CRM entity (for example, a custom object to hold
Account or Customer Information, Product Data, etc.. which are also present in
the base CRM application.)
There is a common need to “integrate” between the CRM object
definition and the cloud app’s customer object definitions. This approach increases integration and data
migration costs and results in unnecessary replication of data.
2.
Upgrades: Many cloud app vendors tout their frequent
release cycles as a testament to their pace of innovation. As a result, there is the rising cost of incessant cycles
of testing, releases, and user training.
3.
Environment cloning and
migrations: Each cloud app comes with
its unique installation and migration procedures. A strong system admin team is required to
clone environments for Development, QA, UAT and Production. Each application could have a different set
of code and processes to be installed.
4.
Technology Stack to build the
Cloud App: Is it native force.com, java,
.Net, or another custom language? Does
the Cloud app include components (such as configurator or pricing engines) that
are built using different languages or residing in a separate cloud?
5.
Process-related Data Migration:
‘Lead-to-Contract’ is one of the processes where data mapping needs to occur
between many objects such as Lead to Opportunity, Opportunity to Quote, Quote to
Order, Order to Contract, Asset to Quote, etc.
Custom workflows to enable the mappings and flows result in high
implementation and maintenance costs.
Many of the cloud vendors have ignored these
challenges, whilst a few are addressing these issues (and rightly so!). So when you’re looking for a cloud solution ask
the vendor if they have done the following:
1. Pre-built end-to-end,
industry-specific CRM apps reducing the need to manage and maintain multiple
cloud apps.
2. Focused at the
outset on the integrations and data migrations, building adapters for most
common on-premise applications.
3. Offer a ‘CRM’ object-first
guarantee. As a result, they would not
replicate any objects released by the CRM vendor, either pre-existing or in the
future. In addition, their apps
guarantee compatibility with the CRM native objects.
4. Provide tools to
facilitate Process-centric data migration through declarative mapping between
any objects in the CRM instance.
Takeaways:
1. The marginal
benefit of installing a new cloud app vis-à-vis the existing on-premise app requires
careful consideration. Keeping the
on-premise application may not be a bad decision after all!.
2. Just because the
edge app is built natively on the same platform as the CRM application doesn't
mean there is no integration and data migration effort.
3. Detailed
understanding of the integrations involved.
The existence of some APIs is just table stakes; use of those APIs to
integrate and load data is where heavy lifting is necessary. Check for existence of tools and solutions to
address these.
4. Check on the excessive
use of custom objects to store data that is already stored in the CRM native
object.
If you’d like to know more about which
cloud vendors we think are taking the right approach then please get in touch
