Andrew Davis
00:00:00
From Code to the Cloud cuts through the noise to get to what really matters. The insights and tactics that help you maintain a consistently secure and productive DevOps strategy.
Welcome to From Code to the Cloud, a DevSecOps podcast focused on the Salesforce ecosystem. I'm Andrew Davis, Chief Product Officer at autorabbit and I'll be your host.
My guest today is Amit Chaudhary,the Director of Architecture at Infoservices and a member of the Low Code Security Alliance. He's also a 24 time certified Salesforce architect, Salesforce MVP hall of Famer, and the host of the popular Salesforce program Apex Hours.
Welcome Amit.
Amit Chaudhary,
00:00:39
Thank you so much Andrew to having me in your show.
Andrew Davis
00:00:42
That's a delight. Yeah.
Now I've known you for many years, at least from a distance from the Apex Hours podcast and I'd had a chance to be on your show a couple of times. I guess time for me to return the favorite you on here.
Very fun that we have a chance to talk today about a topic that was I know near and dear to your heart and something that's been very meaningful to me which is how to become a Salesforce Architect and how to build a successful career as a Salesforce architect. So yeah, when did you get started in this journey?
Amit Chaudhary,
00:01:18
I mean yeah, the very good question Andrew. So lots of people ask me this question. So to be very frank, I try run, I become. I'm working as an architect for more than five or six years.
So lots of people ask like how to become an architect. It's a great question.
Like all of the developer I see in the market, they are working on a Salesforce industry for more than 13 years but still working as a technical lead or working as a senior developer still doing the coding. And few people in the market I see there is like six and sevens of your experience and they started their journey as an architect.
Now the question is that how and when you decide you are an architect, it's a big question. So most of the thing like it started with the mindset.
It's not about numbers of experience, it's about how you see the things and how you see the bigger picture. So there are people who work on a project, they get a ticket assigned to them, they start working looking into that and fix the problem.
That is called a developer mindset. And there are people who work on epic level and saying that hey this is the epic.
They connected the dot and work for a single team looking into their own module where they are working for a PI, planning for A Sprint or something like that. So that kind of mindset I will say always have a developer lead mindset. They are looking into the model which they are working. That's it.
They don't care about what's happening in others area.
And architect is someone who is actually looking into the bigger picture, not looking into the epic, not only looking for their story, they are looking overall architecture, overall impact, how many systems are there into the system, how they are talking to each other, what will be happen if this scale of the data volume will be increased? What will be happen after five years. So it's all about a mindset. The person who is thinking what is happening today is that developer mindset.
Person who is only thinking about after six months is I can say like it's a tackled kind of mindset.
And the person who is looking into the bigger picture and thinking about where this product will be stand after couple of year that is called architecture mindset. So it's all about the thought.
So it's depend where you are thinking and what you are thinking that make you a tech developer, technical lead and architect.
Andrew Davis
00:03:53
I like that. It's very very simple, practical, grounded in topics that I think any developer or admin could understand.
The term that's coming to my mind when I hear that and I think about that is care. And do you care about what's going to happen five years from now? Do you care about the broader scope? And it takes energy to care.
So if you don't have a lot of time or energy and you just are assigned that one thing, your scope of care is relatively small. But is it appropriate to think about an architect as someone who cares on a bigger scale on a longer time horizon?
Amit Chaudhary,
00:04:36
Exactly. So it's all about what you care. Like there's another area also come into this picture.
If you only think about definitely you're looking for bigger picture, you're looking for the future. But then you take care about Salesforce saying that hey I only take care about Salesforce. I don't care what's happening in other system.
That means you're a salesforce architect. But when you are thinking about other system as well then you will become enterprise architect.
Andrew Davis
00:05:00
Okay, okay. So you mentioned about a developer moving in the direction of becoming an architect.
Is this also a career path that might be a future for admins or other people working on the Salesforce platform? Or is it more likely a developer?
Amit Chaudhary,
00:05:17
So definitely right. The architect is not about only technical. The architects should have a multiple hats. So they should know the business overall business Functionality.
Okay. They should know the domain, they should know the technical part and they should know they should be good into the communication.
If I'm talking, we are talking about admin and definitely if the admin know the business, admin have a good business awareness and they have a good communication skill and they have a skill to look into the bigger picture. Yes, they can be architect too and they don't need to be technical.
If they are not too technical, they will be always considered as a solution architect. But if they have a technical background then they become the technical architect. So that is the main difference.
Do you know the code or you do know the code but it doesn't mean the admin cannot be become an architect.
Yes, they can be architect and I see there are lots of people who are a CT as well who come from the admin background or the business background and they become it. As long as you have the business technical awareness, you're good. But yes, if you have a technical skill of coding that give you extra advantage.
Andrew Davis
00:06:37
That feels very, very helpful to frame the mind of an architect in terms of the scope of concern both I guess in, in the span of the technical system as well, time scale. I think there's so much to learn. It's very, very easy to feel inadequate like that.
I could never be an architect or I could never be a senior developer or something because I don't, I do know this, but there's so many other areas that I don't know.
But I think when you're describing this thinking at a high level, it doesn't mean that you necessarily know all of the detailed answers to all of the problems. It's just that you're, you're taking that, that level of responsibility. So that makes sense.
So when people are thinking so and when an architect is faced with a challenge, would you, how would they approach the solution? What do they think about before making a solution?
Amit Chaudhary,
00:07:29
Would you say so I always say like it's like a T concept, T principle. I will say so first of all, if you want to be an architect, approach it to the solution.
You should be have a good base, good base in terms of knowing the platform, sales, cloud, service, cloud platform.
And they should know about, they should know about that common understanding of cpq, CLM and other products of the salesforce and then they can go into deep so that make a T principle.
So in that when I say deep, they should know about how the integration work, how the SSO work, how, how the DevOps work, how the data integration work, data migration Work integration pattern work and so more so first of all know the platform and then go into deep, select the pet, select a particular area where you want to go deep. It can be a platform, it can be sales cloud, it can be sales service cloud, it can be cpq. It depend on you.
But being an architect, you should know a high levels of the platform very well so that whenever you need to design the solution, you know other platform instead of building the custom solution.
So take an example, if you don't know about cpq, you might be end up building something custom which is already there out of the box into the Salesforce. So that's the principles and thought. I will say an architect should always have it in mind.
Andrew Davis
00:08:56
Okay. And I guess you and I have some commonality in that we've both done a lot of Salesforce certifications.
I know when I had done a number of these certifications in areas that I didn't historically have much familiarity or working experience like integration architecture. It comes to mind when you say about going deep, right? So you understand broadly about how the platform works.
But then if you know, as in my case integration architecture was a weakness at that time.
But I studied and would you say that I studied and gained all of the sort of base knowledge about integration architecture in the Salesforce platform? Would you say that certifications are how do they fit into your architect training path? Would you say so?
Amit Chaudhary,
00:09:42
Definitely. Right. Having a knowledge.
But the one thing which you get from your study, which you get from your project, which you get and learn from your day to day activity, what you are doing in a project and making sure you know everything into that particular area that would come from the certification. Take an example.
If you're talking about integration, there might be possibility in your project you're not following all the patterns of integration, right? So you are might be using couple of things in your project and you're done. And you did not use explore everything.
But once you go and study for integration architect exam, then you will learn about lots of other things which you are not using. Same thing for. Take an example for access and identity, right? That is the most difficult exam I can say.
People are working on 2.0 pattern and they are working. Some people are only working on client secret. Somebody is working on web service architecture and people. Some people are not using JWT flow.
Once they will go in exam then only they will get to know hey, there are like seven, eight patterns are there. They might never use it. They will be go study more to get a deep knowledge. Few people are like just take theoretical knowledge to prepare for exam.
Some people are more active and go try to find and do some hands on.
So in this particular way I will say certification is very much important because the way it is designed it cover all the aspect which Salesforce industry have. So that will be give you lots of area where you might did not enter your fit.
So if you never enter into that area that will be give you opportunity to learn something more from that what I say from your exam guide. So it's a good opportunity for you to learn something new which might you did not encounter into your experience or in the project.
Andrew Davis
00:11:41
That makes a lot of sense and that aligns with my experience as well. Just kind of knowing you might not be an expert in all of these things, but you know that they exist, you know roughly how they fit together.
Um, and what's coming to mind as you're saying that is is just how big the Salesforce platform is and how big the world of technology is.
But you, you can't expect to be a a super deep expert in all of those areas but at least to kind of be able to orient yourself to the main key concepts. So you said you've been on this architect path for, for five or six years.
What would you say are some of the lessons you've learned in your work as an enterprise architecture?
Amit Chaudhary,
00:12:18
So definitely very good question. That word I say like the the first thing first never miss the discovery sessions.
Most of the person do it, they start directly jumping into the solution. Did not spend too much time into the discovery session. That is the first thing. And second thing, show empathy while solving the problem.
Listen that problem, understand other issues instead of blaming someone else. Hey, this was not working because of this and that. Just show empathy and look into that why it's happened. Understand the pain point of the customer.
And while designing the data model title don't jump into getting the data model. Most of the project I see in my life which is failed because of the wrong data model.
Where you see over the time you might heard hey this is a 10 year old org which is not working and I am facing Rolock issue, SoQL issues, 101 issues, CPQ time limit. This all happened because of the wrong data model. So focus time on that area and pretty much if you see like while doing it lots of customization.
Okay, I see like self was always recommended 20% code, 80% configuration. But after 5, 10 years what always we see into the project is reversed. They did lots of code, 80% of code and only 20% configuration.
And then you realize right what's happened Sometime Architect does not focus on the Salesforce product roadmap. They build something custom and then now after a year they say hey, it's come back, it's out of the box now.
And then once it's going production, trust me, people don't spend time to fix it.
People don't spend time to fix the tag depths because the business have always high priority on their feature and the tag depth is something which is not give an roi. So people don't prioritize that. They only take okay we have to solve it, but when to solve it, they don't have any priority list on it.
So that's happened. So fixing the tech dab, putting into priority list, putting into the backlog, that is very much important part.
Andrew Davis
00:14:47
This reminds me, there's a quote that I always remember and it's been influential for me. I think it's from Martin Fowler saying that architecture is those parts of the system that are hard to change afterwards.
And so you can imagine if if you're rushing into building the data model or rushing to solutioning, you may be making decisions that are hard to change afterwards.
And they can be hard to change also because as you say there's no ROI on just refactoring, but you've ended up with something that's a lot harder to support. So are the things that so you've talked about some of the things to avoid while doing solution architecture.
Like architecture like rushing into solutioning or not being aware of the native functionality and roadmap and especially rushing into data models. Anything else to watch out for and avoid?
Amit Chaudhary,
00:15:45
Definitely. Like some of the time I always see the architect is ignoring the ABE change. They are technical people, they know they can build it anytime, right?
I know they can build it. If you know the code, you can reinvent the wheels. But Navaric ignore the app Exchange product that is ready to so there are two concepts, right?
Build versus buy. If the product is already available I will be highly recommended check it into the App Exchange product if it is available.
I know if you have the capability you can build it.
But I will be highly recommended on AppExchange product and definitely most of the project I found over the time lack of governance and lack of documentation.
The project come, they delivered and when someone else take over it and start working it, they never find any architecture document or they did not see any governance body which I most of the time we face the multiple vendor come, multiple architect come, they implement the project and Go away. But after that when somebody on take responsibility of it this trauma.
Andrew Davis
00:16:59
So maybe that's something we can dive into in terms of this governance body or ongoing management. Because one of the things coming to mind you mentioned that the quality of an architect is thinking broadly, having a broad scope of concern.
And when you talk about governance, it's something similar. It's like a sustained, like a, a sustained process of making sure that you're considering all of the risks and the factors on an ongoing basis.
What, what. And having said that, you know, governance can also be associated with bureaucracy and a lot of overhead. And what does governance mean to you?
And are there ways to do it right, ways to do it wrong?
Amit Chaudhary,
00:17:46
So governance is a process or a principle or a rule which is set up what to do, how to do and best practices setup.
Take an example, right in the governance, you can set it up the process, how to create the document, how to get that BRD and how to follow the code quality click versus code rule. And setting up your architecture review board. Setting up the architecture review board is another way, right?
Then like I'm architect, you are also architect. So I have one way of thinking or solving the problem.
But if we have an architecture review board where the 10 different architect will become underplace, they're talking and I'm presenting my solution or you're presenting my solution, I might give you a pointer which you did not think about it or I might learn something from your solution which you know or I don't know. So I will say this kind of governance will be always helpful.
So in that particular way, sometime in the organization into enterprise level I found right, the multiple teams are working separately, they don't know what's going on. So there might be possibility I'm already building something which is already there in the organization.
So once that different architecture come into the architecture review board, they can discuss all this point. Hey, why you are not using the existing pattern, why you are not using this thing and that and similarly for the code quality and standard, right?
There are plenty of R trigger frameworks that are available in the market. All of them are good. There's no issue of any of them. But the problem starts.
Andrew Davis
00:19:26
Let me guess, don't use all of them. Use any R and B. Don't use all at the same time. Like choose one. Is that, is that where you're going?
Amit Chaudhary,
00:19:34
Exactly where I was about to go. So don't use all of them, right? So it doesn't mean if you pick someone and I pick someone, you are right. I'm wrong. No, everything is good.
The problems start Once we have a 2 and 3 framework in the same organization. And that is horrible and hard to maintain. So that kind of guidance should be documented and put it together.
A checklist should be there where we should have a code review best practices, we should have a coding standard, we should have the naming conventions and all of this should be documented. And there should be a code review process in place before getting the code deployed into production.
Which I see most of the time what's happened, right. But on the last day of Sprint they are trying to commit their code and the PO is having, are running behind.
Hey, we need to sign out, just do it and all and they skip that part and deploy. So I will always say like when you're doing it, you should have a process. Users have a process documented very well where give your developer time.
Hey, this process has to be followed. Just commit your code with X numbers of day before so that you will not skip this process, document it, make a cadence so that everyone will follow.
Andrew Davis
00:20:56
Makes sense. I mean what's coming to mind is I've spent a lot of time studying Lean as a, as an approach.
They have this, this idea called the five S's like Sort and Shine and so forth. It's just about maintaining cleanliness in your workspace. It came from the physical workspace.
And if you think about like a high quality, like, like an electrician, you know, there's ways of labeling the wires, you know, color coding that's used, cross checking, it's got to be, you know, inspected by a certified elect and so forth. And those kinds of practices have developed over decades and centuries in some cases.
I, I often think about the software world as a little bit like the wild west where you know, there's not an official, there's not an official certification body. Right.
I mean you could say Salesforce is doing some certification, but it's not at the same level as like fundamentals of engineering or professional engineering if you're, or license being a licensed contractor, if you're building physical things. But it is incredibly important this kind of attention to care and detail. You mentioned coding like coding standards and review and so forth.
That falls under the umbrella of an architect's responsibility setting these code guidelines.
Amit Chaudhary,
00:22:22
And yeah, definitely it's a responsibility of architect or it can be a joint responsibility with the architect and a tech lead to build it. But architects should know about it, review it and build it.
That is what the process I will say so that they should have the common framework Documented. Take an example. It can be logger, it will be trigger, it can be coding standards, naming conventions, design patterns, integration framework.
If we are using anything this, if this is all documented properly so that that can be shared across the team so that whenever anyone will be start working on it, they will be using those document as the bible to make sure they are following it.
Andrew Davis
00:23:12
Okay, fantastic. And then I mean again even at the level of like like you don't want to use multiple trigger frameworks.
It's much more beneficial to have standardization across the coding practices. Are you a fan of these automatic code reformatting tools like prettier JS and so forth?
Amit Chaudhary,
00:23:36
That yeah, definitely. Right. I'm big fan of all these tools.
Andrew Davis
00:23:40
Right.
Amit Chaudhary,
00:23:41
There are plenty of rules that are available in the market. I would always recommend it. Code review is important but never do the tasks which machine can do it.
Okay, so and what I mean to say, plenty of softwares are available. You can use checkmarks, you can use Apex pmd.
There are multiple open source use it and if you have a luxury of budget go and buy lots of other tools market based on your budget. Buy it and use it. Use the tool, don't waste the time. Which machine can do it for you.
That is what the pattern and that is where right now you can see the AI is going to involve and machine is doing lots of work. So that will be the future. Right. People want it doesn't mean the AI is coming and it will be kill the job.
No, it will be needed the people who use AI or use the automation or use the tool. So we have to be active into that particular area.
Andrew Davis
00:24:44
Nice, nice, nice, nice. I think I need to give a shout out to codescan.
So if you have the budget and really really want like a really strong tool then codescan I'd strongly recommend but I'm biased.
Amit Chaudhary,
00:24:58
I'm currently using for one of my client. It's a good tool. So that's what I say. There are open source tools and then there are paid tool as well. How deep your client pocket is there go.
According to that it definitely are going with the custom open source. It's have a limited functionality. If we are talking about you have a paid one definitely it will give more feature to you. So it's all about pocket.
So if you have a pocket and budget go and buy it. So that what I initially picked that topic called epic Change. There are products which are ready build versus buy.
Andrew Davis
00:25:34
So yeah, exactly as you said. Right. And I guess that's an example. So you talked about Build versus buy.
You know, if you wanted to implement, you know, a document generation solution, you know, why would you build that yourself? And so forth. But here it's almost like, it's almost like code review as a service. So you're.
If you were to buy a tool like that, you're buying something that helps train the developers, give feedback, help enforce standards and so forth. And that's. There's a substantial value over time to having tooling that is supporting a high quality process. That makes sense.
So you talked about governance bodies, you talked about an architecture review board. There's another concept that's very popular, comes up especially when you have multiple production orgs, which is a center of excellence.
Would you agree that a center of excellence is a type of governance body or do you think of it separately as more of an enabler, supporting tool or support, sorry, supporting body.
Amit Chaudhary,
00:26:38
So COE is a bigger term. Some people call COE C4E different name. Center of excellence. Right, so that is what is where actually it's about architecture. I don't have.
I wish it is a presentation. I can show you the architecture, how it should look like. But again, right, if you want to build it, you need a steering committee who can sponsor it.
And then under it, like we talk about architecture review board, design authority, having the project management team compliances, you can bring all of them together and assigning the different responsibility, whatever. We talk about the architecture review board and code review and functionality, that is only one part.
Apart from that there's vendor management, there is a project management and there's a lots of other part come into the picture. So in short, if you're coming to the CoE, it's a bigger term. But if you're talking about the governance, yes, COE come under the governance.
Andrew Davis
00:27:41
Okay, so you say coe or I.
Amit Chaudhary,
00:27:42
Can say governance come under the COE governance.
Andrew Davis
00:27:46
Governance comes under the COE in the sense that it is a one of the responsibilities of the coe. But COE comes under governance in the sense that it's like a. It's a structure and a body that can help and support that.
I think I should make a shout out to my friend Velu Pilani and Charlie Havens just wrote a book called A Master Framework for the CRM center of Excellence. It's the first time I think there's been a dedicated book about COEs. At what point would you set up a COE? Would you say?
At what point does it make sense to have such a center of excellence, center for enablement.
Amit Chaudhary,
00:28:23
So let me tell you, right, Everyone wants you in the project but the problem come up with the budget, okay, who is ready to spend money on it? Who is wanting to hire people? Who is running all these things? Because there are two things, right? One is the roi.
The question come up do you have a budget to run all these things and having the people for doing that governance work and not working on the technical stories and the technical features. If people have a budget, they go for it.
But I will always highly recommend it go for it because that actually reduce your cost into the maintenance phase.
Might not give you something for today at the time of build phase, but that will be always save Your cost around 30 to 40% because majority of the project if you see they go live quickly. But most of the life time spent on the project 70, 80% is maintenance. So maintenance fixing the attack depth.
If you have this, that is the place where you are going to save your time.
Where you're it will be giving that output and having that the CoE, right the tab ops is also part of release management is also part of the COE if you maintain it properly.
Having a proper release manager, having a proper DevOps tools that will be save your 30 to 40% of go to market time for taking the product into the production so that all part of the coe. So if you are asking me, I will say every project should have it. If it is a.
It is a medium or enterprise that always should have the COE into the place. I'm not saying for the smaller project, but it depends smaller project have a different definition, right? So you should always have it.
Andrew Davis
00:30:19
It's interesting there's a. I'm doing the math in my head where you're saying, you know, 70 or 80% of the total costs of any implementation are on the long term maintenance.
So I guess by the numbers if you sort of, sort of invert that so you. You invest a million dollars in a certain, you know, project initiative.
You're suggesting that although that looks like you know that's the main cost, it may only, you know the total cost of ownership may be 4 million, 5 million over. Over the life of the project. Imagining that's 10 years or whatever. And that if you can reduce that cost right by 40% or something like that, you're.
That is a. That's potentially substantial cost savings over time.
It also seems to me that there's a parallel you keep mentioning about, you know, it depends on how deep your pockets are, how much money you're now where you're willing to spend money is really a question of what do you care about and it's, it's.
There's almost a parallel between when you say, you know, moving from a developer to a dev lead to an architect to somebody who cares, you know, at a higher scale, longer timeline. And there's a, there's a, there's, there's a kind of wisdom in that. Right? There's a, there's a wisdom born.
We didn't really talk about it when we talked about this question about how does somebody become an architect. But one thing that came to my mind is you become an architect through painful experience.
You know, you realize, you know, three years later you should have done things very differently and then you're trying to warn everybody else, don't do it like that. Right. And so I don't know if that's. That is similar to your architect journey.
But like there's a wisdom of knowing that you need to care about these larger scale, longer term issues architecturally. And that same wisdom, I guess would manifest in being willing to invest in tools or invest in a coe. Is that a fair summary?
Amit Chaudhary,
00:32:13
Yep, exactly. You're absolutely right.
Andrew Davis
00:32:17
So is your architect journey a bit born through painful experience? Wanting to warn other people not to make mistakes you'd seen?
Amit Chaudhary,
00:32:25
Yeah, definitely. Right. I cover a couple of point which you should take care and what you should not do it in the project. Right. Don't missing that discovery session.
Take care of epic change product and showing them empathy while solving the problem. Take care about data model and using and most of the thing. Right.
Once you're a Salesforce architect, you always think to build everything on Salesforce. Don't use Salesforce for everything. Okay.
You should know when to use Salesforce and when not to use Salesforce and always remember that governor limit into the Salesforce. Right. So know the limitation of the platform and he should know when you should use the Salesforce and when you should not use the Salesforce.
When I'm saying not use the Salesforce it doesn't mean you should go with other tool. I mean to say the Salesforce have lots of other tools like root cause and lots of other platform which you can leverage and use it.
So you should know where to do large data, how to handle the large data volume and what to do and which particular tool we need to use.
So you should know the landscape of the whole Salesforce ecosystem as well as the limitations as well as the Salesforce governor limit and knowing that the Salesforce limitations.
Andrew Davis
00:33:47
Okay, makes sense. I guess this is a way to we close out. We've talked about the mindset of becoming an architect. Some of the things you'd pay attention to.
Any career tips, you know, career development guidelines and so forth?
Amit Chaudhary,
00:34:03
Yeah, definitely. I will say the first step, become the technical experts. Then learn about the business.
You should have the business expertise, knowing the domain and work on your communication because that is very much important.
When you are coming to the leadership skills, especially architect, you should know when to talk, what to talk in front of which audience are you talking to the business. Then don't talk technical language to them, talk about business language to them.
And if you are talking to your offshore team or your development team, you should know how to communicate your solution very well to the development team so that what you are thinking to build, they also know what to build. You should be perfect in communication. The communication have a different skills. Okay.
You should know how to talk to C level people and you also know to know how to talk to developers so that they understand what you are thinking to build and they build it accordingly. And then definitely once you have all this thing, then look into the bigger picture. Think about the future scope, LDV and enhancement of the project.
Because it's not about you build a project today you are done. That what I'm saying. Most of the project license spending around 70% into their maintenance and enhancement. Right.
So if you build something for today, it's really hard sometime to enhance that product. So you should know if you have these four skills, you're all good.
Become the technical expertise, learn about business and learn how to communicate and look into the bigger picture. This is the four key things I will say everyone should know in the Salesforce ecosystem.
Andrew Davis
00:35:55
Okay, it sounds almost like a translator. Someone who knows how to translate the technical language in the business terms, the business language into technical terms and so forth.
I'm reminded there's an analogy.
There's a book, the Software Architect's Elevator by Gregor Hope who's introduces some some similar concepts about being able to go from the C suite up in the penthouse down to the where the developers live in the basement and so forth and you know, go to all those levels. I don't know. Amit, this has been fantastic. I'm really very grateful to hear your your overview and I know you're.
You're currently responsible for managing a team of architects at at Infoservices, is that right?
Amit Chaudhary,
00:36:39
Yes, I'm the architecture of Salesforce Practice where I'm leading team of architect. Yes.
Andrew Davis
00:36:47
Okay. And tell me a bit more about Infoservices.
Amit Chaudhary,
00:36:50
Yeah, definitely.
So Infoservice is more and all Salesforce implementation partner where we are working on multiple client and taking care of the end to end software implementation. So we are working on a different stream, Salesforce, aws, Databricks. So yeah, that's all about us.
Andrew Davis
00:37:11
Okay. Fantastic. Right? So we've really grateful for the overview that architecture is.
I think the key point that I'm taking away is that architecture is all about mindset, that sort of broader scope of concern and that you need to learn these four domains of communication as well. From a technical point of view, the certifications. Architecture certifications are a powerful way to make sure your learning is very broad.
We talked about, I'm just checking my notes here.
Talked about the importance of these discovery sessions where the architect really understands at a high level what is the goal the customer is trying to accomplish and to show empathy.
They're not rushing into building solutions, relying on governance bodies, building structures like architecture review boards to benefit from everybody's collective knowledge and then not using Salesforce for everything, not using, not using it where it's not necessarily the best solution, but having that breadth of understanding. So Amit, thank you so much for joining us today.
Amit Chaudhary,
00:38:22
Thank you so much, Andrew, for having me.
Andrew Davis
00:38:24
A great pleasure, Amit. Be sure to subscribe wherever you stream podcasts so you don't miss out on illuminating conversations with industry leaders like Amit.
You can also Visit us@autorabbit.com for show notes, helpful links, and access to every episode as they're released. So stay safe out there and we'll see you next time.
00:00:00
From Code to the Cloud cuts through the noise to get to what really matters. The insights and tactics that help you maintain a consistently secure and productive DevOps strategy.
Welcome to From Code to the Cloud, a DevSecOps podcast focused on the Salesforce ecosystem. I'm Andrew Davis, Chief Product Officer at autorabbit and I'll be your host.
My guest today is Amit Chaudhary,the Director of Architecture at Infoservices and a member of the Low Code Security Alliance. He's also a 24 time certified Salesforce architect, Salesforce MVP hall of Famer, and the host of the popular Salesforce program Apex Hours.
Welcome Amit.
Amit Chaudhary,
00:00:39
Thank you so much Andrew to having me in your show.
Andrew Davis
00:00:42
That's a delight. Yeah.
Now I've known you for many years, at least from a distance from the Apex Hours podcast and I'd had a chance to be on your show a couple of times. I guess time for me to return the favorite you on here.
Very fun that we have a chance to talk today about a topic that was I know near and dear to your heart and something that's been very meaningful to me which is how to become a Salesforce Architect and how to build a successful career as a Salesforce architect. So yeah, when did you get started in this journey?
Amit Chaudhary,
00:01:18
I mean yeah, the very good question Andrew. So lots of people ask me this question. So to be very frank, I try run, I become. I'm working as an architect for more than five or six years.
So lots of people ask like how to become an architect. It's a great question.
Like all of the developer I see in the market, they are working on a Salesforce industry for more than 13 years but still working as a technical lead or working as a senior developer still doing the coding. And few people in the market I see there is like six and sevens of your experience and they started their journey as an architect.
Now the question is that how and when you decide you are an architect, it's a big question. So most of the thing like it started with the mindset.
It's not about numbers of experience, it's about how you see the things and how you see the bigger picture. So there are people who work on a project, they get a ticket assigned to them, they start working looking into that and fix the problem.
That is called a developer mindset. And there are people who work on epic level and saying that hey this is the epic.
They connected the dot and work for a single team looking into their own module where they are working for a PI, planning for A Sprint or something like that. So that kind of mindset I will say always have a developer lead mindset. They are looking into the model which they are working. That's it.
They don't care about what's happening in others area.
And architect is someone who is actually looking into the bigger picture, not looking into the epic, not only looking for their story, they are looking overall architecture, overall impact, how many systems are there into the system, how they are talking to each other, what will be happen if this scale of the data volume will be increased? What will be happen after five years. So it's all about a mindset. The person who is thinking what is happening today is that developer mindset.
Person who is only thinking about after six months is I can say like it's a tackled kind of mindset.
And the person who is looking into the bigger picture and thinking about where this product will be stand after couple of year that is called architecture mindset. So it's all about the thought.
So it's depend where you are thinking and what you are thinking that make you a tech developer, technical lead and architect.
Andrew Davis
00:03:53
I like that. It's very very simple, practical, grounded in topics that I think any developer or admin could understand.
The term that's coming to my mind when I hear that and I think about that is care. And do you care about what's going to happen five years from now? Do you care about the broader scope? And it takes energy to care.
So if you don't have a lot of time or energy and you just are assigned that one thing, your scope of care is relatively small. But is it appropriate to think about an architect as someone who cares on a bigger scale on a longer time horizon?
Amit Chaudhary,
00:04:36
Exactly. So it's all about what you care. Like there's another area also come into this picture.
If you only think about definitely you're looking for bigger picture, you're looking for the future. But then you take care about Salesforce saying that hey I only take care about Salesforce. I don't care what's happening in other system.
That means you're a salesforce architect. But when you are thinking about other system as well then you will become enterprise architect.
Andrew Davis
00:05:00
Okay, okay. So you mentioned about a developer moving in the direction of becoming an architect.
Is this also a career path that might be a future for admins or other people working on the Salesforce platform? Or is it more likely a developer?
Amit Chaudhary,
00:05:17
So definitely right. The architect is not about only technical. The architects should have a multiple hats. So they should know the business overall business Functionality.
Okay. They should know the domain, they should know the technical part and they should know they should be good into the communication.
If I'm talking, we are talking about admin and definitely if the admin know the business, admin have a good business awareness and they have a good communication skill and they have a skill to look into the bigger picture. Yes, they can be architect too and they don't need to be technical.
If they are not too technical, they will be always considered as a solution architect. But if they have a technical background then they become the technical architect. So that is the main difference.
Do you know the code or you do know the code but it doesn't mean the admin cannot be become an architect.
Yes, they can be architect and I see there are lots of people who are a CT as well who come from the admin background or the business background and they become it. As long as you have the business technical awareness, you're good. But yes, if you have a technical skill of coding that give you extra advantage.
Andrew Davis
00:06:37
That feels very, very helpful to frame the mind of an architect in terms of the scope of concern both I guess in, in the span of the technical system as well, time scale. I think there's so much to learn. It's very, very easy to feel inadequate like that.
I could never be an architect or I could never be a senior developer or something because I don't, I do know this, but there's so many other areas that I don't know.
But I think when you're describing this thinking at a high level, it doesn't mean that you necessarily know all of the detailed answers to all of the problems. It's just that you're, you're taking that, that level of responsibility. So that makes sense.
So when people are thinking so and when an architect is faced with a challenge, would you, how would they approach the solution? What do they think about before making a solution?
Amit Chaudhary,
00:07:29
Would you say so I always say like it's like a T concept, T principle. I will say so first of all, if you want to be an architect, approach it to the solution.
You should be have a good base, good base in terms of knowing the platform, sales, cloud, service, cloud platform.
And they should know about, they should know about that common understanding of cpq, CLM and other products of the salesforce and then they can go into deep so that make a T principle.
So in that when I say deep, they should know about how the integration work, how the SSO work, how, how the DevOps work, how the data integration work, data migration Work integration pattern work and so more so first of all know the platform and then go into deep, select the pet, select a particular area where you want to go deep. It can be a platform, it can be sales cloud, it can be sales service cloud, it can be cpq. It depend on you.
But being an architect, you should know a high levels of the platform very well so that whenever you need to design the solution, you know other platform instead of building the custom solution.
So take an example, if you don't know about cpq, you might be end up building something custom which is already there out of the box into the Salesforce. So that's the principles and thought. I will say an architect should always have it in mind.
Andrew Davis
00:08:56
Okay. And I guess you and I have some commonality in that we've both done a lot of Salesforce certifications.
I know when I had done a number of these certifications in areas that I didn't historically have much familiarity or working experience like integration architecture. It comes to mind when you say about going deep, right? So you understand broadly about how the platform works.
But then if you know, as in my case integration architecture was a weakness at that time.
But I studied and would you say that I studied and gained all of the sort of base knowledge about integration architecture in the Salesforce platform? Would you say that certifications are how do they fit into your architect training path? Would you say so?
Amit Chaudhary,
00:09:42
Definitely. Right. Having a knowledge.
But the one thing which you get from your study, which you get from your project, which you get and learn from your day to day activity, what you are doing in a project and making sure you know everything into that particular area that would come from the certification. Take an example.
If you're talking about integration, there might be possibility in your project you're not following all the patterns of integration, right? So you are might be using couple of things in your project and you're done. And you did not use explore everything.
But once you go and study for integration architect exam, then you will learn about lots of other things which you are not using. Same thing for. Take an example for access and identity, right? That is the most difficult exam I can say.
People are working on 2.0 pattern and they are working. Some people are only working on client secret. Somebody is working on web service architecture and people. Some people are not using JWT flow.
Once they will go in exam then only they will get to know hey, there are like seven, eight patterns are there. They might never use it. They will be go study more to get a deep knowledge. Few people are like just take theoretical knowledge to prepare for exam.
Some people are more active and go try to find and do some hands on.
So in this particular way I will say certification is very much important because the way it is designed it cover all the aspect which Salesforce industry have. So that will be give you lots of area where you might did not enter your fit.
So if you never enter into that area that will be give you opportunity to learn something more from that what I say from your exam guide. So it's a good opportunity for you to learn something new which might you did not encounter into your experience or in the project.
Andrew Davis
00:11:41
That makes a lot of sense and that aligns with my experience as well. Just kind of knowing you might not be an expert in all of these things, but you know that they exist, you know roughly how they fit together.
Um, and what's coming to mind as you're saying that is is just how big the Salesforce platform is and how big the world of technology is.
But you, you can't expect to be a a super deep expert in all of those areas but at least to kind of be able to orient yourself to the main key concepts. So you said you've been on this architect path for, for five or six years.
What would you say are some of the lessons you've learned in your work as an enterprise architecture?
Amit Chaudhary,
00:12:18
So definitely very good question. That word I say like the the first thing first never miss the discovery sessions.
Most of the person do it, they start directly jumping into the solution. Did not spend too much time into the discovery session. That is the first thing. And second thing, show empathy while solving the problem.
Listen that problem, understand other issues instead of blaming someone else. Hey, this was not working because of this and that. Just show empathy and look into that why it's happened. Understand the pain point of the customer.
And while designing the data model title don't jump into getting the data model. Most of the project I see in my life which is failed because of the wrong data model.
Where you see over the time you might heard hey this is a 10 year old org which is not working and I am facing Rolock issue, SoQL issues, 101 issues, CPQ time limit. This all happened because of the wrong data model. So focus time on that area and pretty much if you see like while doing it lots of customization.
Okay, I see like self was always recommended 20% code, 80% configuration. But after 5, 10 years what always we see into the project is reversed. They did lots of code, 80% of code and only 20% configuration.
And then you realize right what's happened Sometime Architect does not focus on the Salesforce product roadmap. They build something custom and then now after a year they say hey, it's come back, it's out of the box now.
And then once it's going production, trust me, people don't spend time to fix it.
People don't spend time to fix the tag depths because the business have always high priority on their feature and the tag depth is something which is not give an roi. So people don't prioritize that. They only take okay we have to solve it, but when to solve it, they don't have any priority list on it.
So that's happened. So fixing the tech dab, putting into priority list, putting into the backlog, that is very much important part.
Andrew Davis
00:14:47
This reminds me, there's a quote that I always remember and it's been influential for me. I think it's from Martin Fowler saying that architecture is those parts of the system that are hard to change afterwards.
And so you can imagine if if you're rushing into building the data model or rushing to solutioning, you may be making decisions that are hard to change afterwards.
And they can be hard to change also because as you say there's no ROI on just refactoring, but you've ended up with something that's a lot harder to support. So are the things that so you've talked about some of the things to avoid while doing solution architecture.
Like architecture like rushing into solutioning or not being aware of the native functionality and roadmap and especially rushing into data models. Anything else to watch out for and avoid?
Amit Chaudhary,
00:15:45
Definitely. Like some of the time I always see the architect is ignoring the ABE change. They are technical people, they know they can build it anytime, right?
I know they can build it. If you know the code, you can reinvent the wheels. But Navaric ignore the app Exchange product that is ready to so there are two concepts, right?
Build versus buy. If the product is already available I will be highly recommended check it into the App Exchange product if it is available.
I know if you have the capability you can build it.
But I will be highly recommended on AppExchange product and definitely most of the project I found over the time lack of governance and lack of documentation.
The project come, they delivered and when someone else take over it and start working it, they never find any architecture document or they did not see any governance body which I most of the time we face the multiple vendor come, multiple architect come, they implement the project and Go away. But after that when somebody on take responsibility of it this trauma.
Andrew Davis
00:16:59
So maybe that's something we can dive into in terms of this governance body or ongoing management. Because one of the things coming to mind you mentioned that the quality of an architect is thinking broadly, having a broad scope of concern.
And when you talk about governance, it's something similar. It's like a sustained, like a, a sustained process of making sure that you're considering all of the risks and the factors on an ongoing basis.
What, what. And having said that, you know, governance can also be associated with bureaucracy and a lot of overhead. And what does governance mean to you?
And are there ways to do it right, ways to do it wrong?
Amit Chaudhary,
00:17:46
So governance is a process or a principle or a rule which is set up what to do, how to do and best practices setup.
Take an example, right in the governance, you can set it up the process, how to create the document, how to get that BRD and how to follow the code quality click versus code rule. And setting up your architecture review board. Setting up the architecture review board is another way, right?
Then like I'm architect, you are also architect. So I have one way of thinking or solving the problem.
But if we have an architecture review board where the 10 different architect will become underplace, they're talking and I'm presenting my solution or you're presenting my solution, I might give you a pointer which you did not think about it or I might learn something from your solution which you know or I don't know. So I will say this kind of governance will be always helpful.
So in that particular way, sometime in the organization into enterprise level I found right, the multiple teams are working separately, they don't know what's going on. So there might be possibility I'm already building something which is already there in the organization.
So once that different architecture come into the architecture review board, they can discuss all this point. Hey, why you are not using the existing pattern, why you are not using this thing and that and similarly for the code quality and standard, right?
There are plenty of R trigger frameworks that are available in the market. All of them are good. There's no issue of any of them. But the problem starts.
Andrew Davis
00:19:26
Let me guess, don't use all of them. Use any R and B. Don't use all at the same time. Like choose one. Is that, is that where you're going?
Amit Chaudhary,
00:19:34
Exactly where I was about to go. So don't use all of them, right? So it doesn't mean if you pick someone and I pick someone, you are right. I'm wrong. No, everything is good.
The problems start Once we have a 2 and 3 framework in the same organization. And that is horrible and hard to maintain. So that kind of guidance should be documented and put it together.
A checklist should be there where we should have a code review best practices, we should have a coding standard, we should have the naming conventions and all of this should be documented. And there should be a code review process in place before getting the code deployed into production.
Which I see most of the time what's happened, right. But on the last day of Sprint they are trying to commit their code and the PO is having, are running behind.
Hey, we need to sign out, just do it and all and they skip that part and deploy. So I will always say like when you're doing it, you should have a process. Users have a process documented very well where give your developer time.
Hey, this process has to be followed. Just commit your code with X numbers of day before so that you will not skip this process, document it, make a cadence so that everyone will follow.
Andrew Davis
00:20:56
Makes sense. I mean what's coming to mind is I've spent a lot of time studying Lean as a, as an approach.
They have this, this idea called the five S's like Sort and Shine and so forth. It's just about maintaining cleanliness in your workspace. It came from the physical workspace.
And if you think about like a high quality, like, like an electrician, you know, there's ways of labeling the wires, you know, color coding that's used, cross checking, it's got to be, you know, inspected by a certified elect and so forth. And those kinds of practices have developed over decades and centuries in some cases.
I, I often think about the software world as a little bit like the wild west where you know, there's not an official, there's not an official certification body. Right.
I mean you could say Salesforce is doing some certification, but it's not at the same level as like fundamentals of engineering or professional engineering if you're, or license being a licensed contractor, if you're building physical things. But it is incredibly important this kind of attention to care and detail. You mentioned coding like coding standards and review and so forth.
That falls under the umbrella of an architect's responsibility setting these code guidelines.
Amit Chaudhary,
00:22:22
And yeah, definitely it's a responsibility of architect or it can be a joint responsibility with the architect and a tech lead to build it. But architects should know about it, review it and build it.
That is what the process I will say so that they should have the common framework Documented. Take an example. It can be logger, it will be trigger, it can be coding standards, naming conventions, design patterns, integration framework.
If we are using anything this, if this is all documented properly so that that can be shared across the team so that whenever anyone will be start working on it, they will be using those document as the bible to make sure they are following it.
Andrew Davis
00:23:12
Okay, fantastic. And then I mean again even at the level of like like you don't want to use multiple trigger frameworks.
It's much more beneficial to have standardization across the coding practices. Are you a fan of these automatic code reformatting tools like prettier JS and so forth?
Amit Chaudhary,
00:23:36
That yeah, definitely. Right. I'm big fan of all these tools.
Andrew Davis
00:23:40
Right.
Amit Chaudhary,
00:23:41
There are plenty of rules that are available in the market. I would always recommend it. Code review is important but never do the tasks which machine can do it.
Okay, so and what I mean to say, plenty of softwares are available. You can use checkmarks, you can use Apex pmd.
There are multiple open source use it and if you have a luxury of budget go and buy lots of other tools market based on your budget. Buy it and use it. Use the tool, don't waste the time. Which machine can do it for you.
That is what the pattern and that is where right now you can see the AI is going to involve and machine is doing lots of work. So that will be the future. Right. People want it doesn't mean the AI is coming and it will be kill the job.
No, it will be needed the people who use AI or use the automation or use the tool. So we have to be active into that particular area.
Andrew Davis
00:24:44
Nice, nice, nice, nice. I think I need to give a shout out to codescan.
So if you have the budget and really really want like a really strong tool then codescan I'd strongly recommend but I'm biased.
Amit Chaudhary,
00:24:58
I'm currently using for one of my client. It's a good tool. So that's what I say. There are open source tools and then there are paid tool as well. How deep your client pocket is there go.
According to that it definitely are going with the custom open source. It's have a limited functionality. If we are talking about you have a paid one definitely it will give more feature to you. So it's all about pocket.
So if you have a pocket and budget go and buy it. So that what I initially picked that topic called epic Change. There are products which are ready build versus buy.
Andrew Davis
00:25:34
So yeah, exactly as you said. Right. And I guess that's an example. So you talked about Build versus buy.
You know, if you wanted to implement, you know, a document generation solution, you know, why would you build that yourself? And so forth. But here it's almost like, it's almost like code review as a service. So you're.
If you were to buy a tool like that, you're buying something that helps train the developers, give feedback, help enforce standards and so forth. And that's. There's a substantial value over time to having tooling that is supporting a high quality process. That makes sense.
So you talked about governance bodies, you talked about an architecture review board. There's another concept that's very popular, comes up especially when you have multiple production orgs, which is a center of excellence.
Would you agree that a center of excellence is a type of governance body or do you think of it separately as more of an enabler, supporting tool or support, sorry, supporting body.
Amit Chaudhary,
00:26:38
So COE is a bigger term. Some people call COE C4E different name. Center of excellence. Right, so that is what is where actually it's about architecture. I don't have.
I wish it is a presentation. I can show you the architecture, how it should look like. But again, right, if you want to build it, you need a steering committee who can sponsor it.
And then under it, like we talk about architecture review board, design authority, having the project management team compliances, you can bring all of them together and assigning the different responsibility, whatever. We talk about the architecture review board and code review and functionality, that is only one part.
Apart from that there's vendor management, there is a project management and there's a lots of other part come into the picture. So in short, if you're coming to the CoE, it's a bigger term. But if you're talking about the governance, yes, COE come under the governance.
Andrew Davis
00:27:41
Okay, so you say coe or I.
Amit Chaudhary,
00:27:42
Can say governance come under the COE governance.
Andrew Davis
00:27:46
Governance comes under the COE in the sense that it is a one of the responsibilities of the coe. But COE comes under governance in the sense that it's like a. It's a structure and a body that can help and support that.
I think I should make a shout out to my friend Velu Pilani and Charlie Havens just wrote a book called A Master Framework for the CRM center of Excellence. It's the first time I think there's been a dedicated book about COEs. At what point would you set up a COE? Would you say?
At what point does it make sense to have such a center of excellence, center for enablement.
Amit Chaudhary,
00:28:23
So let me tell you, right, Everyone wants you in the project but the problem come up with the budget, okay, who is ready to spend money on it? Who is wanting to hire people? Who is running all these things? Because there are two things, right? One is the roi.
The question come up do you have a budget to run all these things and having the people for doing that governance work and not working on the technical stories and the technical features. If people have a budget, they go for it.
But I will always highly recommend it go for it because that actually reduce your cost into the maintenance phase.
Might not give you something for today at the time of build phase, but that will be always save Your cost around 30 to 40% because majority of the project if you see they go live quickly. But most of the life time spent on the project 70, 80% is maintenance. So maintenance fixing the attack depth.
If you have this, that is the place where you are going to save your time.
Where you're it will be giving that output and having that the CoE, right the tab ops is also part of release management is also part of the COE if you maintain it properly.
Having a proper release manager, having a proper DevOps tools that will be save your 30 to 40% of go to market time for taking the product into the production so that all part of the coe. So if you are asking me, I will say every project should have it. If it is a.
It is a medium or enterprise that always should have the COE into the place. I'm not saying for the smaller project, but it depends smaller project have a different definition, right? So you should always have it.
Andrew Davis
00:30:19
It's interesting there's a. I'm doing the math in my head where you're saying, you know, 70 or 80% of the total costs of any implementation are on the long term maintenance.
So I guess by the numbers if you sort of, sort of invert that so you. You invest a million dollars in a certain, you know, project initiative.
You're suggesting that although that looks like you know that's the main cost, it may only, you know the total cost of ownership may be 4 million, 5 million over. Over the life of the project. Imagining that's 10 years or whatever. And that if you can reduce that cost right by 40% or something like that, you're.
That is a. That's potentially substantial cost savings over time.
It also seems to me that there's a parallel you keep mentioning about, you know, it depends on how deep your pockets are, how much money you're now where you're willing to spend money is really a question of what do you care about and it's, it's.
There's almost a parallel between when you say, you know, moving from a developer to a dev lead to an architect to somebody who cares, you know, at a higher scale, longer timeline. And there's a, there's a, there's, there's a kind of wisdom in that. Right? There's a, there's a wisdom born.
We didn't really talk about it when we talked about this question about how does somebody become an architect. But one thing that came to my mind is you become an architect through painful experience.
You know, you realize, you know, three years later you should have done things very differently and then you're trying to warn everybody else, don't do it like that. Right. And so I don't know if that's. That is similar to your architect journey.
But like there's a wisdom of knowing that you need to care about these larger scale, longer term issues architecturally. And that same wisdom, I guess would manifest in being willing to invest in tools or invest in a coe. Is that a fair summary?
Amit Chaudhary,
00:32:13
Yep, exactly. You're absolutely right.
Andrew Davis
00:32:17
So is your architect journey a bit born through painful experience? Wanting to warn other people not to make mistakes you'd seen?
Amit Chaudhary,
00:32:25
Yeah, definitely. Right. I cover a couple of point which you should take care and what you should not do it in the project. Right. Don't missing that discovery session.
Take care of epic change product and showing them empathy while solving the problem. Take care about data model and using and most of the thing. Right.
Once you're a Salesforce architect, you always think to build everything on Salesforce. Don't use Salesforce for everything. Okay.
You should know when to use Salesforce and when not to use Salesforce and always remember that governor limit into the Salesforce. Right. So know the limitation of the platform and he should know when you should use the Salesforce and when you should not use the Salesforce.
When I'm saying not use the Salesforce it doesn't mean you should go with other tool. I mean to say the Salesforce have lots of other tools like root cause and lots of other platform which you can leverage and use it.
So you should know where to do large data, how to handle the large data volume and what to do and which particular tool we need to use.
So you should know the landscape of the whole Salesforce ecosystem as well as the limitations as well as the Salesforce governor limit and knowing that the Salesforce limitations.
Andrew Davis
00:33:47
Okay, makes sense. I guess this is a way to we close out. We've talked about the mindset of becoming an architect. Some of the things you'd pay attention to.
Any career tips, you know, career development guidelines and so forth?
Amit Chaudhary,
00:34:03
Yeah, definitely. I will say the first step, become the technical experts. Then learn about the business.
You should have the business expertise, knowing the domain and work on your communication because that is very much important.
When you are coming to the leadership skills, especially architect, you should know when to talk, what to talk in front of which audience are you talking to the business. Then don't talk technical language to them, talk about business language to them.
And if you are talking to your offshore team or your development team, you should know how to communicate your solution very well to the development team so that what you are thinking to build, they also know what to build. You should be perfect in communication. The communication have a different skills. Okay.
You should know how to talk to C level people and you also know to know how to talk to developers so that they understand what you are thinking to build and they build it accordingly. And then definitely once you have all this thing, then look into the bigger picture. Think about the future scope, LDV and enhancement of the project.
Because it's not about you build a project today you are done. That what I'm saying. Most of the project license spending around 70% into their maintenance and enhancement. Right.
So if you build something for today, it's really hard sometime to enhance that product. So you should know if you have these four skills, you're all good.
Become the technical expertise, learn about business and learn how to communicate and look into the bigger picture. This is the four key things I will say everyone should know in the Salesforce ecosystem.
Andrew Davis
00:35:55
Okay, it sounds almost like a translator. Someone who knows how to translate the technical language in the business terms, the business language into technical terms and so forth.
I'm reminded there's an analogy.
There's a book, the Software Architect's Elevator by Gregor Hope who's introduces some some similar concepts about being able to go from the C suite up in the penthouse down to the where the developers live in the basement and so forth and you know, go to all those levels. I don't know. Amit, this has been fantastic. I'm really very grateful to hear your your overview and I know you're.
You're currently responsible for managing a team of architects at at Infoservices, is that right?
Amit Chaudhary,
00:36:39
Yes, I'm the architecture of Salesforce Practice where I'm leading team of architect. Yes.
Andrew Davis
00:36:47
Okay. And tell me a bit more about Infoservices.
Amit Chaudhary,
00:36:50
Yeah, definitely.
So Infoservice is more and all Salesforce implementation partner where we are working on multiple client and taking care of the end to end software implementation. So we are working on a different stream, Salesforce, aws, Databricks. So yeah, that's all about us.
Andrew Davis
00:37:11
Okay. Fantastic. Right? So we've really grateful for the overview that architecture is.
I think the key point that I'm taking away is that architecture is all about mindset, that sort of broader scope of concern and that you need to learn these four domains of communication as well. From a technical point of view, the certifications. Architecture certifications are a powerful way to make sure your learning is very broad.
We talked about, I'm just checking my notes here.
Talked about the importance of these discovery sessions where the architect really understands at a high level what is the goal the customer is trying to accomplish and to show empathy.
They're not rushing into building solutions, relying on governance bodies, building structures like architecture review boards to benefit from everybody's collective knowledge and then not using Salesforce for everything, not using, not using it where it's not necessarily the best solution, but having that breadth of understanding. So Amit, thank you so much for joining us today.
Amit Chaudhary,
00:38:22
Thank you so much, Andrew, for having me.
Andrew Davis
00:38:24
A great pleasure, Amit. Be sure to subscribe wherever you stream podcasts so you don't miss out on illuminating conversations with industry leaders like Amit.
You can also Visit us@autorabbit.com for show notes, helpful links, and access to every episode as they're released. So stay safe out there and we'll see you next time.
