FITTING SALESFORCE INTO EXISTING IT LANDSCAPE

The goal of this stage is to define the current state of the organization. The most important questions to resolve:

Let's try to combine the most common components that our IT landscape could consist of, so we can get a picture of a self-sufficient multilateral system. It must be able to support the full cycle of the company's life. What is the very starting point of almost every business in the world? That's a client – a person, who's most probably interested in your services or products. And yes – it is obvious that one of the main parts of the system should implement a flawless sales process and corresponding level of customer engagement.

Such assumption allows us to define the first part of the system – CRM component (on diagram), which is responsible for interaction with customers and collecting their information relevant for business processes that are currently in use.

Communication with clients is quite a complex task that requires a reasonable approach to choosing tools for building your customer interaction processes. Most CRM systems provide some basic marketing functionality, so it makes it possible to send some emails to customers or let them submit some landing forms, but comprehensive flow can be guaranteed by professional external modules. Let's define it as a separate Marketing component (on diagram) block.

When you face any issues with financial processing and reporting, it means that this is the time to pay attention to accounting automation. If current CRM+Marketing composition is not capable of scaling and fitting the required level of transactional, quoting, or billing processes, the situation forces us to look for a new module built exactly for that. That is why one of the most encountered issues and tasks for the IT department is to investigate integration capabilities of ERP and Accounting (on diagram) modules to include them in current processes and combine with the CRM core.

Automatically calculated KPI's and business insights can be extremely helpful when making decisions on further ways of company evolution. Producing low- and high-level reports and indicating sales process or customer interaction weaknesses allow us to draw the correct conclusion and plan corresponding correction activities on different management levels. What information may be helpful for that? The answer is "any" – just let your BI component (on diagram) analyze the data you already have in the system and use the results!

Once your system has grown, it starts to iteratively evolve: existing and connected modules are being modified and new components are introduced and integrated. Every new piece of the system may require different sets and levels of data from various modules, so it becomes helpful to connect a Data Warehouse component (on diagram) to be able to backup and share both sensitive and secondary data from different parts of the system.

When building a large system which is able to support the complex functionality described above, it is crucial to ensure the integrity and relevance of information, as well as its timely receipt in various layers of the system. Popular solutions for that are ESB (Enterprise Service Bus, on diagram) and ETL (Extract/Transform/Load, on diagram) services built to support real-time and scheduled uni- and bidirectional data synchronisation.

Here's the diagram of a medium-scale IT landscape with all the above mentioned components represented with their connections and dependencies:

The focus of this stage is to define the functional components that are bottlenecks for company's scaling, or lack the integration capabilities or flexibility to enable true corporate connectivity. The most important questions to answer:

Such components are replaced with automations configured on existing Salesforce modules or built on Force.com platform.

Basic CRM systems are not too extensible and do not provide such a large set of utilities as the Salesforce platform does. Managing landing forms, serving inbound/outbound emails via extended and customisable trigger-based services, integrated and extendable call centers and wide flexible application programming interfaces allow not only to connect Salesforce to the existing system but to fully replace few existing modules with a single cloud also. Following diagram shows a Salesforce migration scenario from the multicomponent CRM to a solid and scalable block. End customer experience is not impacted, agent responses are improved and accelerated.

Most ERP systems keep focus on working with financial data, associated document flows, assets management and contracts, draft and signed. Such processes are commonly quite complex and are associated with some legacy instructions – it means that replicating it on Salesforce side may take some time and will have to be fully retested and approved on all management levels. In that case, let's concentrate on some real value which can be brought by integrating a Salesforce instance to the system: customer interaction, website integration, providing seamless sales processes encapsulation. End customer experience is not impacted, processes are combined, accelerated and scaled.

We have not in vain mentioned that Salesforce is a platform – a new SF instance is not just another component to integrate into existing infrastructure but a chance to optimise overall data processing and provide more consistency to the system. Acting as a connecting block, this SF module can take responsibility for the integration of the other blocks and provide ESB/ETL-based component integration design. Choosing a type of architecture, in this case, must be based on estimated data volumes, the concept of extensibility and scalability of the system. End customer experience is not impacted, processes are combined and accelerated.

The goal of this stage is to leverage powerful integration capabilities of Salesforce and connect the remaining systems in one centrally orchestrated IT domain. The main questions to resolve:

The application of the methods presented and described above transforms the existing system into a less distributed and more independent set of components, presented in the following diagram. As a result of integrating Salesforce into the existing IT landscape, this structure does not violate the main/intermediate data flows and customer interaction processes, but simplifies the work of agents, the data distribution approach and the general principles of connecting and expanding component structure.

However, the flexibility of the Salesforce system allows us to run implementation in different ways, it can:

Technological aspects of Salesforce integration capabilities are really miscellaneous – it supports a number of integration principles and can fit into almost any architecture. Bulk data uploads, single record sync, custom interfaces and event publishing – all these operations are supported by default and are automatically adjusted to be compatible with data structures already in use. The interfaces which cover the most component integration and data sync cases are highlighted in bold.

Create, read, update, and delete records, search or query data, retrieve object metadata and access information about org limits. Great for mobile and web apps.

The same functionality as REST API but based on a different protocol and WSDL description. Great for writing server-to-server integrations.

This is an asynchronous RESTful API for querying and handling large amounts of data at once. Great for running migration of lots of records, such as initial data upload or running data backups.

Publish-subscribe design and broadcasting data changes. Great for building apps with UI based on capturing frequent data modifications.

Any cloud system has its own usage limits but it is also scalable — it is an important aspect which must be taken into account in order not to overpay for unused system resources and to be able to configure the cloud power for a specific system structure. I recommend using the following reference to get acquainted with basic Salesforce limits when designing a new implementation or expanding the existing one.

There's a set of solutions in the Salesforce domain that have become a powerful trend in the modern cloud landscape. Leverage of these clouds furthermore unifies and scales the organizational IT ecosystem.

Exploring other possible system improvements and Salesforce clouds, we may pay some attention to a Marketing Cloud tool which provides one of the most targeted and comprehensive customer engagement experience. It is a great option to consider when thinking about the future of the marketing component to be chosen for a system to scale.

A quick overview of MC capabilities provided by SF:

Accounting solutions are provided by Salesforce partners as packages and can be installed directly to the cloud, so they become seamlessly embedded to the SF interface and associated with corresponding SF users. A couple of package examples are mentioned on the diagram.

Accounting solutions are provided by Salesforce partners as packages and can be installed directly to the cloud, so they become seamlessly embedded to the SF interface and associated with corresponding SF users. A couple of package examples are mentioned on the diagram.

Einstein Analytics + Tableau is a set of Salesforce tools which allows us to connect various data sources to the system, transform it into a single format, to run AI-driven analysis and represent the results in handy dynamic dashboards. Moreover, using such a cloud simplifies the overall SF-based system structure.

Salesforce is not designed to be a data warehousing solution, so it is recommended to keep the data lake in a separate environment if there is a need for such a component.