Design or Develop

A while ago I was explaining the architecture of a solution I have developed when he made a remark about how my solution was based on the integration of off the shelf Solutions (OTS) rather than a custom development and he added how a custom development would have been more impressive and efficient not to mention superior in every way. Being a solution architect that’s a question I have to answer at the beginning of almost every project I am responsible for and the answer is almost always customize and integrate, in this post I’m going to explain the logic behind such as decision.

  1. Someone has done it better: you might have access to the best developers but unless you are developing something within the core technology of your company you don’t have the accumulated experience someone else has especially if that solution is within their core technology area. When you limit yourself to in house developed solution you also limit yourself to the skills you’ve got within the confines of your company.
  2. Is it really custom development: unless you are writing machine language or using your own compiler you are actually customising the only difference is the building block size. Developers use libraries and packages that someone with more experience has built and most use it as a black box without fully understanding it’s inner workings and they really shouldn’t.
  3. Cost: in theory you can build everything if you have no cost and time constraints however unless it’s a toy or personal project cost and time constraints are of key importance. The more customization requires the more costly in terms of time and money a project becomes. Licenses cost money but almost always they are cheaper than the investment needed to build the same functions in house. There is also a hidden costs associated with the involved risks and the bugs that we’ll be discovered during QA and initial customer experience.
  4. Accumulated experience: vendors building OTS solution amount the combined experience of their customers which means they’ve covered more use cases and edge cases than the your in house development team ever will this experience is merged into the patches and product updates.
  5. Compliance: it’s a lot easier to comply with certification criteria when using larger building blocks (OTS) as the certification bodies are familiar with the OTS solutions and the vendors are usually precertified. Trying to certify an in houe developed solution can be both expensive and time consuming.
  6. Integration best practices: this point is a bit tricky to explain when in house solution is used the developers use integration short cuts to save time that are often far from the industry best practices, using OTS solutions enforces a certain level of best practices conformity this is valuable as a at a later stage components can be swapped out at a minimum impact.
  7. Operability & Extensibility: Even if you have the ultimate bespoke solutions built specifically for you, finding people to operate it or build on top if it in the future might prove to be problematic especially if the original team who built it moved on.

So these are the reasons why you should almost always go for customization of OTS rather than in house solutions and using larger building blocks with micro services, how about the situations where you should in fact build your own solution and going for the smallest building block possible (language default libraries)? Thats my next post.

Advertisements

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