Tryst with a Solution Architect – 3 : It ain’t broke, why fix?
Okay, fine – let me admit this. It is fun talking to experts. We never do that, because we are sucked in transactions. But philosophy, that singular layer drives thoughts and therefore creativity. I am talking about Solution Architecture here. We caught up over an overlapping leisure period. ‘Simplicity is a much-missed factor in solution architecture these days’, he said. ‘People over-architect solutions based of a technology hangover, generally missing the point that user would want simple and ‘good enough’ architecture. I asked him if he felt that CTOs are influenced by budget constraints, and therefore cut corners or made compromises. Because of integration, more layers means more integration and development costs. This drives up the cost. Why should a customer pay more for complicated stuff? Kumar says that customer actually go for new technologies presuming that they will give better performance gains. Sometimes an older technology say VB can be written so well that ASP.NET won’t give that performance. Yes, but it depends on topography as well. If the customer is already having a web application, and performance is an issue, we can tune the existing code rather than ‘migrate’. ‘Lack of support for a technology, like VB may influence the need for migration. I asked him how much do the current technologies affect technology choice. While he agreed on the above points, Kumar pointed out that a technology choice is better to improve status quo than changing to a new technology. He quoted an instance where the technical architect did not feel the need for ‘fix, as it was not broken’ while the senior management felt that ASP.NET was faster. The money that was spent was wasted at that point, according to him. Secondly, for a new product, the choices can be wide open. And what he means in the above cases are typically migration cases. A technology being faster does not itself guarantee better performance, he said. It is the way the code is written. So the first choice is to ‘re-engineer’ the code, optimize queries, design and develop light-weight pages, as it still keeps the same software, cost lower, and has user continuity. What would be the tipping point for technology migration? Scalability, business process changes or additions, functional necessities demand the need for a newer framework. Kumar said that in that case, when the development effort is high then, may be, a technology change is warranted. If parts of the code or modules are reusable, then let them be, he said. There are interfaces and bridges that can be built using web services etc., which can cut down development costs grounds up by leveraging the already-running-well systems. Enterprises dont retire their core applications so easily. He gave an example of Multinational banks that use mainframe applications that are running like batch processes and bulk loads. They use web services etc., to connect. They can run more efficient queries using modern querying methods like JQuery or Ajax. That way, they can get the best of both worlds, he said. For existing applications in small enterprises, Mom-and-Pop stores, as he calls, he said that the core, such as the existing database – carrying inventories or item master can be kept in tact. If the new application is B2B, one can build a web service and if it B2C one can build a portal that queries this database. Thus, by changing only web layer, significant costs can be saved. Just as one hears a technology and its benefits need not be the trigger for a technology migration he says. The cost savings of addressing a portion as against a complete migration is a matter of reckoning. He says that all these are factors, but a careful study needs to be taken before deciding the way forward. As the coffee cups became empty, we returned to work. I was thinking of asking you – What do you think of ‘if ain’t broke, don’t fix’ philosophy of solution architecture.