4 simple points for Tech/CoE leaders,Salesforce or Enterprise Architects,who may also fall into the trap to address hard technical constraints earlier than needed
In 1999, I was asked to set up a customer service number where a caller can enter a ticket # & our solution can query CRM (Siebel), and read them their case status.
It was specially made more difficult because we did not have the hardware (Telephony Switch) or the pricey switch software needed to interface it with Siebel – and the client had to see a demo in less than a week.
Do you also fall into the trap of trying to figure out how to address hard technical constraints that appear insurmountable – earlier than needed?
I made this mistake often because, after my young scrappy days, I somewhere forgot that not everything is a nail that needs the mighty Thor hammer of Technology & Enterprise Architecture – at least not at the start.
With the power of Cloud Computing, did we forgot about thinking & starting small?
If you are a technology leader, CoE member, a Salesforce or an Enterprise Architect, or another role that influences your organization or your client on making Enterprise technology decisions, then this is for you.
But, back to the story…We had to pull this rabbit out of our hat in a very short time and had no access to the basic components.
However, I was able to pull it together, with a dedicated phone line and a modem, a 3rd party device library, and some custom code that served as the integration layer to Siebel that I wrote over the weekend.
It worked pretty well for the demo, giving us the UX and validating the business process, and proving our creativity could address complex problems of 1999.
Of course, my cute little demo (which was pretty cool during that time) would never make it to production or scale for any large enterprise, but it served its purpose, without costly and time-consuming encumbrances.
Initial ideas need a PoC, to nurture what they can be – they don’t need to be the real thing but a taste of the possibilities.
Good PoCs are cheap, fast, and purpose-built to address specific questions & assumptions
The point of a PoC or a prototype is to cut through the fog of confusion and answer the ‘what if’ questions.
As seasoned technologists, we can impose scale as the constraint on our thinking, without realizing that it has slowly become second nature. I have done this a lot in my past and try to keep myself away from doing it again.
Most of the time, thinking about scale, performance, and other considerations works well. After all, that is the job of Enterprise Architects – to design scalable & technically elegant enterprise solutions!
But the greats that I have learned from, always balance business context with technology firepower, and their technology choices embody a purpose-appropriateness.
Even for very large enterprises and complex use cases, not everything needs a hammer. Some initiatives can use a more lightweight approach – even if they don’t scale to incredible numbers.
I was once looking at a proposal generation solution that would do everything that the business wanted, but it won’t scale for millions of proposals.
However, this B2B customer only sent out a few thousand proposals a year in total – and so they did not need a more scalable solution. Just something easy to use and quick.
Purpose appropriateness in Enterprise Architecture boils down to 4 key areas
I now lead a product company, and that brings an entirely different facet of this thinking. We need to account for every possible way our customers use or would want to use our products.
Most product companies have to think more deeply about end-user and dev. experience, followed by scale and robustness.
We do the former with declarative configuration capabilities that are data and metadata-driven by design. In addition, to support easier ability to use our capabilities with Salesforce Flows and Process Builders, we build Salesforce invocable-based functions.
For developers, our products focus on standards-compliant APIs (REST/JSON) and use well-accepted security protocols and authentication mechanisms, and Apex methods that are well designed and documented for ease of integration.
Finally, we use Async (Batch, Schedulable) and Bulk API-based design where applicable, because our customers feature the range from small under 250 user Orgs to Fortune 500 customers.
Summary:
The incredible computing power of the Cloud has made it easier than ever to deploy massively scalable solutions. However, a good architecture mindset is all about knowing where to use a Machete and where to use a Lancet – and bring purpose-appropriateness to our designs.
Saurabh is an Enterprise Architect and seasoned entrepreneur spearheading a Salesforce security and AI startup with inventive contributions recognized by a patent.
A plain English guide to the latest additions in the California Privacy Rights Act (CPRA) and their implications for Salesforce orgs.
Everything you need to know about Salesforce and Postman In this article, you will learn about Postman and how you can use it to search,
Why should you read this? Data Privacy laws such as GDPR and CCPA bring in a new set of requirements around Consent for the
Why should you read this? Because you are curious if Salesforce can be your consent management platform for GDPR and CCPA compliance. And how can
This is the first of a monthly blog series we call “Ask an Architect.” In this series, we will be answering common questions from some
“We have millions of records and constituents with high expectations around service and engagement; how do we develop an effective data management strategy?” In Part
The pandemic has changed the human lifestyle in many ways, workstyle being the one most affected. Offices and cubicles replaced with corners of houses and
