NIH and SOA - bad combination

I am continually amazed at the amount of time and effort (and money) that companies will put into writing code that is well outside of their core competencies for their business. The usual reasoning that I hear is that the technology they are building is foundational to their core business. In other words, no one does it "exactly" the way that they want, so they have to build it all themselves.

Really?

I very recently met with some representatives from a company that is taking this concept to the extreme, and has even created their own programming language to support the needs of their business. When I pushed them on this, they outlined the need and benefits of doing so with a straight face. I asked them why they invest so much in something that is ancillary to their core business, and the response was "this is our core business", to which I replied "your core business is writing programming languages?".

"Well, no - but our core business relies on it".

I see - what you mean is that your desire to develop a programming language has created a foundational dependency for your core business.

To me, this is akin to saying that because our delivery company relies on cars, we need to build and staff a factory to design and produce those cars.

Now, I am not picking on this one company - the "not invented here" (NIH) syndrome has plagued developers for many years. I used to teach an object oriented programming class at one of our local universities, and I would always start out the semester discussing the evils of what I called "developer reflex #4" - the overpowering desire to re-write any code that a developer reads, which he or she has not written themselves. Everyone seems to think "I could do that better", and it is almost painful to use something that someone else wrote - especially if you can actually read their code constructs and see how they implemented the functionality. The desire to build a better mousetrap is overwhelming for developers - even if they are not in the business of catching mice.

I was a very early adopter of component technology, and was a vocal proponent of such when I was a young developer. Where I was working at the time, we actually had some great success stories of re-usable code and sharing components between applications (I even co-authored an article on the subject). I now firmly believe that one of the keys to our success was that we shared binary components, where other developers had to consider the shared component as a black box - they couldn't see under the covers to know if they could implement it more efficiently or not. And in the end, it didn't matter - the components worked just fine for them.

I view the Service Oriented Architecture (SOA) hype today as simply an extension of this component-design approach. Rather than sharing components to build applications, we are now talking about sharing full applications in order to build systems. But, the danger still exists - developers have a "not invented here" syndrome that causes them to still feel that only they can build the right application to share - and if everyone else would just use their implementation, SOA would finally fulfill its destiny.

New technology, same old biases. And somehow, the technologists convince their business to invest in building these non-core technologies, assuring them that anything less would be a sacrifice that will ultimately take the business down due to its lack of competitiveness.

We need to stop trying to build everything ourselves, and start innovating around our own core business - stop re-inventing the wheel, and put some true SOA principles into action, making use of the best of what is out there, being built by those who specialize in that technology. Invest in the innovations around our core business competencies, and minimize our investment in anciliary technologies.

Then, companies will become more competitive through the use of technology.