AEC Application Integration: Part 4/6, Options & Gotchas
My longest post by far, but necessary to do a thorough job where you can fill in without much risk. Friendly reminder, this is aimed at arming non-technical people with information to help them make decisions and manage IT, particulary geared toward a Cloud mindset. Lets dig in... In Part 2/6 in this post series I noted several broad Business Use Cases. In Part 3/6 in this series I gave a very specific example of a scenario sending data one way from NoteVault via BizTalk to Prolog in order to show the general step by step technical pieces and flow required in any integration. Now I am going to give a range of options you can discuss when trying to select the best way to do an integration for your budget.
Keep in mind I am focused on a repeatable process you intend to make part of your daily business that people will rely on, not simply a one shot import/export (which I note for the bottom of the barrel reference). In all cases you need a deep understanding of the business case, stakeholders, business process, applications, related API's and in many cases Vendor relationship management. Here is a range of options:
Manual Import/Export:
This is simply exporting a dataset from one datastore and importing it into another. I don't really consider it integration.
Cost; Free, usually a feature in all software.
Integrity Risk; Very high due to human issues, non-repeatable, datastore corruption.
Pros/Cons; basic transfer of datasets from source to destination.
ROI; not very good, not repeatable, requires a high level of skill and QA/QC.
Office Business Applications (OBA):
This enables you to have a similar experience to import/export except that the Excel file is bound to the LOB applications. Example; integration of Excel (RSA) with Prolog (LOB). You may not realize it but all the Pieces from Part 3/6 are generally present.
Cost; Free to $10,000 for most tabular types of updates. You can get many free, as well as paid or custom OBA's from my company @ TheOBAStore.com.
Integrity Risk; Moderate because once it is created you only risk getting the initial dataset from the source application to the OBA.
Pros/Cons; Is identical to working in Excel. Somewhat manual getting source data into it, but when you push the dataset to the destination application validation & error handling will be enforced. Great upgrade to import/export. Requires requirements analysis and programming but once it's built, the users can't change the logic so this may be good or bad. Deployment can be tricky as OBA's are light windows applications. Only runs on Windows unless you use a citrix or similar technology.
ROI; good because of low entry cost, reduced errors, and highly repeatable once setup.
RIA/Light Switch:
Lightswitch is a Rich Internet Application (RIA) development environment that lets a business person create a rapid data entry application based on Microsoft Silverlight. There are other RIA platforms like Adobe Flash, Fireworks, etc... I like RIA's in general, but let's focus on LightSwitch since such a large portion of the AEC space is a Microsoft shop.
Cost; Inexpensive/Free depending on existing software/relationship with Microsoft. You can develop it yourself, with relatively little programming skills.
Integrity Level; Moderate for similar reasons to OBA's.
Pros/Cons; Similar to OBA's but it can be used as you design it more like prototyping on the fly by a non programmer. It's form based, so you don'te get teh native Excel experience. Depending on level of business/technical skills, could be preferred over the OBA development process. Once built, it's easy to deploy on any device silverlight applications run on.
Custom MiddleWare In-House:
The first of what I would really call "Integration Capable". These are standalone middleware, independent of the LOB applications and fit squarely in the part of the process as outlined in Post 3/6. This one is built in-house by the user company.
Cost; Moderate if you are moving a couple data sets one direction like the Business Case 1 in Part 2/6 of this series. Endless if you get into Business Case 3.
Integrity Risk; Moderate/Low depending on disciplined approach to quality software development.
Pros/Cons; Like the prior options, you own it. This means the IP, the code, the maintenance, and the problems. This becomes a much bigger problem as it grows. I can't stress enough how many people start here, and then decide to keep going into every requirements they can dream of, only to end up creating a substandard piece of software that was not designed with vision.
3rd Party Custom MiddleWare:
Built buy a 3rd Party and works identical to Customer Middleware 1 in terms of end user experience.
Cost; Similar to Custom MiddleWare In-House. Likely a bit higher than your internal estimate because of the best practices you are getting. Same idea as why people hire you to build buildings for them.
Integrity; Same or higher than Custom MiddleWare In House.
Pros/Cons; Similar to Custom MiddleWare In-House except you may or may not own the deliverable. A 3rd party with a good track record will take the time to listen & educate you. You can then gauge whether their methodology makes sense. For the most part, it should sound like you are building a construction project. IE, idea, discovery, requirements documentation, bidding, technical documentation, samples, drawings/specs, pilot, testing, QA/QC, delivery, punch list, etc...
Commercial MiddleWare:
Built buy a 3rd Party and likely works better than the other options because a lot of time has been spent refining the User Interface and User Experience.
Cost; License based, so it can vary widely by quality, feature set, flexibility, etc..like any other software application. May have significant implementation costs if it is not configurable by the end user. Watch out for the base cost plus all the connectors.
Integrity; Highest as it should be proven in the market.
Pros/Cons; Similar to other MiddleWare noted. Be careful to ensure the connectors exist. For example, if the connector required to go from NoteVault to Prolog (my example in Part 3/6 of this post series) does not exist, then it could diminish all the value of the MiddleWare. It is highly likely that the MiddleWare you buy will not have connectors to AEC Applications. If this si true, then make sure you apply scrutiny to the cost of the connectors, and treat this like a custom project where you may or may not want to develop it in house, our of house, etc...
In the next post I will break down a few points about how vendors from industries outside the AEC space are approaching integration and then finally some details about the AEC space and what I think needs to happen to reduce pain.