Mcoderkat's Blog

Ask “Why” 5 Times

06 Aug 2010 Leave a Comment

by mcoderkat in developer productivity, integration, Lean Integraton, WebORB

It is exciting to see Enterprises embracing Lean Software Development and Lean Integration practices and principles, especially since I’ve been touting Midnight Coders’ developer productivity tools for several years now.

Lean has its roots in methodologies developed for manufacturing and specifically for the manufacturing of cars.  The Toyota Production System (TPS) is probably the most well known for its synchronized manufacturing and just-in-time techniques.  The most important objective has been to increase production efficiency by consistently and thoroughly eliminating waste.  Lean is not just for manufacturing of cars though.  Lean can be applied to any type of manufacturing and service process.

Taiichi Ohno, Founder of the TPS believed, “By asking why five times and answering each time, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms. In a production operation data is highly regarded, but I consider facts to be even more important.”

For the industry my company serves, one in which development teams around the world are creating dynamically rich online applications in Adobe Flex, Adobe Flash, Microsoft Silverlight, AJAX and HTML5, we can assume our customers’ five questions might go something like this:

1. Why are we losing customers or why is transaction failure rate so high?
2. Why is data loading so slowly?
3. Why is the code base so bloated?
4. Why was the integration manually coded?
5. Why was XML web services chosen for this integration?

Asking these questions reveals the business problem, which is lost customers and that is tied to bottom line profitability.  The root cause was choosing an integration approach that proved inadequate for the company’s needs.  All to often we have customers come to us after they have gone down the path of creating an application that connects multiple tiers (client, business logic and database) using XML web services.  They adopted that approach because they either didn’t understand the performance problems they would face as their user base and data grew or they just weren’t aware of alternative integration strategies.  Sometimes it is a money issue – the business side would not approve the purchase of technology to solve the integration issue, which is tied to bottom line profitability.  Granted, XML web services isn’t a bad choice for every application, we just hear from our customers time and again that it is a bad choice for data intensive applications.

If we look at the five questions in light of LEAN we can see that developers probably spent a lot of time hacking away at writing, documenting, debugging and maintaining the integration layer, which could have been spent more productively on developing business logic.  It would be interesting to see just how long development takes and at what cost to produce an application integrated using web services that in the end would not scale to meet the business needs.

Ultimately, the business loses because customers are unhappy and revenue is lost.  To fix the business problem, the business approves a rewrite of the application and purchase of technology.  It would be so much easier and more profitable if the business approved the purchase of technology in the beginning.  Case in point, Rafael Zbili, Sr. Manager of e-Business Technology at Hilton Grand Vacations stated, “WebORB reduced our data loading times by 83 percent.  This allowed us to process 143 percent more reservations than before using WebORB.”

One Benchmarking Tool that will help companies that are trying to decide what will give them best performance is to run a simple test that compares remoting to web services.  Keep in mind that true performance gains are recognized with larger data sets.