In previous posts I have written about the complexity of MRO software and why it isn’t simpler. This is the first part of a series of suggestions about what can be done to start making software for the aerospace MRO industry simpler and more user-centric.

Part 1: Be More Open

One of the problems with MRO software is that the vendors can be so protective of their own intellectual property rights and their own little corner of their customer’s business that they do not allow outsiders to have access to their code or to their data structures.  This means that inter-connecting systems to other business applications becomes very problematic.  The cost of building additional business functions into the application environment becomes cost prohibitive as you have to re-engage with the original vendor using their expertise or you have to wait for them to build bespoke proprietary services for you to utilise.

We have found through experience that most MRO software does not have readily available Application Programming Interfaces (APIs), Software Development Kits (SDKs) or a true Service Oriented Architecture (SOA) to allow this to easily happen.  Even if they do have a readily available method for inter connection it is often like getting blood out of the proverbial stone to obtain the necessary information without first being a “technology partner” or without demonstrating you have a queue of customers ready to pay for your idea.

I don’t know of any other sector of the IT industry that behaves in such a restrictive manner.  Admittedly Apple and Microsoft amongst others have been accused in the past of being restrictive in the way they have presented their code to external developers and have stifled innovation through the application of legal proceedings for patent infringements, but at least they do provide access to the various resources third party developers would need for nearly all of their product range.  In most other industry sectors independent developers can produce applications in their back bedrooms that add value to software by expanding capability into niche areas. And this does actually happen.

If I am producing a web application, but have no expertise in hand held devices such as the iPhone, Android or BlackBerry I would thoroughly encourage third party developers to produce external software to make it run on those platforms.  I’d give them access to my technical infrastructure and help them do it to the best of my abilities as it adds value to my product, and enhances my return on investment for relatively little effort on my part.

One company that does this fantastically well is 37Signals.  These guys produce enterprise level applications for many areas of business from cloud based CRM to collaborative project management software.  They are fabulously open with their APIs meaning that there are a whole raft of plug-in tools and system connectors which have expanded their software functional capability into areas that the original designers could never have imagined.

Likewise in MRO software, if a customer wants to do something with the software that is peripheral to the core application product (like create a custom user interface, build an iPhone app or inter-connect it with an external system) this should be both straight forward and within easy grasp of any interested and capable third party.  I’m not saying use Open Source, but provide open access to your architecture.  Maybe this is coining a phrase, but I refer to this concept as “Visible Source”.

This is the first step towards truly simple, user-centric software.

Related Posts:
Why MRO Software isn't Simpler
Why isn’t MRO Software Simpler?
This is what we believe: Web Apps