Technology decisions should not be made in isolation, particularly when you are trying to weigh up building a solution or buying a third party platform. There are a number of questions that you should be asking in order to gain a better understanding of the commercial and organisational context.

In particular, it’s important to fully understand how the technology relates to the business. Does it relate to a core activity, or is it just a supporting system? Would any intellectual property be developed by building this that would help to differentiate you from competitors?

Assessing the strategic significance

The closer an activity gets to the heart of the business, the more specialised the requirements tend to become. Generally speaking, applications that are not mission-critical tend are more likely to be addressed by a procuring a generic solution. Those applications that are aligned to the core activities of a business are more likely to be suitable candidates for an internal build.

Core activities are those that directly contribute to differentiating our products and services. They may even be responsible for generating revenue through direct sales. Examples include product functionality such as validating address data, de-duplicating sets of records or cleaning individual records.

Less critical activities are less likely to provide such differentiation or value so provide a much weaker business case for development. Examples would include more non-specific, operational features such as message queuing and content management.

Keep an open mind

In general, development effort should focus either on delivering new intellectual property or integrating generic technologies together. That said, it is important to avoid dogma and ensure that every decision is based on an objective review of the current circumstances.

A team that builds too much functionality in-house will become inefficient and almost certainly struggle with a set of inflexible and incomplete implementations. A team that never builds anything can find themselves having to shore up a disparate set of loosely integrated technologies that do not add up to a coherent solution. Each selection decision should be considered on its own merits.

Are there any existing systems that do something similar?

In making a decision you will be expected to demonstrate an awareness of any third party solutions that address your requirements in some way.

A general rule of thumb is that the more generic your business challenge is, the more likely you are to meet your requirements through a third-party solution. If your research of the market reveals a number of well-established vendors then it would imply that there is little to gain through building your own custom solution. In some cases a generic activity might often involve functionality that has become so commoditised that the market is dominated by well-established open source solutions.

However, when you are concentrating on the fine detail of a problem it can be very difficult to take a step back and see it as a “generic” challenge. After all, all business problems generally appear unique to the people who are directly trying to solve them.

Solution vendors normally have to address the requirements of a very wide audience so are unlikely to be a direct match for your particular requirements. It is important to expect a degree of compromise and keep an open mind. A formal assessment process can help to provide a more objective view of these compromises and identify any trade-offs involved with third-party solutions.

Examining existing solutions for re-use

You are not under any obligation to use something just because it happens to be there, but you are under an obligation to at least consider it in the interests of minimising unnecessary duplication.

Any consideration of internal solutions should also include the wider Experian context. After all, in a company of fifteen thousand people there is a fair chance that somebody has encountered the same problem before. If you do not find a solution you may at least find somebody who has some experience of addressing the same issue.

Note that internally developed solutions are not necessarily superior by definition. It may be that they do not stack up to best of breed solutions produced by specialised vendors. Any internal solutions should be compared with commercially available alternatives to check that the benefits of leveraging an internally-produced solution are not outweighed by any superior functionality available from external vendors.

The importance of history

It’s surprisingly easy for an organisation to repeat mistakes. There may have been previous attempts to introduce a particular technology which will have a bearing on any future initiative.

Any decision should be informed by an explicit appreciation of any previous attempts to solve the problem. You should speak to the people who were involved and read any documentation trail that may have been left behind. A proper understanding of history will help to ensure that there are no unresolved issues waiting to undermine another implementation.

Filed under Architecture and Strategy.