Being billed for Salesforce licenses that you actually do not need? Endlessly investing money in additional data storage space and your Salesforce instance keeps turning into a big money pit? Many of the biggest roadblocks organizations hit when building a Salesforce app are not related to the Salesforce technology at all. Rather, it’s all a matter of a strategic vision decision-makers have for the overall process and key roles that should be engaged into the app building project. It’s not uncommon for organizations to underestimate those roles that are generally considered to be critical in Salesforce implementation, either out of ignorance or simply because they want to keep costs down. Either way they end up paying at the very least twice as much as they normally would. With that in mind, we decided to provide you with though-provoking insights into the role of the Salesforce Application Architect – the role that organizations can’t do without if they’ve set their sights on building a high-performance application on the Force.com platform. Dmitriy Zhugin, Chief Technical Officer at VRP Consulting, helped us see behind the scenes.
Here we go.
We know that there are three types of Salesforce Architects: the Salesforce Application Architect, the System Architect and the Technical Architect. To begin with, please tell us about the difference between these roles, if any.
Well, the three roles are interrelated in that they share the same focus area which is architecture. Yet, they have different areas of responsibility, levels of expertise and skills. In broad strokes, the key responsibility of the Salesforce System Architect is to see to it that applications the company installed in their Salesforce instance interact with each other the right way. That is to say, their key activity revolves around configuring the Salesforce system in a way that ensures proper communication between installed application packages. As for the Technical Architect, as a rule they come into play to tackle serious issues like performance issues, poorly configured database connection, when, say, the Application Architect didn’t meet business requirements and messed things up – simply put, to troubleshoot screw-ups and critical system issues. That is why it’s imperative that businesses never cut corners on designing robust application architecture in the first place. This is exactly what the Salesforce Application Architect does.
So, what is the scope of duties the Salesforce Application Architect performs?
Well, first and foremost, the Salesforce Application Architect is involved in designing the backbone of a company’s application solution on the Salesforce platform. This includes designing a portal, an application for AppExchange, an integration module – whatever it is, the Application Architect is in charge of defining the framework of an application based on business and functional requirements.
Along with that, if you are looking to migrate any application to Salesforce.com the application architect is the one you can’t go without anyways. They are skilled enough to analyze your application in terms of complexity, identify the functionality required and make a crucial decision about whether you need to recreate your application on Force.com or can get away with a connector to integrate your application with Salesforce using API.
What’s more, prior to tapping into the application design process, the Application Architect has to analyze and get an in-depth understanding of the company’s specific business needs so as to translate business requirements into well-thought-out, practical solutions in the long run. Similarly, they carry out a thorough analysis of technical and functional complexities of the project in order to evaluate technological risks, develop comprehensive technical requirements and specify limitations for the source code.
Alongside with that, the Application Architect works in close collaboration with the Salesforce development team, which implies teamwork throughout the entire project lifecycle, from assigning tasks to development team members through ensuring that development activities are carried out appropriately and the delivered product matches the architected solution to hands-on participation in application development and configuration activities when needed. As you can see, the Application Architect takes on multiple roles, while taking a holistic look at the application system.
So, we can safely state that the Salesforce Application Architect is a multitasker, right?
Sort of. They wear more than one hat in their role, that is to say their role is decidedly multifunctional. We’ve just covered their key responsibilities, yet this is by no means an exhaustive list – the list could go on. For example, the Application Architect is also engaged in creating documentation and specifications related to the application architecture, its design steps, integration processes and testing procedures, its installation and maintenance. They ensure that the design meets quality standards and the application is effectively tested, verify with user representatives that the design and the application solution fit their business needs. That is to say, they are engaged in every step of the application development project, from analysis and product design, through development, to delivery and modifications.
Why do businesses need the Application Architect for their Salesforce app development projects?
The thing is, the role of the Salesforce Application Architect implies deep understanding of the Salesforce ecosystem, data model, out-of-the-box capabilities, features and functionality, strong knowledge of database design, data movement best practices, application and business modeling, to name a few. All in all, they are supposed to know everything application-specific. As you see, Application Architects are well-versed in the Salesforce platform and application landscape, and therefore, being Salesforce-savvy, they are capable of designing highly scalable, reliable and fast Salesforce applications for your business that won’t drain too many resources.
But what’s more important is that the Application Architect will help you choose the right Salesforce licenses so that you won’t have to squander you precious money on the ones that you really do not need. The point is that Salesforce licensing is rather complex, and if there is no the Application Architect to guide you through it, Salesforce will sell you, say, 5,000 licenses for $300 each, and you’ll eventually pay way more than required simply because you do not know how to manage licenses. This is one of the most common and costly mistakes many businesses make. So, license management is another mission-critical task the Salesforce Application Architect takes on.
Among similar lines, if you’ve already signed up for Salesforce packages but have doubt as to whether you need to make full use of all this full-blown functionality your licenses offer, you can also seek help from the Application Architect. They will probe deep into your biz, sift through your licenses, analyze your users, figure out which users need full read/write access and which ones can be good with read-only access to certain functionality, and finally opt for the licenses that will work best for your organization, thereby drastically reducing your Salesforce licensing costs. Once we had a client who had purchased 10,000 licenses just to communicate through Chatter! Imagine that! And they didn’t even have a clue that Salesforce offers the Chatter Free license. By the way, Salesforce terms and conditions do not allow reducing the number of users’ subscriptions until the end of the subscription term, which will add to your expenses. The idea here is that hiring the Salesforce Application Architect from the get-go is going to cost you far less than jumping into subscriptions blindly.
So it is. However, the value the Application Architect can bring to your business does not end here. Particular attention should be given to performance issues. Well, imagine the following scenario. You’ve had the application designed and it seems to be up and running. Yet, as soon as you have over 200K records for the lead object, for example, SOQL query returns so many objects that query performance sucks and you receive a “non-selective query” error. Your queries have extremely long execution times simply because the architecture was not properly designed, the field was not indexed, and queries were not designed to be selective up to the projected peak data volumes. And the worst part is that this all happens right at the time when your business keeps going strong, and you have to waste your time (think: money) to get the system up and running again.
What’s more, the Application Architect will also see to it that your database does not store redundant data, so that you won’t have to pay for additional data space. The point is that, Salesforce assigns the default storage size to each user license. The data storage limit, for example, is 20Mb per licensed user on Enterprise Edition, and 120Mb per licensed user on Unlimited Edition. Once you’ve hit the Salesforce data storage limit in your org, you will have to purchase more data storage. To avoid the situation like this, it’s critical that you engage the Application Architect who will gain insight into how much storage space you are using and how much space you actually need.
Dmitry Zhugin, CTO and Pavel Klochkov, Salesforce Developer at VRP Consulting
There is a lot more to consider. Very often Salesforce applications need to be integrated with 3rd party systems and subsystems. Poorly addressed integration will invariably cause a collapse of the system. This usually happens because you fail to consider in advance which system will be the “master” with regard to customer information. Improperly designed architecture leads to data duplication and bid data mess. As a result, you may, say, start flooding someone’s email inbox with the same email messages. A rather unfortunate thing, indeed. Implementing data deduplication, cleaning up messy data, identifying the Master record and all related Detail records – simply put, performing code refactoring may come out to be a daunting, time-sapping task, which may take up several months to fulfill. Hands down, it’s way more reasonable to perform data management as early as the architecture design stage than bring order to the messy integration. This is where the Application Architect comes into picture as well.
And one more thing. When it comes to designing an application, it is easy to fall into, say, a custom development trap. What I mean is that in many instances it is possible to minimize Salesforce custom code due to a host of out-of-the-box, declarative features Salesforce provides for its users. These include the top-tier Salesforce Sharing and Security Model, Outbound Message, Omni-Channel Skills-Based Routing, multiple integration features, you name it. All you need in this case is the Salesforce-savvy Application Architect who can easily figure out when you really need custom Salesforce code and when you can get away with standard functionality, and who knows very well how to unlock the power of standard features. Otherwise, your entirely customized solution will turn into the bane of your life, since the more custom code you embed into your app, the more bugs will eventually arise, meaning the application ongoing support will cost you a bomb. On top of all that, custom development implies long delivery timelines – on average, it takes about half a year for an app to go in production. Let alone the fact that any improvements and design modifications you’ll have to introduce sooner or later will unfailingly entail new development cycle, which will again eat up a large part of your budget. The Application Architect who knows the Salesforce platform inside out can leverage the platform’s declarative framework to the fullest, which will invariably cut down development costs and dramatically reduce time to market.
The role of the Salesforce Application Architect seems to be remarkably all-embracing, which raises the question: is it that indispensable? Can we replace this role with, say, the Technical Consultant or the Salesforce Senior Developer role?
The role of the Salesforce Application Architect in the project can’t be overestimated – they bear full responsibility for the entire application architecture, end to end solution design and development lifecycle process. Hence, unlike other specialists (except for the Technical Architect, of course), they have to possess a wide range of specific skills and knowledge we’ve already covered to fulfill these multiple functions. This role is about coming up with, documenting and monitoring the delivery of a system solution tailored to meet exact business requirements, whereas developers, for example, are solely supposed to write code for the solution architecture designed by the application architect.
The same is true for Technical Consultants – they can walk you through all possible features Salesforce comes packed with, they will tell you which of them are best suited for your business needs, how they will work and what value they might bring to your organization. Yet, it is the Application Architect who evaluates the options of how to implement functional requirements and finds the best one for your enterprise needs. For example, you are looking to set up a mass email system; however, you are unwilling to invest in Marketing Cloud. Hands down, there is a variety of work-around solutions out there – you can always opt for writing custom code or integrating with a third-party email service provider such as Mailgun. Yet, with the former it won’t take long until you hit the mass email limits, while the latter won’t come cheap. Nо one but the application architect will tell you that it is possible to bypass Salesforce mass email limits and send unlimited emails from within Salesforce to contacts, leads, person accounts, and users whatever edition you may use.
So, getting back to your question, if you want everything to be up to par and at affordable prices, you’d better not replace the Salesforce Application Architect with whoever comes your way.
Does the same go for any other application architect? Can we, for example, engage the architect who has been developing applications on, say, Microsoft Azure?
Well, there is always an option to hire an application architect who doesn’t know beans about Salesforce coding, but who will deliver a properly designed solution from the perspective of coding standards. Yet, it won’t be that good in terms of the platform, in terms of performance and value for money. The point is that not all programming principles apply to Salesforce. After all, Salesforce is a cloud platform, and all cloud platforms operate differently. More than that, in order to become Salesforce-savvy and be able to take on the task of designing a Salesforce application, the specialist is supposed to earn the Salesforce Certified Application Architect credentials and this is not an affair of a few days, since it requires achieving the domain designer certifications – all four! – prior to going for the Application Architect Certification.
The bottom line here is, the role of the Application Architect proves to be crucial in designing the Salesforce application architecture and businesses should never underestimate it, since they help reduce development time and costs while also ensuring application and business agility and scalability.
To that end, you’d better avoid taking a shortcut when jumping into the application development project. The so-called short cut will unfailingly turn into a long-term laborious journey – that is, sorting out the mess will drain your precious time and resources. As the saying goes prevention is better than cure. This is particularly true for application development. Investing money in the Salesforce Application Architect from the get go will go a long way in that you won’t have to pay heavily for the system revamp in the long run.
The average Salesforce Solution Architect salary in the USA is $130,453 per year.