AEC Application Integration : Part 1/6, Definitions

In the last year or two I’ve seen a significant increase in questions about software integration from AEC customers, vendors, and reseller partners. In ten years, my company has often pointed people in the right direction (insert middleware of choice) for things we don’t do, built numerous integrations when nothing is available, and scratched our head a lot at why this so difficult & expensive. I’ve broken this post series down (+/-) into Definitions, Business Use Cases, Technical Requirements, Options & Gotchas, Other Industries & the AEC Space. Here we go…

The following definitions are crafted from concept and examples simply intended to help keep this series of posts clear.

Role Specific Application (RSA); This is a single or limited task application that while very powerful and useful, is generally not being used by a wide range of users. Examples are Vela Systems (primarily field data capture), Encompass Mobile (Field data capture), Notevault (Mobile data capture), or an OFfice Business Apllication (OBA).

Line Of Business Application (LOB); This is a broad application that handles a wide range of use cases for an entire discipline. Examples are Dynamics (CRM), JD Edwards One World or Master Builder (accounting), Prolog Manager, Contract Manager or eBuilder (portfolio/project management), or Projectwise (engineering content management).

Middleware; This is an application that sits in the middle of two other applications and helps them communicate. It could be a “feature” built in to one of the two RSA or LOB applications, or it could be a 3rd party or custom application from a different vendor. Some examples are Biztalk, Fusion & MTG Frameworks.

Adapter; These are software components that generally are required to enable an RSA, LOB application to communicate with middleware.

Datastore; This is where data is stored for an RSA or LOB application. It could be an MS SQL or Oracle database, a flat file database, or an XML file. My references simply refer to a container where data is stored that you want to get from one place to another, regardless of format or how it got there.

Dataset; This is simple a set of data that you have defined and want to use in your integration. Examples would be 5 fields from an RFI, 8 fields from a Change Order, or both.

Data Warehouse; This is similar to a Datastore but it’s a collection of data from various Datastores. An example would be an aggregation of data from numerous LOB and RSA applications into one place, generally for purposes of backup, integration, etc…

Products; Software Applications generally commercially available for a standard licensing fee.

Projects; Software Applications generally custom built for one company or business use case without plans to productize the application.

Enterprise; A term used to indicate that the software is built based on industry standards as if it was going to be used in a high availability, business critical environment. It could be a Product or a Project.

TCO & ROI; This is not specific to integration, more general solution benefit analysis, but I’ve yet to note it in other definitions on this blog. TCO or (Total cost of Ownership) is the entire cost of the effort including software, hardware, human resources, depreciation, financing, etc.. & intangibles like stakeholder satisfaction. ROI or (Return on Investment) is the delta between the TCO of two solutions over a given period. For example; solution “A” costs $500,000 to run for 3 years; solution “B” costs $100,000 to purchase, and $350,000 to run for 3 years; then in theory you have saved $50,000 over 3 years and potentially more going forward.

Stakeholders; This is another general term, it Includes but is not limited to business owners, decision makers, end users, consultants, vendors, etc… Essentially anyone that will have interest in the result of a solution.

Ok, that’s some definitions we will need…post two coming shortly.