AEC Application Integration: Part 5/6, Other Industries

Continuing from post 4/6, I’m going to run down a list of key characteristics you should look for in your integration middleware/overall solution. I’m using Microsoft’s BizTalk as an example to tie the concepts into reality. Many of these apply to IT in general.

Maturity; It’s been around many years and is tested with many products. If a product is not mature, it may work well, but it’s extremely difficult to put a new product into the wild and have all the business and technical lessons learned built in.

Community; It has a good consultant community running businesses based on related services and Microsoft makes it easy for partners to get involved. If the vendor is the only one aloud to service it, and there is not a really great reason why, chances are it’s simply not ready for show time and you will be getting yourself into a long, costly relationship.

Security; It complies with standard 128bit SSL encryption and can run over HTTPS. Clearly any product should conform to security standards and fit into your standards, whether it is hosted internally or externally.

Versions; It ships as a generally available, supported & documented versions release, meaning it’s not “custom software”. Any software that does not ship as a managed release is a red flag. There is a common mistake made when buying into vendor speak that you get more faster by having customer specific installations releases. The bottom line is vendors should have a thorough development process that results in a managed product, not a project.

Connectors; It has lots of connectors included. For example various SAP & Oracle connectors are available as well as a growing list of third party connectors. An Internal dev team or consultants could also write connectors without requiring Microsoft to do it. This will be more likely for apps in the the AEC space as many AEC vertical apps are not popular enough to have standard connectors. Post 6/6 will cover this.

Compatibility; It plays nice in the Microsoft technology stack. Make sure whatever you buy fits in your existing and future plans, and the vendor has a plan.

Cloud Ready; Based on the cloud definition found here & on our company site, it’s intended to be configurable within reason by a LOB user, is programmable & scalable (in line with the rest of Microsoft products). Broad access really doesn’t come into play in the sense of PC’s, tablets, etc…as its a back end app that will serve up data to other apps, however, you need to blend this with the programmable characteristic to ensure it plays nice with all the other apps that have broad access. Multi tenancy may or may not be possible depending on your use case. If you are looking at a SaaS offering, that’s fine, but be extremely careful about the ability to move the product, separating software from service as needed. (Details on this are coming in a future post).

Licensing; It can be paid for as a perpetual license or SaaS license via a certified partner. Not many vendors push the envelope like Microsoft does in this arena. This is primarily because Microsoft ships software, and leaves the rest up to Customers and Partners. This may not be important to you now, but if you have a strategy that may include putting your software off/on premise one day, for example to offload IT management, accommodate external users, or align technologies as they change, you may want to understand/negotiate your options ahead of time. I’ve found many small vendors will negotiate if someone leads the way in establishing the model.