Buy vs Build – Which one is a proprietary solution for a Single-Dealer Platform?


When Matt Davey blogged about Single Dealer Platform Team Dynamics, it was mainly about methodology, but it brought up a point relevant to this blog post:

The team needs to be “driven” from the perspective of ensuring that the hours within an available work week are spent appropriate in driving business value, and hence achieving the goal of delivering an SDP.

The key here is driving business value. That is exactly what a team delivering a single-dealer platform should be doing, and the best way to do that is to make use of existing software that helps you concentrate on business value rather than infrastructure.

How is business value best added?

In this Internet age the word “proprietary” is seen as a bad thing. People don’t like to feel they are locked in or lacking freedom in any way, and the freedom and transparency associated with building a system from scratch can be attractive – much like choosing to use open software over proprietary products. Open software means it uses open standards, but not necessarily free or open source.

But what happens in the SDP world, when there really isn’t an open source option – no open standards or technologies over and above the core generic infrastructure of programming languages and environments?

The SDP Standards

The kind of standards you might use to build an SDP are at a different level. For example you could use JMS for some backend messaging. This would allow you to swap out for another JMS provider – you could use programmers with JMS skills. The problem with this is JMS does not provide you enough and it is too generic. Yes you can make use of it, but you will be writing a lot of your own logic on top of it.

Similarly with streaming servers, which are often used in SDP’s with RIA front ends, there are no standards. Where there is some commonality it is a low common denominator, which again leads to a lot of development work to implement the business functionality you require. The less custom code the better – you will take longer to get into production and it will bite you later.

The Ultimate Proprietary Software

The debate becomes one of “buy versus build” –  between buying the software and spending a couple of months implementing your application, or building it yourself from the ground up.

While in other categories of software it may seem correct to associate the “buy” argument with being proprietary, when it comes to SDP’s it’s simply not the case. Quite often the reverse is true – by building a core infrastructure from scratch you are effectively creating the ultimate proprietary software.

When you build your single-dealer platform in-house, you will be supporting it yourself and will require a skilled team who are constantly available and who have the intimate knowledge of the internals of the product. As is often the case, the team may get dismantled after the platform is complete or the key developers leave the company – so you’re no longer free to change things because the people who know how it worked are now gone, and you have a “legacy” system which no one wants to touch. Once again, this is the ultimate proprietary software – it’s entirely proprietary to you and has a dwindling list of benefits.

A Re-Usable Core Infrastructure

And while it is easy to compare products on initial price, (and in this instance building a system in-house may initially appear cheaper) you must also include the costs of implementation, support and other costs such as changes to support new lines of business in the future. It is essential that a single-dealer platform have a re-usable core infrastructure so that you can easily extend it to incorporate new asset classes or additional portals for different user populations. Most single-dealer platforms built from scratch are hard-coded and not easily extendable – this means they do not continue delivering business value as your business changes.

Conclusion

Business value is key – don’t waste time solving all the problems that someone else has already solved.  If you are able to purchase the tools to quickly create your core infrastructure and implement your business logic, then you can focus on any required customisation and business value that can be added on top as part of the final implementation.

3 Responses

  1. […] “don’t waste time solving all the problems that someone else has already solved” – I agree, but also disagree. Technology moves onward at neck breaking speed. What was cool and fast two years ago, is often found to be old and slow today. Whatever product(s) you buy need to be appropriately integrated into an application (SDP or whatever) so that if required that product can be replaced with minimum fuss if it’s deemed that product is not providing (business) value for money. […]

  2. […] Here we are talking about the inherent tensions that exist in many firms, between the business who require functionality, and speedy time to market, against possible internal technology team interests to ‘build it here’. (background on this question is covered here) […]

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

%d bloggers like this: