Posts Tagged ‘large-scale systems’

4 Ways to Empower a Customer

Wednesday, September 14th, 2011

Out-of-the-box software systems from big-name software vendors are always a big contender for CIOs and other business decision-makers when selecting the best systems to power their business. As a customer, choosing what systems to best manage your business can come with unexpected repercussions. Software vendors often develop their products to “capture” their customers, tying them to the system by isolating and creating dependencies on their product and services. These tactics can result in limitations that confine and even cripple the growth of their business.

A great software product shouldn’t have to encapsulate and limit their users just to keep them “hooked in”; the product itself should be useful and attractive enough for users to want to continue using the program. So what kinds of “capturing” tactics should you look out for, and what can you do to have greater control over the software solutions you choose to power your business?

1. Request to know what kinds of integration and compatibility options the system provides. – Software vendors often take an all-or-nothing approach that often limits integration with other software products and services. This lack of integration results in manual conversion of data between software that hinders the efficiency and capacity of your business.  The purchaser should be able to use non-competitive 3rd parties where applicable. If the system does not allow for integration and compatibility for the products you’re already using or hoping to use to power your business, evaluating whether that trade-off is worth it is a must.

2. Request for training, documentation, and configuration. - Oftentimes, software vendors will either develop a “black box” application without access to the code of the program, or give you a product so complicated that it requires a vendor expert. Without access to the inner workings of the software product, the customer is completely dependent on the vendor for how the system operates (and in turn, how your business is run).  By requesting training, configuration tutorials and system documentation, you can ensure you’re getting the most control over the product as you can.

3.  Request to know how the products work together and to access training materials on configuring them yourself. – Compatible software products from the same vendor provide additional software functionality to your system, but they can also leave the customer clueless as to how to use the products together if there is no knowledge or training transitioned between them. If you choose to use the original vendor across multiple products (which you may be forced to), it’s important to understand how you can use these compatibility options to get the most out of your business processing system.

4. Maintain as much direct contact with the vendor as possible, and make use of any feedback service the vendor offers. Large, out-of-the-box software products from major software vendors rarely provide all of the functionality that you need to run your business exactly the way you want (despite the large price tag you dished out for a name brand product). Often times, the packaged system will come with plenty of bells and whistles, but falls short when it comes down to the real tools you need to build your business. Yet these large software vendors rarely allow the customers to direct the development of the products they buy, limiting the opportunities for feedback, compromise, and criticism of what they use (and put up with).  There are no guarantees that large-scale vendors will pay any heed to feedback, but it is the customer’s right to have an active voice wherever possible.

20 Questions to Understand What Your Vendor Means by “Re-Architect”

Friday, July 29th, 2011

I think the term “re-architect” needs to be stricken from our vocabulary.

Whether you’re building a home or a system, the architecture is the first thing you decide upon.  It’s fundamental.  Just as the architecture for a home lays out the blue print for the physical structure, the architecture of a system lays out the blue print from which components and functionality are developed. Before the first batch of concrete is poured or the first line of code is written, you put that blue print in place, and from it every piece of the home or system is defined and developed.

With large-scale systems like policy administration, every line of code is written with that architecture in mind and it is core to everything in the system.  The architecture defines the very essence of the system – it is beyond “foundational”.  Once you go down an architectural path, you might be able to make changes to it, but there’s no re-doing the architecture unless you throw everything out and start from scratch.

So when vendors throw around the term “re-architect”, I think it can be very misleading.  “Re-architect” seems to imply that they have applied some fundamental, structural changes to the software without compromising the system itself; yet, to truly “re-architect” anything would mean a complete overhaul of the architecture that defines it. So, it’s kind of a misnomer.  If they had actually rewritten the system, they would say “we did a complete 100% rewrite from the ground up”.  If they didn’t rewrite it, then there is NO WAY the system is not compromised by the legacy architecture it had.  When you’re purchasing a system – large or small –, there’s a fair amount of legacy architecture and legacy code that comes with the package in almost every case.  You may be OK with that, but you need to have a good appreciation for the extent of it.

Along the lines of finding the “freshness date” or newness of the architecture of the system – as well as just doing some good due diligence – here are 20 key questions I think you need to be asking your vendor as part of the assessment:

  1. When was the last time you “re-architected”?  What parts were not rewritten and why?
  2. Why was the “re-architecting” deemed necessary? And what was the overall impact to the system in terms of % of code rewritten?
  3. What year was the oldest code in your system written?  (I suggest you have the vendor make that a contractual representation and you should get an honest answer.)
  4. For your policy administration system, do you have a monolithic or component based object structure within your code?  If component, do your components reference each other within the code?  Are there database joins that go across your components?
  5. Can you tell me how many lines of code your software is (by language)?  (The purpose here is to gain an understanding of the ratio of newer code to legacy or older code.)
  6. How many customers have converted or committed to converting to this new architecture? For those who have converted, what was the average project duration?
  7. How many lines of code did you write for each of your last three new client implementations?  How long did those implementations take?  (Make sure you can reconcile the lines of code to the duration and that it passes the “smell” test – in other words “if there’s that little code, why did it take so long?”)
  8. Assuming coding changes are required (and they will be), what restrictions are there on using external consultants?   Here the vendor will likely represent that you don’t need to make changes to the core system – do not under any circumstances accept that answer.
  9. How many developers do you have supporting clients offshore and onshore on this platform today?  (Given the low amount of programming you will be told is required, make sure you can reconcile this answer to the answer in #7.)
  10. Am I forced to use your proprietary rules engine?  How easy is it to swap out?
  11. What contractual guarantees are you willing to make about maintaining this platform in the future and future releases?
  12. What is the biggest implementation (# of policies) that anyone who is running on one of your past two releases of the platform we are buying?  (Work to make sure that the answer IS for the platform you are buying.)
  13. List your current clients for the platform I am buying and version of the platform they are running.   (Accept that some clients can’t be named, but insist on a complete list.)  Exactly what functionality are they using and what is the product mix?
  14. Can I have the attendee list from your last user group meeting?  This IS NOT highly confidential and they should be able to give it to you.
  15. Who was the last policy admin customer to go into production for individual life?  Individual annuity?  What were the released version those companies used?
  16. How long did it take your last policy admin customer to go into production (from initial requirements through production)?
  17. Over the past five years, how many companies who have selected your platform where you started projects and the customer never ended up going into production?  (This is information you can learn for yourself in the industry.)
  18. How many policy administration customers do you have that haven’t made a significant number of code changes for customization?  Please name them.
  19. How many policy administration customers have done production upgrades to a newer version over the past five years?
  20. How many customers have terminated maintenance agreement in the past three years?


John Gorman