Content Copyright © 2007 Bloor. All Rights Reserved.
How do you survive as a vendor in a space that is dominated by big boys? That question is one that a great many companies have to face. No doubt you have a number of existing customers that you need to keep happy, so you need to continue to develop your existing product(s) but that’s not going to grow the business fast enough if you can’t rise above the competition by out-maneuvering the 800lb gorillas in new accounts. One possibility is to target a niche market, a second is to branch out into something completely new and a third is to develop new products on top of your existing offering. Of these, the first is no more than a survival strategy and the second is a gamble. I would contend that only the third approach has real potential, especially if you can spot a gap in the market that is not otherwise being addressed. This is exactly what ETI is doing with its ETI Built-to-Order™ (BTO) integration product.
To go back a step, ETI was one of the founders of the data integration space. However, unlike all of today’s major players ETI adopted a code generating approach rather than a ‘black box’ approach to this issue. This has proved to be popular in environments where security is paramount—having a black box where you can’t see what is going on is not ideal for, say, the FBI—and where the data environment is extremely complex. However, for general-purpose use the trend has been towards adopting an engine-based approach to data integration, so ETI has had to look elsewhere for continued growth.
Now, if you think about it, where a code generating approach undeniably makes sense is in project-based data integration deployments (which ETI refers to as operational data integration). Suppose that you have a data migration issue, either as a stand-alone exercise such as migrating from one database to another or as a part of a larger migration project to, say, consolidate your ERP systems onto a DB2 platform or migrate from PeopleSoft to Oracle. You could deploy a platform-based solution using Informatica, IBM, or for that matter, ETI, but this is overkill here because you have very specific source, mapping and target requirements: you are licensing (and paying for) large amounts of generic capability that you do not need for this particular project. The same would be true of any on-going, yet specific project: for instance, if you wanted to link a Teradata warehouse with multiple SQL Server data marts or if you wanted to move to Salesforce.com’s CRM environment.
To address this gap left by traditional data integration platform approaches, ETI has pioneered what it calls “ETI Built-to-Order” (BTO) integrations. These are one-off point-to-point integration solutions that are constructed by using (but without having to licence) the company’s existing data integration product, ETI Solution® platform. The company provides free access to its ETI Integration Center™ (iCenter) Web portal (www.eti.com/icenter), which provides a formalised and repeatable process for gathering high level integration specifications. Of course, we all know about specifications, so if your specifications are not already defined (they’ll accept the more traditional Microsoft Word or Excel documents, too) you are given the option of either entering your integration requirements into the ETI iSpec™ client via the iCenter or ETI’s integration engineers will work with you to ensure that your specs do actually match your requirements.
You are then provided with a fixed price quotation (on average $25,000) for your point-to-point interfaces with all the mappings, transformations and business logic built-in, based on your specification. BTO integrations can support multiple source systems and populate multiple target systems and are delivered as ready-to-run executables. Furthermore, BTO integrations are delivered with documentation that provides full visibility into everything done to the data values in the process of executing the interface. You can even purchase the source code if you’d like.
Of special note is that ETI guarantees delivery of a BTO integration solution to specification at a fixed price on a set date (usually within 2 to 4 weeks). As far as I know, this guarantee is unique in the industry and it is an important differentiator for ETI. In particular, the result is that fully documented integration components are delivered in a matter of weeks whereas this process might commonly take months (and cost a great deal more money). Similarly, changes can often be effected in hours rather than days or weeks.
Because all of ETI’s products (including its own ETI Solution data integration platform) tend to use native capabilities (or possibly bulk loaders, where available), its generated code is likely to run significantly faster than would be the case if using an engine-based approach.
Of course, you could argue that if you already have a platform in place as an enterprise wide solution then you will not need BTO integrations. However, there are several points to consider here: first, many companies do not have enterprise policies about data integration; second, even where they do, it may be still faster and cheaper (in terms of manpower) to use a BTO integration and, third, BTO integrations may well be a good way to supplement whatever existing integration software tools you may already have in place. This last point may need some explanation: it refers specifically to those times when you’re required to drop out of your engine-based product to write those custom snippets of code called out as user functions (we all know it happens). ETI BTO integrations may be the perfect solution for integrating that last 20 percent of the process.
The bottom line here is that if you don’t have an ETL platform in place then using the ETI Built-to-Order approach will save you a lot of time and money (compare ETI’s prices with a typical platform solution at $200,000+) and even if you do, ETI promises a faster, more secure solution in less time, without taking up valuable developer effort. It is certainly something worth considering.