My name is Patrick Smith, I am currently the Lead Database Administrator for Electronic Payment Exchange, EPX, which is a wholly owned subsidiary of North American Bancard. I have the responsibility of making sure that all of our database systems are constantly available 24 by 7 by 365, and meet all of the business requirements of our organization.
EPX, the division that I work for, has about 32 employees. North American Bancard has several thousand overall. So EPX could be viewed as a small division in a larger company. Our company is committed to the complete satisfaction of our customers requirements for processing their electronic funds transfers, and doing so in as economical manner as possible to save them money, and to do so reliably, and with a very high level of security.
We provide a higher level of quality with respect to the flexibility of programs that we can make available to our clients, we also provide a much higher than typical level of security to our clients, and we also provide significant cost advantages to a large majority of those clients. Of course the opportunities for that depend to a large degree upon the character of the clients themselves.
Well, we're pursuing the extension of our database replication to begin to explore migrating certain decision support elements off a core processing platform onto data marts using replication tools. We are primarily an Oracle shop with respect to our database technologies, we have a wide range of proprietary applications servers with a lot of in-house developed software in a a number of languages from .NET to C++ to assembly language to PL/SQL. We primarily do most of our processing in Linux environments, and with Oracle at this time.
Our users never access our databases. We have literally thousands of users who look at data that comes out of our systems. We have quite literally thousands of points of sale terminals across the world and websites that provide data inputs to us, but the only users who access our databases are the application server tier, which passes those processes and data to and from those end users, and our internal users who are doing development, operations, quality control, and security.
Our business problems are fairly constant. The need for extremely reliable processing with zero errors, there can be no failures in any aspect of our processing or of replication of our processing, and we have to do so not only with reliability, but extremely high level of security within a very tight SLA.
We chose SharePlex because we had a critical business need for completely reliable, relatively high speed replication which could be verified on an ongoing basis at a affordable total cost of ownership.
The challenges that I deal with in my job do affect my personal life, and my job is all about stress. I cannot afford for my databases to be down, I can't afford for our company not to be able to perform its computer operations, because all our company does is computer processing, that's our only product. If we're not processing, we're out of business until the processing resumes. That's not acceptable, it affects not just me, but every other individual employed by my organization, and I feel a responsibility to my coworkers, and to the management of the company that's personal, and that's stress involved.
For replication, previously we were using Oracle's Golden Gate. Our implementation was not successful, we were not able to practically, and quickly verify the correctness of replication in order to permit business operations to move into the replicated environment with confidence. Our previous solution did not allow us to efficiently, and rapidly verify the correctness of replication in order to allow the business to move to the replicated platform with confidence. Well, we looked at Oracle, we looked at a custom solution which we would write ourselves, and we looked at SharePlex.
The native replication features in the Oracle database are not really a form of logical replication. We could have created a logical standby, but we did not feel that that was really an adequate solution, nor would it have allowed the target to be fully read, right. It made that solution unacceptable, it was not available to us because it did not solve our problem. We evaluated the replication solutions that we looked at by actually implementing, and trying them. We looked at the possibility of writing our own replication product, specifically for our requirements, and we did implement it on a partial scale across our database successfully, but we abandoned it as having a total cost of ownership far too high to be acceptable to the business.
Our previous implementation took 18 months from the initial installation in production to the achievement of what our technical team believed was a successful implementation. However, we experienced numerous problems which required a substantial learning curve to overcome during that 18 month period which resulted in the loss of confidence in the solution by our management team. Our previous solution was presented to us as a relatively low cost, and relatively trouble free solution which could be implemented with minimal investment, and expertise said training. In our experience that did not prove to be the case, the total cost of ownership is significantly greater due to a requirement for greater investment in internal technical expertise, and familiarization.
The challenges in our previous implementation again were primarily in addition to overcoming the need to invest in the product to achieve success was our inability to practically, and in a timely fashion, verify to management's satisfaction that the replicated environment was exactly synchronous with the source environment. Additional add-ons to the previous solution if they had been initiated early in the process might well have resulted in success in that effort. The failure of our organization to make that initial investment was a critical part of the end-to-end success of the effort. However, at the conclusion of the project so much