Let me try to put this together with a small example from the top of my head.
One of our customers had a BPM tool and they were integrating their product with multiple third-party CRM, ALM and SCM tools to push the product in the market. We signed the contract with the customer to integrate their product with a CRM tool. Before the project came to us, the customer’s product had already been integrated with a leading SCM tool and we had to start from that source base.
The customer had no requirements for creating a reusable design with respect to supporting multiple integrations. Somehow, the customer had carried an opinion that writing mostly independent code for different integrations will keep them in a better place to manage the code better in that he would have the flexibility to change one integration without worrying about the other integrations. So, we too didn’t carry this discussion forward as it was not the right time considering the facts – 1. Our team too didn’t know what the variables were in the equation. There was no proper working code as a base for the discussion.
Here is how we approached this problem:
- First, we focused on these variables:
How was the existing integration working?
How did we need to integrate the new tool?
- For the new integration work, we implemented the necessary design principles like re-usability, abstraction, error-handling and fail-safe and other things which were not respected very well in the previous integration that was already done. The new integration started working well and another tool was added to the product’s integration chest.
(As a side note – Because of the way the code was organized, a few of these things, with minor efforts from our side, came as a bonus for the existing integration. Not every single task can be billed to the customer if you are really worried about Customer Delight and Customer Retention.)
- Following this, we had a discussion with the customer on the need for reusable and extensible design – now with some working code as a base, and it was the right time for the discussion. Technically also, we had understood what precisely were the design improvements to be made.
- We worked out the details and implemented a reusable architecture for integrating more tools with the customer’s product.
From the technical point of view, this example is about identifying and weighing the design decisions based on what-to-do, when-to-do and why-to-do as we discussed in the post – Business-Driven OR Fact-Driven Design. The rule of ‘Don’t change the working code’ didn’t apply here considering the ‘Return on Investment’ if it is overruled.
From the business point of view, it is about identifying what the customer needs and Delivering Value to the customer. Again, this project is not one of those fortune-turner kinds of projects that we handled, yet it carried some business importance and for a service based vendor, unless there is a very strong reason, every customer is as important as the other customers.
The design improvement added a lot of business value to the customer that they could add more tools to their product’s integration chest much faster. It is about reduced-cost and faster requirement-to-implementation cycles. The business value for us was that the customer started signing more contracts with us. End of the day. the question “What is in it for me?” has to answer for all the stakeholders. 🙂
- Does your team understand the customer’s business enough to identify what the customer needs?
- Do your team’s decisions on the technical aspects, also consider the requirement of delivering business value to the customer?
This blog first appeared in “Beyond your Code” on 7 Sept, 2012.
[mk_contact_info title=”Contact Us” phone=”+91-7290 970 980″ email=”firstname.lastname@example.org” company=”3E Software Solutions” skype=”Software3E” website=”www.3esofttech.com”]