What Salesforce got right #1: database abstraction

In the spirit of the holidays 🎄 and inspired by implementing a competing CRM, I'll pause my usual snark and share a few of the architectural decisions 🏗️ that I think Salesforce got right.

Salesforce win #1️⃣: Database abstraction

When I was a wee lass, walking uphill in the snow both ways (in NYC) ❄️, field and query requests in enterprise environments typically went through a Database Administrator. Not to imply DBAs have gone the way of horse buggy whip craftsmen, but abstraction layers for database management, of which Salesforce was an early purveyor, did reduce the need for the role.

In other CRMs like Sugar CRM and Creatio, database updates made in the UI translate directly to tables and fields in a standard relational database. Years ago at Dreamforce, an engineer explained that all Salesforce customer data is stored in just 4 Oracle tables. To pull that off with the flexibility they offer in configuring the data model, secure segmentation of customer data 🔒, and (to a point) not choking on performance ⚡? That's impressive engineering 💪.

The downsides? SOQL versus SQL limitations. I was a whiz with SQL when I started with Salesforce, and SOQL felt like data handcuffs 🔗. It's improved since release, but never broke beyond being bastardized SQL. That's the cost they paid for that clever metadata-driven model. Conversely, the CRMs that sync the metadata with the database architecture hit their own issues, as replicating the same information in 2 different places in 2 different formats is prone to do.

I've also seen orgs inadvertently sabotage themselves 💣 because the tight coupling of data model to form-per-record UI leads to data models that complicate or outright block business logic, integrations 🔌, and analytics 📈. I'm watching this exact struggle play out in Creatio right now, with two different means of relating Financial Accounts to Cases emerging to satisfy different UIs. Business versus database wonks; a reflection point for choosing quick wins that become long-term disasters, or sustainable solutions that require a little elbow grease.

That said, technology that empowers non-technical folks to build their own data model can't be expected to force them to make decisions they don't have the experience to make. That's why there is value in turning to experts like my colleagues and I at Codality, we have a geeky passion for designing data models that sustainably support our clients' requirements.

Next up, let's talk about how impressive it is for a cloud platform ☁️ to do 3 major releases a year that *usually* do not cause chaos. What architectural decisions do you think Salesforce nailed ✅ (or failed ❌)? Drop your opinions below.