The traditional top down approach to architecture does not fit well with Salesforce. The reason for that is you cannot take a full top down and business driven solution and technology approach, because of the XaaS characteristics of Salesforce:

- The PaaS aspect means the technology architecture is a given, providing constraints to higher domains and layers of architecture

- The SaaS aspect should be leveraged, not replaced or conflicted with

Salesforce is not a system or platform that's designed to be implemented exactly how the client wants. It's a back and forth process where change management is key.

Forcing the traditional approach to architecture on Salesforce typically results in two things:

- The implementation becomes very code heavy

- The implementation struggles to stay within the governor limits

The other way around - bottom up - doesn't work either, but is what you often see in Salesforce implementations: hardly any big architecture is done, the solution is designed story by story, without properly considering end-to-end UX/CX, dependencies and conflicts.

It's the approach I like to call stacking sheds: you cannot stack up a few hundred sheds and expect to end up with a skyscraper. The implementation will not form one harmonious end-to-end solution and the foundation does not support the solution built on top of it.

So what could a better approach to Salesforce architecture look like? That's the question we'll be discussing in this virtual meetup.