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
- Business context - Will the company be able to consume the solution in terms of its sophistication, timeline, cost, complexity, and maintenance? When will they get the value from this deployment?
- Strategic perspective - How does this align with their 2-5 year strategic roadmap? Is this foundational to their digital transformation or is this ancillary to their core direction? This can help determine how durable and technically elegant it needs to be?
- Requirement/project context - What are the expectations of the project sponsors? Are they looking for a quick sandwich for lunch or a 6-course meal? And what kind of ROI will this yield?
- Enterprise technology & Roadmap - How capable is the IT when it comes to seeing how it fits in their landscape? The 'Holy wars' of technology zealots have killed so many logical ideas for politics and lack of understanding.
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.
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.