Multi-Application Architecture: Why and How?

In Pigment, you can build revenue forecasts, profit and loss statements, headcount and recruitment plans, balance sheets, and cash flows.

All of this could exist in your Workspace, even in one Application. However, you can also distribute planning across multiple Applications in real-time natively. Implementing multiple Applications has no time costs and protects you from data import/export issues.

This article aims to explain the concepts of distributed planning so you can decide how to best apply this to your business.

Distributed Planning: How does it work in Pigment?

Any Pigment Application can share its Dimensions and data (any Block, technically speaking) with other Applications in the Workspace. You can see which Blocks are shared by looking for the shared icon in the Block explorer.

Sharing a Block is simple:

1. In the Block you want to share, select the cog icon at the top right of the main pane.

2. Select Library.

3. Toggle on Share this Block with other Applications.

Then activate sharing in the Library menu of your Pigment Application:

1. Select the three-dot menu at the foot of the sidebar.

2. Select Libraries from the dialog that opens.

3. Toggle on the button beside the name of the relevant Application.
   Any Block built from the shared Block is instantly impacted by any changes made to the Block in the source Application. For example, if you add a country in the source Application, it is available in real time everywhere.

ℹ️ Note

Access rights apply across Applications and they are a major driver of the decision to split Applications. See below.

Typically, Applications share the common business Dimensions (country, cost center, time etc.), source data (actuals from accounting, headcount by cost center) and output data (revenue forecast, new hires per period etc).

Why split Applications: main drivers to consider

Sometimes the decision to split Applications comes naturally and obviously: your sales ops team has its own Revenue forecasting, Finance has its own forecasting app and HR has a recruiting app.

If you are weighing up splitting your Applications even further, consider the following.

Reason 1: Segregation of duty

Consider who the main users and admins of the Application are.

If one group of users is solely focused on that one functionality, that’s a good hint it should be its own Application.

Will one of your modelers be solely focused on one particular functionality and should not be allowed to modify the rest? Stand-alone Application.

Is your data set super sensitive? Make it its own Application. It’s a lot simpler to limit user access to just that one Application.

A typical example in this category would be an HR Staff Costs Application that contains the individuals and their salary. Only one team (HR) would access this Application.

Reason 2: Organization of the Blocks and ease of modeling

When we start building in Pigment, we quickly find ourselves with a large number of Blocks: Dimensions, data loads, Metrics, Metrics, Metrics… Even with strong naming conventions, and organizing Blocks into folders, it can still become too much.

Does one functionality require dozens of Blocks, yet only one Block (containing the final results) will be shared with the rest of the model? Make it its own Application!

This is also valid if the names of the Blocks are very close in two functionalities: split one into its own Application.

A typical example: Revenue forecasting requires many Blocks but only one Metric (final revenue by desired Dimensions) needs to be shared with the rest of the Applications.

Reason 3: Different versions of Dimensions

We’ll start this one with an example. A specific part of your business requires very different (or even slightly different) Dimensions from the rest of your business. They might require a longer timescale for historical reasons or a list of countries that is slightly different from the common one because that part of the business is based on a legacy system. You could work with two different Month/Country Dimensions in one Application, but that can be confusing (especially when typing a formula or creating a new Block).

You can build the same logic into its own Application and then do a simple mapping exercise to match the Dimensions. This will allow data to be shared.

Reason 4: Cadence of planning and scenario cycle

When you plan for your business, you don’t necessarily plan for 100% at the same cadence. Do you review your OPEX spend plan every month? Headcount every week? Revenue every day? Do you do 10 scenarios for your revenue but only one for the rest? Sounds like your revenue planning is a good candidate to be its own Application.

A special Application: the Hub

The Hub is a special Application that we strongly recommend you implement in all deployments of Pigment. It offers many benefits and will simplify your life when you increase your usage of Pigment.

See below some key benefits.

Single source of truth

The Hub should be the Application where all the common Dimensions of your business are stored. For example: Region, Cost Center, Product, Chart of account, Time, Versions etc.

This ensures a single source of truth.

However, this is not just limited to Dimensions. In the Hub, you can also put in your common business data. For example, actuals from Accounting, opportunities from SFDC, etc. Any external data that will be shared between your Applications is a good candidate!

A rule of thumb: if a Dimension or data will be used by two or more Applications, it should be in the Hub.

However, don’t put everything in there just for the sake of it. There are valid reasons why a Dimension should be in another Application. For example, headcount and payroll should sit in an HR Application and be shared from there (see Reason 1).

Smooth User Access Management

As the Hub will contain the shared Dimensions, it is the natural place to define user access and derive it from the Hub.

In Pigment, user access uses two axes:

• Action: what you can do, based on your role (open a Board, edit a Block, change access). A user will have a role on every Application they need access to, and those roles can differ depending on the Application. Using a Hub, a user will just need a role in the Hub (to access shared Dimensions) and a role in their main Application.

• Access Rights: what Dimension you can see and write on. This is very often driven by Region and Cost Center. You can assign this in the Hub and derive access rights in all Apps from the Hub.

For more information, see Pigment Access Rights Basics.

⚠️ Important

1. While a user can jump from a Board in one Application to a Board of another Application easily, you can only put a List widget of a Dimension in a Board of its own Application.

2. Users of an Application will (at least) need a READ role in each Application that is sharing a Block with the Application.  

Example of architecture

Example 1: Finance only:

Hub - FP&A App - HR Staff Costs
 

Example 2: Distributed XFN:

Hub - Actuals - FP&A - HR Staff Costs - Recruiting (TA) - Sales Forecasting (Sales Ops)

Example 3: Supply Chain:

Hub - Demand Planning - Inventory Planning - S&OP