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.
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.
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.
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.
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.
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.