Pages

Wednesday, January 2, 2008

The Closed-Source Software Buy-In

The Case

What makes our stakeholders to take a decision for proprietary software buy-in? Literally, one stakeholder was eager to implement a "brand-new-cool" solution for automating some of the business operations that forced him to hire 3 more employees. So the claim was that if once he have the product installed, and the data integration is done against our core system, then eventually everything will work... That said, we have: the stakeholder X, the software product Y, that should implement function Z. And finally, the software product Y doesn't include its sources in the shipping package.

As you may have already guessed, this software was not working properly after installation and we could not integrate the data model as the software wasn't suitable for some specific business cases.

Let us to take a look to the root of the issue. When the stakeholder was about to take a decision which software to buy, he did not evaluate the software by using the demo version, but instead, some marketing salesmen were visiting the customer and selling the product using PowerPoint slides... (OMG). The stakeholder knew that the product cannot perform some operations, so the required customization was merely ordered.

Next, after the contract was signed, we were testing our data integration procedures with every new version of the product. And, we were receiving the new versions every 4-5 weeks, periodically, with some bugfixes. Nice. After about 2 years (!) of such integration process we've got to know, that by the time of contract signing, there were no customers who succeeded with integrating this product. And, some customization logic were still not working by this time. At the moment the project is almost 3 years old. Lately we received the new version that was claimed to work accordingly to the ordered specification.

The Hi-Tech

The product is actually a J2EE application, running on BEA Weblogic application server, and, even if have no source code available for this application, we can still see that the application is built using EJB 2.1 (despite it is legacy specification already). So the stakeholder made the decision just based on the PowerPoint slides. The software product was not analyzed if it applies up-to-date technologies, or if it is complies to maturity standards.

... blah blah blah... i could continue for nothing :)

The Real Problem

As I see it at the moment, the stakeholder's point of view in this situation is that the integration team is the bottleneck, as we fail to integrate the product.

So my list of questions for this issue is:

  • What makes the stakeholder X believe into some product Y, instead of developing the solution in-house?

  • Why doesn't stakeholder try the product demo before signing a contract?

  • What position should take the integration team in this situation?


From the business process point of view, buying the software product from the 3rd party might be even positive: bringing the know-how in. But! Is your stakeholder so incompetent that it would take n+1 years to complete the project?

No comments:

Disqus for Code Impossible