Transitioning from being a bespoke development to a COTS development house

Question

Currently one of the major applications that our organisation produces would be regarded as bespoke software as it is specifically designed for one specific client organisation.

However, we have specifically retained the intellectual capital on the project and a number of different organisations in different countries (with different languages and character sets) now look like they want to purchase our software solution. Our current approach to development passes 9 ½ out of the Joel Test and is improving. However, our approach is all about satisfying the requirements of one specific client and responding quickly to their needs (regardless of whether something is a bug or a change request).

If we want to transition to producing more of an 'Off the Shelf' approach with multiple client organisations---rather than just one client organisation---on a common code base, what are the major differences and what pitfalls do we need to be aware of to successfully make the transition?

Answer 1

Some signficant organizational and architectural changes should be enacted to be successful at developing a common product that meets all of your clients specific needs.

Organizationally you will need to change from directly delivering requests of clients to a situation where the development team delivers requests to a product owner within the company. Once you do this, the development team is not working for the clients of the company anymore, the only client that should matter to the development team is the product owner in YOUR company.

The product owner will have to gather requirements from the mutliple clients and determine a common set of requirements that will make the majority of them happy. The development team only needs to worry about making the product owner happy.

Architecturally it helps when designing a product that has a wide array of customer needs to make it as configurable, extensible, decoupled, scalable and componentized as logically possible.

Some good approaches to doing this would be to take the many different pools of requirements and find out what pieces are common amongst all of them. These common requirements will constitute the core of your featureset. Everything that is slightly different than the core can be determined as a configurable feature, setting, or perhaps a whole unique feature that is seperate from the core. Make these seperate features as componentized as possible and spec it out well.

Your customers may look at different features that are currently disabled for their installation of a product and may realize that they might actually want that feature too.

Finally, try to be a "Defensive Designer" without violating the YAGNI principle. This can be a fine line to traverse, but it is a very real possibility that certain architectural and design assumptions can cause you to develop yourself into a corner, causing the need for major refactoring in a future release. Assumptions are CRITICALLY important and should be closely detailed and scrutinized in your technical specifications. An incorrect assumption can cost you dearly later. A good way would be, "I know that the customers are pretty certain that they would like this component to work this specific way, but just in case, I am leaving the option open that this COULD change in the future without causing the need for a major revamp." Sometimes this is as simple as proper componentization and decoupling, other times it borders on possibly developing features that were not requested. You have to make that judgement call for your situation.

Answer 2

Since you'll have multiple clients, your build/test/deploy process will need to be more robust. If you already have strong engineering practices, then this should be doable, though it still will be a transition. But that's the easy part...

With only one client now, the customer-facing part of your business is straightforward. However with many clients, you'll need to be able to handle all of them independently. You'll need a help desk, possibly a public issue tracker, etc. (There is a reason big companies have "support" engineers on staff; this is a full-time job.)

On the business side, you'll need to ramp-up your sales and marketing. You'll need to cultivate new sales leads and track the satisfaction of existing customers. So if you want to grow big enough, this may mean using CRM or other automated solutions. You'll also have to "get the word out" about your product, which can happen through PR, advertising, tech conferences, etc.

So your process for building the product will need to become more "professional", yes. But it's selling the product that will be the hard part. Good luck!

Answer 3

One of the biggest issues you have to deal with is customization. Since you may no longer be responding to individual requests but rather making changes to a product that serves many, you need to decide how to handle the need for some of your clients (especially your intial client who is used to requesting custom solutions) for custom information.

You will also need to learn to filter requests for changes based on what the product needs vice what one company needs.

There are several routes to take in regard to customization and you need to decide which one:

• Allow no customization - will lose some customers maybe even your bread and butter first customer
• Create an EAV table in the relational database to allow for lots of customization -flexible but slow and hard to query
• Create a few undefined columns in key tables to allow for limited customization - can work if you have already designed the 95% that is really needed
• Use a no sql database for customized information - fine for things that don't need transactional integrity
• Create separate instances per customer and charge an arm and a leg for customization (especially for custom reporting) - can be very expensive and hard to manage
• Treat all customization requests as something that all customers will get or be offered as an add on (modularly develop the customization so people can pick and choose what features they want) - may be able to handle most development this way depending on how your current software is structured and what it does.

You need to really think through these issues as customization done wrong can make your software unbelievably slow or can result in the need to for many more programmers than no customization. You may also consider using several of these techniques. All have pluses and minuses.