Successful Consultingware

Posted on

From time to time I have a look at the Blogs that some of my colleagues have. Unless I’m looking for a quick solution to a “why the hell does this thing fail?” or “how the hell do I do that?”, I find a lot more interesting reading to people that I know than people that I don’t. I have been on the same boat and I exactly know what they’re talking about.

I’ve just read Scott’s blog about Consultingware (read here). Scott is a colleague that has been recently been working with me. He is a brilliant developer and consultant (and he seems to be a very good tango dancer as well)

In his post he talks about a model of business that has become very common in recent days and that it could be resumed as:

1. Company A develops a solution that it’s intended to reach a large market

2. Company B sees the product and thinks that it’s a good product that fulfills the 80% of their needs and with a little customisation it would be the perfect product for them because:

a. Buying the product will greatly reduce how long it’ll take to have something working

b. There is a company that will be upgrading the product and liable for any errors or legal problems due to wrong calculations

c. It’s outsourced (easily budgeted and a TAX-friendly cost)

d. And the most important of all is that it’ll cost just about the same amount of money

3. Company A can make money from company B by selling the product and customizing it with the 20% of the missing features. Additionally the new features can be used to increase the product value that will be sold to the other companies.

In my career I’ve been working in this type of scenario several times with a different approach each of the times. They all were very large and complex products and all in financial areas (where the money really is).

· The first of them had an international product. I was involved in the development of the version 4 which it was a full rebuild of the product from scratch (something not very common).

Their approach was: They had the product and it was customised with a set of rules or predicates that were introduced in the system as normal data. Then, the engine used these rules to cater for the specific way of working the clients had.

The product came with a standard set of rules that the client could modify, but realistically they wouldn’t be able to do it because of the complexity. However, they could outsource it to external consultancy companies (as KPMG or PWC to say some) that had specialised consultants to do it.

Then, the company that was making the software wasn’t liable for the customisation even though they had ongoing consulting benefits for training and support and they benefited from the clients that were brought from these third party consultancy companies.

Very little changes or enhancements where made to the software due to client requirements and the ones that were accepted had been evaluated as generic and as beneficial for all the clients (I have to recognise that some clients were heard more than others and their changes were always more generic). As there were no real client specific customisations, no per-client maintenance was required.

· The second case was as well an international product that went to its 6th version.

This product was similarly based in a highly configurable platform in where the company included with the product a basic set of product customisations that were good enough for the majority of the clients and the clients only needed to provide the system with the input values specific to them and the system would calculate the output (after sometimes overnight processing).

As the Product could be adapted to the client needs using an included modelling tool, the clients could create their customisations (or pay my company to do it) and save them to be used whenever it was required. The main difference in the approach of this solution was that the features that were demanded by clients were implemented as features in the modelling tool so the customisations were allowed to be done by the client. This linked with the fact that the client had the chance to use plain C++ to create custom functions (all edited, compiled and linked in the modelling tool) and use them in the different areas of the calculations.

To have a better understanding of the whole, think about Excel. In Excel you can use all the features and if you want to do something else you don’t call Microsoft, you create your scripts and add them to your spreadsheet.

This approach allowed the clients to customise the system to their necessities and the vendor could still offer customisation services without modifying the base code. The downfall was that it was very difficult test the models and verify if the problem was in the model or the customisations. However, there was only one solution for all the clients.

· The third case it’s more related to what Scott was talking about (read here).

Scott, in his conclusion he doesn’t give a solution but I’m going to give my opinion in how I would approach the problem.

Have a look at all the Microsoft and Adobe applications. They all provide an API to create extensions or plug-ins and macros. The product remains the same but you are able to do some customisations to adapt it to your needs. I think that this model would solve most of the problems that Scott talks about. I’m not saying that create a system that supports this model it’s an easy task and it may require a fair bit of thinking, but it would dramatically increase the chances of success, specially because the complexity of the management is reduced not having to keep one branch per customer and each of the modules can be independently tested without affecting the rest of the system.

Good luck in Argentina, Scott!

2 thoughts on “Successful Consultingware

    Scott said:
    June 2, 2008 at 16:22

    Hi there Roberto, with all my travels, I have only just seen this now. Good article. I really should get my act together and do a follow up post myself.

    You are definately thinking along the right lines, I think it’s important to give others the power to make customizations through the use of API’s etc…, even if they end up getting you to do those customizations. I’ll try and explain this more in my next post.

    I’m having a great time in Buenos Aires, still very much in holiday mode, y mi espanol no es bien todovia.

    Alan said:
    January 26, 2009 at 13:53

    Just had a read or yours and scotts blog article. Great stuff. Just letting you know I have linked your article on my blog (http://www.consultingware.org). This is such an unexplored area of software engineering. And it is something I think we all experience (at least once, if not way many more times). It is also a very complex subject. I know I have been thinking about it (in the context of a few projects, but thinking about it none the less in detail). It touches GUI, business logic, work flow , just about any business unit (and each one differently) etc. My particular interest is in the client side (but server side is also interesting). What is so amazing is that when we all start our first project, we have a bag of skills but I don’t think we really understand just how many issues these sort of projects will generate, so its always so much harder to plane or architect a solution. And due to such a limited understanding (and often time for experimentation/exploration), many of our initial abstractions leak so much.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s