If you are involved in the Salesforce ecosystem you will have across the #RoadToCTA movement. I recently got thinking about the different types of Salesforce Architects I have been fortunate enough to work with and began reflecting on this. If you are a Salesforce Architect or aspiring to be one then you should review this and see if you identify with any or even multiple.
The Perfectionist
As the name suggests, this architect is a perfectionist. They can be prone to analysis paralysis in trying to find the perfect solution to every problem. Most people that work in Software/IT will tell you; the perfect solution rarely exists, only the best solution at the moment. Perfectionists are great to work with and will most likely make you consider most options before heading down a particular path. This is vital on the Salesforce platform as there can be so many gotchas given the governor limits or obscure platform limitations. You need a splash of perfectionism to be considered a good architect.
The Config Master
I do not subscribe to the notion that only experienced developers can be Salesforce architects, some of the best identify as non-developers. Being a master of the config capabilities of the platform can go a long way. There is more to being a Salesforce Architect than custom development. For one, you need to be able to align business requirements to the full capabilities of the platform. Not being a developer gives these architects a unique viewpoint where they consider all aspects of the platform. In turn, they can have a tendency to over config, but this rare at the architect level. They can usually do a good job of identifying when a use case requires custom development. You too will need to channel your inner config master to be considered a good architect.
The Proof of Concept (PoC) Guy
Everybody loves this guy, but be very cautious. I have been this guy on multiple occasions because it is the number one way to build rapport with your business stakeholders. Whether you buy into the Agile movement or not, one thing you cannot disagree with is that working software is more preferable to powerpoint slides. If this architect is doing their job correctly, they will be quick to highlight that any code or config they do is just proof of concept, and should be treated as throw away. This advice tends to be ignored and the PoCs are usually built upon as if they are production ready. Building a PoC is an important skill and one that should be cultivated, it is hard to hold back and not build the full solution or go straight from PoC -> production code. The good architects build useful PoCs but are able to restrain themselves, they are able to build enough to showcase an idea and only resort to a PoC when clarification/experimentation is needed.
The Artist
Diagramming solutions is an integral part of the role of an architect. Complex systems need to be visualised to be understood. There needs to be a shared understanding of the system across all team members. Some architects take this a step further and can get obsessed with their diagrams, colour coding and constantly spending their time updating diagrams. The trick to diagramming solutions is to do it at the right level. If you go into too much detail then you will forever feel the urge to go back and update your diagrams. If the concept can be easily described using words, then do so. Hone your artistic skills but remember you are still an architect and not actually an artist.
The Skeptic
This is my favourite. Purely because they help unearth some real gems. Their scepticism can be viewed as negative feedback but do not be fooled, they are just as capable and are rarely sceptical of all solutions. Just the ones that have obvious flaws. Working with this type of architect can lead to some very interesting design decisions as they tend to not accept solutions easily and require serious convincing once they are in the sceptic zone. Ask probing questions that move them out of this mindset and into a mindset of finding solutions rather than just stating problems. They are also usually the guy that business stakeholders tend to avoid because he/she asks tough questions of both the technical team and the business. If you find that the business is coming to you with every new business requirement then you should probably start being a little more sceptical.
The Lead Architect
Usually on a power trip and can be hard to work with. They are usually the loudest voice in the room and don't give opportunities for others to speak. The bad ones, tend to not let their team members have any autonomy while the good ones ensure the team have the breathing space to think through options. They usually find a good balance between meeting business objectives and making the right technical decisions. This role can be quite business focused and requires somebody that is open to the delegation. The best lead architects will delegate and do it well, they will know when to get involved and are usually great educators. They take responsibility for the team growing. Working with a good lead architect will undoubtedly help improve you as either a developer, admin or even QA.
The Yes Man
Don't be this guy. Don't just accept the status quo or the business requirement. You are not being paid big bucks to simply just accept ideas and solutions. Think long and hard, take the time to think through other options, try to identify problems early enough where the cost of change is small. In short, don't be this guy.