Monthly Archives: March 2012

Changing the Not Invented Here Culture

It doesn’t matter how you count it, the truth is there are a lot of software developers in the world. What gets me is the gigantic waste of brainpower that this represents. Many of these developers seem destined to waste their lives solving the same problem over and over again. Even the smart ones do it, except they can console themselves with the fact that they are improving their technique every time.

I’m not arguing that should be only one accounting package, or only one e-Commerce platform, ERP or CRM. Instead I think that we need to get better at recognising that a solution exists and get over ourselves and acknowledge when that solution is “good enough”.

When developers are born they are injected with a healthy dose of the “not invented here syndrome” (NIHS) virus. The truth is that we need this virus to drive us to look underneath things to see how they work, and to emulate what we see to build our skills – but everything has a natural limit to its usefulness (with the notable exception of duct-tape).

NIHS when let go unchecked will result in people always selecting “build” over “buy” in a technology project. I’ve blogged about one of its variants NIHSFUD before and the kinds of things it can lead to.

That isn’t to say there is never a time when you should build a solution from scratch, but as an industry we need to get better at the build vs. buy argument and making some rational decisions.

The Argument for Building a Solution

Despite there being a common set of business problems, the specifics of what makes a viable solution vary greatly from organisation to organisation. The reason for this is built into the DNA of any business, the entrepreneurial drive to do things better than what has come before. This requires adaptability and its this adaptability to specific circumstances can lead to radically different business processes.

When a successful business has evolved a unique set of business processes you need to pause before suggesting an off-the-shelf solution. Typically the off-the-shelf solution will implement a set of “standard” practices which may not align to the more evolved processes of the host business. Therefore a costly customisation exercise may be required.

Often this customisation can be more difficult and costly that development of a solution from the ground up which perfectly matches the requirements of the organisation. In those cases it may be better to just roll your own.

Finally, the ultimate argument for build over buy is that a solution simply may not exist. Sometimes businesses do things that are so specific that there isn’t an off-the-shelf solution that comes anywhere near meeting their requirement.

The Argument for Buying a Solution

The solution buying argument acknowledges all of the legitimate reasons for building a solution. After all, before a solution can be bought, someone had to have approved the time and cost of building a solution from scratch.

Those who advocate buying over building suggest that despite the differences between specific businesses processes, 80% of the requirements in a particular solution space are the same, a further 10% can be addressed through customisation and that the remaining 10% can be divided between the true need for bespoke development (say 5%) and stuff that a business does differently which it shouldn’t (the remaining 5%).

One of the common criticisms against buying is that the customisation ends up being just as expensive as building the solution, not to mention the usual licensing costs. You can see the proof of this argument in multiple costly ERP and CRM solutions.

Unfortunately the build argument neglects to acknowledge that the great deal of those customisations probably should never have been implemented. When an organisation buys a solution they need to look at their requirements in terms of the business processes that they need to support, and the data points that they need to manage. They can then look at a range of suitable products.

There are three things that are certain in this world, death, taxes, and a requirement to feature mismatch with off-the-shelf software. All off-the-shelf software finds its roots in solving a specific problem for a specific customer, or group of customers. If you fall outside that target market there is going to be a larger delta between what you want, and what your software provides.

At that point it would be easy to pick the build option. However a pragmatic business decision maker might consider whether the off-the-shelf solution actually represents a better business process, proven out through multiple implementations. The buy option can represent a significant risk reduction **if done properly**.

Finally a great deal of business problems are just out right identical. Whilst there are a multitude of accounting packages, they are all trying to adhere to a common set of principles under which businesses capture and report financial transactions. Very few organisations would attempt to build their own accounting package. They would either purchase a generic solution that works across multiple sectors. Alternatively, they would purchase an industry specific solution which provides the same core financial functionality but has additional features specific to their business.

Once we get beyond core financial systems though all bets are off. I see a lot of organisations spending lots of money building systems from the ground up when it would have been more cost-effective to adapt a small percentage of their business processes to fit with the “norm”.

Buying a solution doesn’t mean that there will never be bespoke development. The closer you get from the centre of your business to the customer the more likely that a bespoke solution which integrates with core off-the-shelf solutions is going to do a better job of representing your unique value proposition to your customer.

By all means build your own e-Commerce system from the ground up, but don’t re-invent the accounting, ordering, invoicing and contact management features.

The Obvious Truth and The Ultimate Irony

The truth is that if you are a business person charged with making a decision about whether to buy or build you are going to be approached by parties with an agenda.

Those who have a solution to sell are going to point out the benefits of getting something off-the-shelf. Those with the skills to build are going to suggest that your uniqueness is a virtue and you need something built just for you. Neither choice will negate your need to continue to invest in your systems into the future as the scale and nature of your business evolves.

You need to recognise when your unique business process provides you with a genuine competitive advantage and warrants custom development, or whether it’s a standard business process and the steps you take towards standardisation now will enhance future development and integration projects.

The irony is that many of the proponents of the “build” argument secretly harbour desires to build a solution that others will “buy” in the future. This is perhaps why software developers spend 50% of their career building the same screen connecting to the same database to support the same process. Where is the value in that?

Is “notgartner” good for my personal brand?

Officially at Readify the Marketing Manager role reports to the Chief Technology Officer. It is a curious perversion of an organisational structure that you won’t find in many companies but it kind of makes sense since the CTO role at Readify has a dual focus around delivery of services internally, but also defining the overall technology strategy for the company that we go to the market with.

I’m not a natural marketer, it isn’t something that I studied before coming into the CTO role and for a good part of my career I tolerated interactions with “marketing people” and never would have dreamt that I would have some level of responsibility for the smooth running of a marketing department.

When I first started working with the marketing team I did what any geek would – I started creating systems and inventing processes not spending a lot of time to really understand what the organisation really expects from the department. Whilst I had collaborated with the marketing team in the CTO role I wasn’t initially responsible for the department but the last 12 months has seen me on a real learning curve.

Of course I’ve been doing lots of self study to get a better grip on the problem, actively participated in the process and learnt lots of lessons (made mistakes) and had some wins. More recently Readify has been starting a planning process which defines the vision for the company over the next three years. That is a pretty tough ask given the rate at which technology changes in this business but at that level its more about the structural supports you need to put into the business to support growth and cope with the pain that comes with it.

These recent events have given me cause to go back to some marketing fundamentals and ask some questions about the Readify brand. What is our brand position, what is our brand promise – things of that nature. Whilst I have a relatively good idea of what those things are for Readify (more work to do), it got me thinking about what my own personal brand is.

I’m assuming that my personal brand and its positioning in other peoples mind is a function of the things that I blog about, the topics that I present on in conferences and the direct interactions that I have with individuals. Another part of my personal brand is my brand name “notgartner”, and I am starting to wonder “what’s in a name?”.

Where is all this coming from? Well, I’m starting to wonder whether it is time to leave “notgartner” behind and start to take some specific steps to reposition myself (and name is important in that).

What do you think?