As I drove home to the other side of town, night lights flashing by (no, I was not speeding), retro Bollywood songs playing at an above-average volume, cool breeze blowing through my hair, I wondered what I had learnt that day after running from one session to another across three different halls (and also from delivering one session). As I recounted, probably wearing comfortable shoes was a key learning, as well as to carry an empty bag for all the SWAG that you can get. But that is just scratching the surface. The actual things that will re-shape my vision of a Salesforce architect will probably be defined by the following:
Salesforce is there to help you.
With architect.salesforce.com and the well-architected framework, Salesforce is making an active effort to help the architect community with publicly available frameworks, diagrams, concept, best practices, design patterns and much more. Gone are the days when each architect had to struggle through the dark alone to catch a glimpse of the shiny light at the end of the solutioning tunnel. A number of these resources can be leveraged to sort through design options, prepare documentation quickly, and align with platform guidelines. That does not mean there are no challenges for architects to solve; it just means that there is a helping hand to aid with solution design.
The flip side of all this information being available publicly is that anyone can validate a solution against the patterns (and, yes, anti-patterns), best practices, standards from the repository. That essentially means we, as architects, need to be doubly sure to build solutions aligned with these or have quantifiable reasons backed by rationale to go a different route, adding more responsibility to the job description (not that we were not responsible anyway).
Being a Technical Architect is not the end, it’s just a bend.
Though I have often wondered about it, Gaurav Kheterpal’s session made it clear as day the growth path for technical architects. For those of you wondering if being a technical architect is the end of road, well, it isn’t! The next stop on the architect line is being a solution architect. A solution architect, especially in the Salesforce ecosystem, is a person who loves solving multi-million-dollar jigsaw puzzles, or the person who drafts the multi-cloud Salesforce strategy, defining what processes will be addressed by which Salesforce modules. Being a solution architect is the quintessential pre-step to being an enterprise architect, working with the entire enterprise ecosystem. It gives one a sense of constructing the bigger picture, while still crafting the smaller pieces. There are learning paths available for B2B and B2C solution architect certifications, and probably those would be my goals for the next 12 months.
The power of Personal Branding
Salesforce, as a company, and also the entire ecosystem, has branding at its core. Over the years, one of the key factors of the success Salesforce has seen is not just due to technological breakthroughs but also because those were branded as revolutions. Mr. Benioff is a genius marketing person, and he is also a brand in himself. Branding, rebranding, coming up with names and labels that stick with you is how Salesforce made its billions. And, in order to be successful in the Salesforce ecosystem, as a company or as individuals, branding is an essential skill. As architects, to be renowned and respected, to be heard and heeded, personal branding becomes an essential commodity. Looking at the most renowned speakers at the event, you can easily pick out the pattern – all of them have worked hard on building a personal brand through public appearances, imparting knowledge and being reachable to anyone and everyone. There is no doubt about the knowledge these people have, but that is not what sets them apart and makes them industry leaders; it is that they are brands that makes them special.
Being an architect is a mindset.
All of us love little labels telling us our designations, don’t we? But being an architect is not about labels or designations; it is about the mindset and the ability to solve problems. And not just solving problems but solving problems in the paradoxical dichotomy of smaller-piece-in-bigger-picture as mentioned previously; an architect should be able to solve the smaller problem at hand, while understanding the implications of it across the larger enterprise ecosystem, ensuring the disruption is minimized. This understanding, this knack of solving problems while keeping an eye on the entire jigsaw puzzle (even if it is sans the flair of Salt Bae) is what constitutes an architect, not the label or the designation.
It takes hard knowledge to reach the top, but soft skills to remain there.
The soft skills workshop conducted during the event portrayed a very important aspect of an architect’s work life – soft skills. All the solution designs, all integration patterns, all best practice documents are important but a tad bit less important than the skills to negotiate with internal and external stakeholders, or the need to work together with a team to achieve common goals. Whether one likes it or not, being an architect is being a leader; there are a bunch of people who would jump into proverbial fire (thank God not literal one) based on the design an architect prepares, which makes it imperative that the architect help shape the mindset of these people to make them stakeholders in designs and solutions. A lone wolf act may sound appealing to some, but delegating is what makes space for growth. Soft skills are what gets it done.
Conclusion
Equipped with these insights on the first day of April, I will revisit my priorities for the next twelve months, focusing on being a better architect hopefully, when we meet again in the next Salesforce Architect Summit. What did you learn?
