One of the more ambiguous terms doing the rounds of the industry is this little term called ‘Solution Architect’. The term certainly is born from the word ‘Solution’. It’s the ‘Architect-ing’ that spins different interpretations. However, without having to use a microscope, we can still very clearly understand where this very important person of the Presales team fits in.
Whether the Solution Architect is a hard-boiled techie who codes in his sleep and loves tinkering with the latest open-source offering, or a more techno-commercial person who gets his hands dirty with estimates and project planning as well; it is certain that he and sometimes, he alone, is yoked with the onus of thinking in the client’s shoes.
One of the most fundamental processes involved around arriving at the magic solution to address the client’s pain is reading. While Bid Managers and Associates may expedite the overall ‘solution-ing’ process by highlighting the specific areas of technical scope etc. in the Request for Proposal document, it is very important for the Architect himself to read through those sections and not have someone’s version be the first level of input for him. In other words, the client’s words should be the words for him to work with when he is starting out with the solution. Why? Because we perfect beings do choose to leave out details unwittingly, that may be seemingly unimportant to us.
For example, if the Request for Proposal document talks about needing a standard blogging solution with a custom made polling widget, it is possible that while transmitting the important information from a hundred odd pages RFP to our Architect, the word ‘custom’ goes missing. The results trickle down to the scoping, solution, estimates and everything else that goes into the client’s inbox. Reading the complete text of requirements to pick out those little words or phrases like ‘compliance with Annexure 1’, ‘spoofing attack in the past’, ‘staging data not available’, ‘front-end frameworks preferred’ is worth the effort-to build the right context. The building of a context is what throws visuals in the mind, perhaps different architectures keeping in mind the smaller details, foreseeable challenges and intelligent questions or assumptions.
The often talked about winning solution makers or differentiators (keeping compliance and cost competition aside) is insight. The insight offered in the winning solution is more than often, simple, novel but the process to arrive at it takes scrutiny and experience. In other words it takes two things to arrive at the perfect solution based on the context: getting the context and putting the solution together by virtue of experience and knowledge.
Context sometimes becomes paramount trumping a lot of other factors (even the cost, as the experts say) because it strikes the right chords. After all, the best jazz pianist evokes snores only, if the audience had bought tickets for Poets of the fall.
