Integration
Dare Obasanjo posted on integration, in reference to ‘Integrated Innovation‘, and used Microsoft Office is an example of a huge integrated piece of software.
But Microsoft Office is not monolithic. It’s not one big piece of software, it’s a number of smaller pieces of software, that communicate through an established, standardized protocol – OLE.
“The fact that one can design a chart in Excel then cut and paste it into Word with no problems was a big deal when it was first implemented and it still is today”
This is done by having Excel support OLE, and Word support OLE. These two applications don’t have to know anything about each other, they just have to support OLE.
This is the difference between other monolithic applications, and Microsoft Office. It also means that when Microsoft comes buys Visio, they don’t need to update Word to support inserting Visio documents. Both applications support OLE.
The lesson here is that if you want to integrate some of your own applications, create the protocol first.
Unfortunately where Microsoft has a big advantage is that they’re usually integrating with applications they’ve written themselves, and they set the standards. If you take two third-party applications from two different companies and try to integrate them, well, good luck.
For document creation applications fortunately OLE is robust enough, and generally pervasive, so that integration between, say, Microsoft Word and Corel Draw wouldn’t be too much of a stretch. That’s a huge testament to the success of OLE. But in any other application segment where there is no such pre-existing standard, what can you do?
Look for places where you can modularize your application – functionality that could reasonably be used elsewhere. Make up your own standards to expose them where none exist, document them, and stick to them in your own applications. Chances are if you need to integrate with another application where there is some overlap in functionality, there will be an overlap in the API. Gluing together the exposed edges of two applications is a lot easier than gluing together the guts of two applications.
I guess that’s the strategy tax.
It’s more like a strategic investment, I think, than a tax – developing software this way will take marginally longer, but if a requirement does come up that requires this modularity, your investment has just paid off bigtime.
Any reasonably successful piece of software will get bought and integrated with something. That’s the way the market is. Design for it.