Relational Database Management System
Web Pages
Electronic Data Interchange

Matrimony.com will rely heavily on technology to reduce transaction costs and provide customers with superior service levels. We will need to investigate several areas including hardware, software, value added networks (VAN) and electronic data interchange technology (EDI).

Relational Database Management System (RDMS)
A RDMS will be the heart of matrimony.com. This database will be the string that ties the wedding guests, the bride and groom and our gift suppliers together. The database will need to manage inbound customer orders, outbound purchase orders, inventory, accounts payable and related financial functions. In addition, the database will need to be able to link to our web pages and will also need to support specific EDI transaction sets.
A key decision we will make early on is whether we plan to build or buy this software. Firms such as iCat and Microsoft (Internet Merchant) make off the shelf tools that could possibly be used. However, after an initial assessment, we don't believe that either of these packages would be full featured enough for us to use. To help make the build versus buy decision we will work through the first two steps of the Systems Development Life Cycle (SDLC). Based on this analysis, we will either draft a RFP to solicit bids for our project or we will continue on with the remaining steps of the SDLC and build our own database. If we decide to build our own software we will probably combine prototyping with the more formal SDLC in order to minimize costs and the time necessary to get up and running.

Web Pages
We will design our preliminary web pages using our own staff. Web pages will be simple, but functional. Emphasis will be placed on speed of updates, integration with our RDMS and the logical layout of pages - not graphics. We will investigate using either Active X or Java to integrate our web pages with our RDMS. In the future, we will consider outsourcing the design and maintenance of our Web pages to a firm that specializes in that area to reduce fixed costs.

Electronic Data Interchange (EDI)
To keep our cost structure as low as possible, we intend to use EDI when we interact with our suppliers, logistics partners and banking partners. EDI is the computer-to-computer exchange of standard business documents. We plan to use the World Wide Web as the primary interface with our customers and EDI as the primary interface with our suppliers. If we are able to achieve this strategy we should be able to dramatically reduce our cost structure.
As an example of what benefits EDI can provide, reference the Wal-Mart example. The following quote appeared on page 6 of the Economist, March 4th, 1995. "The first benefit [of EDI] was just-in-time replenishment across hundreds of stores… The second benefit was cost. According to Sam Walton, founder of Wal-Mart, Wal-Mart's distribution costs in 1992 were under 3% of sales, compared to 4.5-5% for the firms competitors -a saving of close to $750 million in that year alone." While the 1.5 - 2.5 percentage points mentioned above might not seem very material, it is critical in the retailing business where margins are extremely thin. We feel we can achieve additional savings due to the fact that we are integrating EDI with WWW based technologies. Overall, we think this is an excellent marriage of two compatible technologies.
EDI is all about standards. As such, one of the most important decisions matrimony.com will need to make first is which of the EDI standard do we want to use - X12 or EDIFACT? X12 is essentially the "American" set of EDI standards while EDIFACT is more of an international standard. X12 has a large inventory of available transaction sets and is widely used in the USA. EDIFACT on the other hand is newer, gaining acceptance outside of the USA (particularly in Europe), but does not have as complete a set of transactions. X12 is moving to merge with the EDIFACT standards, but the two standards have not been merged at this time. Since we believe most of our suppliers will be US firms our initial thought is to use the X12 standard. We will seriously consider a dual X12 and EDIFACT implementation if we determine some of our suppliers and logistics partners (or future partners) are from outside the USA.
The intial X12 transaction sets we will need to support include the following: