Disclaimer:
This is my personal opinion, as always, more of a thought process than the one truth.
Details will likely differ from company to company. Bigger teams will have a different approach than smaller ones. I’m looking forward to your feedback!
Source
I didn’t come up with the following concept myself but extended the ideas of others. The concept of “evolutionary architecture” and the cost of poor design I got from a blog over at IBM.
Summary
Choosing what to focus on is part of our day-to-day challenge. In my opinion, as Architects, we have to focus on what’s hard to change in the long run. Things that can be easily changed can be delegated. As architects, our focus should on the things which are hard to change in the future. Getting these long-lasting decisions right brings the highest value.
Introduction
It’s hard to describe a Salesforce Architect job and decide what’s our primary focus. There are a million decisions to make, which one should we focus our energy on?
As always, the answer you will give will vary from company to company. Nevertheless, I think there’s one core question you have to ask: How hard is it to change once it’s implemented?
Using that question on the longevity of a decision, we can differentiate what needs to be focused on. Everything hard to change in the future should take our full focus. Things that are easy to change in the future, don’t need our full focus now.
While I was putting together that list, I got some surprises. At times during my career, I was focusing my efforts on topics that sounded important but could be changed easily if they don’t work as expected.
I’m guilty of discussing Flow vs. APEX for days. What I always forget, a Flow can easily be made into APEX if necessary. Therefore it’s not important to put my architect’s effort into that discussion. Whatever we decide today can easily be changed tomorrow.
On the other hand, I would happily delegate defining the Role Hierarchy to an Admin. But actually, this Role-Hierarchy is almost impossible to change later. The Role Hierarchy will likely stay for long after I left the project. Therefore I should focus a lot of thought on the design of the Role-Hierarchy.
Going forward I’ll try to always ask myself: Is this hard to change in the long run? Only if the answer is a Yes I should focus my energy.
The following is my personal opinionated list, which is heavily influenced by what I learned from Salesforce during my #journeyToCTA. Your situation might be different.
Excurse: The cost of poor design
I apply a “hard to change later” logic to my architecture decisions. What goes into that is the cost of poor design. Some things can be done bad but since it’s easy to change later, doesn’t hurt too much. If you get a haircut you later regret, it’s annoying but rather easy to change. Therefore you have a low cost of poor design. On the other hand, if you get a tattoo you don’t enjoy much later it takes a lot of effort to change later, therefore the high cost of poor design. Using that concept I created the “Architect’s menu”. Pick your flavor.
Architect’s menu
Our Architect’s menu comes in three flavors. Make sure you don’t only focus on mild but get your share of hot and spicy
Mild: Easy to change later, little to no architect focus
- Chosen automation tools (Workflow, PB, Flow or APEX)
- UI Elements
- Field Level Security
Medium: Medium-hard to change later, some architect focus
- Fields
- Profiles & Permission Sets (More tedious than hard)
- Integrations
- AppExchange Apps
- Frameworks (More tedious than hard)
- Governance Model & DevOps
- Project Methodology
- Record Types
- Implementation cleanliness
Spicy: Hard to change later, full architect focus
- Org Strategy
- Licenses
- Role Hierarchy & Sharing
- System Landscape
- Data Model (Objects & Relationships)
- Security Concept
Next Steps
You can go ahead and check with your team. Are you putting enough of your time into medium or spicy tasks or are you wasting your time with mild items?
What’s on your Architect’s menu?