Why Components?

SaaS Components is the home of the Salesforce Architect. It was born from the realisation that most of the Salesforce blogs were only targeting two types of professionals:

Because I did not find any blog focused on the important role of the Salesforce architect in implementation teams, I thought I would create one. The content you can find here isn't as technical as the one available in developer blogs, nor is it as feature-focused as admin blogs. There's a bit of both, plus the high-level solution design and delivery perspective that make the role, all based on more than 20 years of experience working on projects of all sizes both on-premise and in the cloud.

So, why did I call the home of the Salesforce architect saas-components.com and not sfdc-architect.com for instance?

In a nutshell, I consider both SaaS and Components to be major concepts of enterprise architecture, and I think that, as a Salesforce architect, so should you. And with this in mind, here is the good news:

  • Salesforce is leading the whole SaaS industry
  • Lightning is an excellent implementation of enterprise components

The evolution of programming

So, I ain't no Wikipedia but I have witnessed a couple of changes in the industry, since I wrote my first line of code in 1981, all of them going in the same direction. Moreover, these changes are supported by the IT planet favourite: Moore's law.

Laziness drives the evolution of programming:
We always seek to automate automation.

Machine language transformed into Assembly language because it's easier to read "words" than "0" and "1". C language replaced assembly language because it's easier to read "for loops" than "registry" and "memory" instructions. Object orientation was adopted in masse because it simplifies reading huge programs (one way to put it).

Similarly, during the maturation cycle of any programming language, code libraries start appearing from the community or specialised vendors. To the point that you could argue that the craftsmanship required from the typical developer decreases with the time since developers can work around common pitfalls by re-using somebody else code. For instance, "multi-browser support" is today elegantly dealt with by most Javascript framework.

The elite programmers are moving from customers to software vendors
and write libraries or components to be re-used by more junior developers.

In the context of this blog, which is about enterprise application architecture and not video games programming, we also need to factor in the impact of Moore's Law. By opposition to the gaming industry, focused on features and performance, the enterprise application business focuses on resilience:

  • ☀️ Always ON
  • 📊 No data loss

These are the non-negotiable requirements, all of the rest is added benefit. The thing is that with an increasing amount of computing resources available (like "CPU power", "storage size" and "networking speed") we can add more and more nice-to-have on top of these two foundational requirements without worrying about performance optimisations for instance. In the nineties, using C language for desktop application development meant going back to assembly language from time to time when performances were at risk. These days are over.

Now, take a look at the following picture. You can have any one of the three toys below. Which one would you pick?

  • Number 1 is very robust but not very refined
  • Number 2 is very robust and somehow refined
  • Number 3 is somehow robust and very refined

If these were software capabilities number 1 would be out-of-the-box configuration, number 2 would be software components and number 3 would be programming.

When engaging in programmatic work in a Salesforce project (3), you are building features that are, sorry to say, less robust (than out-of-the-box or component) because your code will only be tested once, in your current project context. When you're reusing AppExchange solutions, including AppExchange Lightning components, you're losing in refinement but increasing the overall robustness of your solution because the code has been tested by many different customers before you. This is why components (plus low-code) are the new way to design and build a robust enterprise-class application.

Componentization is to the history of programming
what cloud computing is to the history of infrastructure:
The most mature stage of the evolution!

Welcome to my blog!

So, here you go. This all explains why I'm a componentization advocate. Check Why SaaS? to see why am I a SaaS advocate...

I hope you enjoy reading my blog. Don't hesitate to ping me on Twitter if you have any comment or just want to say "hi". Bye for now!

Fab 🐸