I was working with a customer on a project earlier this month and heard an interesting perspective surrounding technology decisions from an enterprise architect. He was making a point about the pitfalls of talking too much about technologies within a solution when presenting the benefits of the solution to the customer (line-of-business.) As the guardian of standards and technologies within the enterprise, this is not the perspective you would expect of an enterprise architect. His comments came while we were working on a CRM project that involved linking several legacy applications into the pilot CRM system and Salesforce.com, using a formal Service Oriented Architecture (SOA) approach.
After we helped the customer create 30 plus service-wrappers for several of their legacy applications, we used our Verastream orchestration tools to create governing business processes—these processes supported the needed workflow for the Salesforce.com application. When finished, the business-unit project manager was very excited with the outcome and talked about getting the production system funding. He really focused his enthusiasm on the great use of web services and web service standards like Business Process Execution Language (BPEL) in the solution. These standards are the underlying technologies that our Verastream tools implement when building the business processes that support the workflow. How to modernize Legacy Applications?
Upon hearing the direction of the conversation, the enterprise architect offered us his perspective. He cautioned all involved not to focus on BPEL and other web service standards when talking with the customer, but rather on how the needs for the solution were met—how the correct workflow was easily built to fully provide the Salesforce.com user all the information they needed. As this was a caution about keeping the topic to the needs of the customer, this perspective might seem intuitive, but he had another reason.
The architect pointed out that the more we touted the technologies and standards implemented, the more likely we were to require more decision makers to chime in and effectively stall a project. The architect reminded us that there are groups within the enterprise that take a big interest in the technologies and standards used across the enterprise. By focusing our conversations around the technologies used, we were inviting other stakeholders to review and approve the project, when in fact this wasn’t needed.
His point, if you talk technology, not only will you confuse the customer, you may stall your project. He saw no need for this. Our solution met the project needs– the customer objectives were met, and the solution had a realistic and viable ROI. His recommendation was to keep the conversation to the needs of the project and only highlight technology when directly asked.
This is a good reminder for those of us who like technology. We sometimes talk about it too much. Technology decisions are important, and leveraging the right standards in a solution has great value to the solution. But with any good implementation, it is transparent to the solution and its users. A good reminder from a person that ultimately guards the use of technology within the enterprise–the enterprise architect. Use the right standards and implement good technologies, but talk about good solutions.