Salesforce Centric System Architecture Diagrams

TDX '19 is just over and I am still humbled about all the positive feedback that I received for my presentations. Quite a few people reached out and asked for the slides and content of the session hence I thought I share the concepts in an article. The slides are with the Salesforce team and will be distributed via their channels.

Introduction

As architects, we often have to assess the systems that an organisation holds in their enterprise and map those into a logical diagram. Sounds simple, right? But as the number of systems increase, so does the complexity and if no logical structure exists to group those systems, the picture we create can get messy very quickly.

This article provides an overview of what system architecture diagrams are, why we need them when we should draw them and my method of logically structuring systems in a diagram. This article is targeted at aspiring architects with no or just a few years of experience.

What is it? When to create it? Why is this needed?

A system architecture diagram (also knows as a system landscape or architecture diagram) is a visual overview that shows the relationships amongst the different systems that exist within an enterprise. Further to showing the relationships, it is a conceptual model that outlines either the current (as-is) or future (to-be) state of how components (systems) are connected to each other. It is of high-level nature and gets progressively refined to a more detailed and concrete diagram that may even be split into sub-diagrams outlining more low-level information. Whilst there are many views on what system architecture diagrams should contain (e.g. does it cover all systems within the organisation or only the systems that are in scope for the project, is it only outlining systems or should it also show the mapping of functionality to software and hardware), this article focuses on mapping systems (including applications that are part of those systems) within a Salesforce centric landscape.

Since architecture diagrams have the purpose of aligning different teams by forming a common understanding of how applications are interconnected, I recommend drawing it as early as possible in a project context. By having an early overview of all moving parts, dependencies and risks can be identified and managed accordingly. That said, it does not mean that the first version is the final one and the document should rather be seen as a living document that gets enhanced and expanded over time.

What needs to be considered?

To state the obvious, put components into a logical structure. What I mean by this is to think about what system live where in your enterprise. Can on-premise systems occupy one section of your canvas, while third-party systems live somewhere else? Also, know the audience the diagram is addressed to - is a business stakeholder interested in knowing that the integration is via REST or will a technical architect get value out of the diagram if it talks to how cases are managed?

The second thing to consider is data that sits in different systems. Knowing where you source-of-truth sits is crucial to understanding how your integration is impacted, if you will need to perform ETL jobs or how your reporting on data needs to be managed.

Also, keep in mind that moving from your as-is state to the to-be state might involve data migration activities that should be highlighted including the tools required.

Lastly consider how is all the integration going to be secured, what protocols will be used etc.?

My approach

By all means, this approach certainly does not work all the time but it has given me a good starting point when putting together my system architecture diagrams.

I divide my canvas into the following areas:

• As mentioned previously, I centre my design around Salesforce and hence draw a big box for it.
• Normally, my landscapes involve on-premise applications as well as an integration layer and I put those at the bottom of my canvas
• Any system that is external and outside of my control (e.g. a government service that validates social security numbers) I put to the right of my canvas
• Channels that explain how I interact with my customer (e.g. live chat, telephony, email) I put to the left of the Salesforce box
• Lastly, anything related to tracking and external content management goes to the top of the Salesforce box.

Putting it all together is probably the easiest with an example. I apologise for the length of the below but I modified a scenario that can be found in the Architect Trailblazer community (https://success.salesforce.com/0693A000006QmW5) and have pasted the contents below:

Laptops to Schools (L2S) is a non-profit company that receives donated laptops from corporations and allocates them to over 2,000 schools around the world or sells them to 3rd party recycling companies. 

L2S also operates two shipping and receiving hubs located in Denver and Paris. Donated laptops are shipped to one of these hubs and evaluated and cleaned before being allocated to schools or sent for recycling. 

On average, each corporation donates 300 laptops each month. L2S is experiencing very rapid growth and is looking for a more automated solution that is easy to maintain and will allow them to scale in the future.

Laptops are donated by sending the laptops to one of the shipping facilities and emailing a CSV file with the model numbers to L2S.

Requests for laptops can be made either via phone, live chat or email. 

L2S employees currently access the following disconnected systems:

• an inventory system
• a shipping fulfillment system
• a cloud storage system

L2S also has the following systems:

• a HR and payroll system accessible via the browser
• a billing system (offers AppExchange app)
• telephony system (Cisco)

The inventory system stores a record of all laptops that are donated to L2S, including the serial number. It is currently the system of record for all schools and 3rd party recycling companies.

L2S employees access this system through the web using system-specific login credentials. L2S employees sign in to their workstations via active directory.

3rd party recycling companies also access the system to update the amount they paid for laptops purchased from L2S and to contact L2S. L2S is considering Auth0 as an identity management system for external users.

The following problems have been identified with the inventory system:

• Schools and 3rd party recycling companies appear more than once.
• L2S Donation Coordinators (DCs) run a manual batch import from a CSV file containing a list of laptops donated from a corporation 

L2S is required to keep the inventory system in place for government audits, but requires that:

• Salesforce be the system of record for schools and 3rd party recycling companies.
• All updates to the inventory system should happen automatically.

Other requirements

• The shipping fulfillment system is accessed through the local workstations and stores shipping details for donated laptops received from corporations and laptops that are shipped to schools or 3rd party recyclers. It offers a SOAP based API.
• The cloud storage system (Box) contains training videos and the software applications for the laptops. The system is provided to L2S free of charge and is also used for storing company process manuals.
• Schools should be able to request laptops, in addition to the existing channels, online and L2S wants to track the performance using Google Analytics. Also, L2S wants to serve content assets in the community using AEM. 

The below diagram shows how I would map the different components and compose them in my system architecture diagram. I have highlighted the different sections to show how I have mapped the different systems against my canvas areas described above.

A few things that I want to highlight:

• Not all the systems that are in the diagram, are actually mentioned in the scenario. I have made assumptions and added some systems to create a more logical view of how an enterprise would likely implement things. Those systems include the Federation Service and Integration Layer as well as new AppExchange apps, Files Connect and CMS Connect.
• When drawing the single sign-on (SSO) integration, I create an extra box for My Domain in Salesforce, since this is a crucial feature that should be turned on before setting up SSO.
• I added a few sub-sections in the Salesforce box to outline the different products (clouds) I use in Salesforce and the core business processes that will be executed in the particular product.

I probably can go on and on to outline even further the considerations and methods I use. However, I believe that this is a good starting point to get started with System Architecture diagrams.

I hope this is helpful to some of you and I am looking forward to hearing your comments and suggestions to further improve this article.