Standards only remain “standard” until the next change. Even in the B2B EDI world where trading partner data exchanges are “supposed to be” standardized, new additions and upgrades to later versions will create an opportunity to re-evaluate how data is being moved and stored for company consumption.
Traditional EDI transactions are built upon the “Header” and “Detail” premise where a single iteration of header information could be followed by many iterations of detail information. This makes it simple to build a database in support of this structure – a single transaction would see one record moved into the header file, and one or more records moved into the detail file. Header and detail would be linked together through common key values and sequential controls.
As requirements mature, changes are made and generally new information is presented. This could come by way of additional (single or multiple pieces of) data that could be stored in either the header or detail file. Trouble begins to brew when this new data is defined [by itself] as repeating information. Continue reading
User (backend) applications are built using many approaches…and for many purposes. From database to flat-file to XML, and from third-party-acquired to in-house-developed, the solutions vary greatly. In-house-developed applications are typically the result of several hasty decisions made by organizations that generally include either or both of the following reasons:
- The requirement (for now) is small – it will be quicker and less-costly to build an in-house solution while a long-term resolution is examined. Unfortunately, more often than not, the short-term solution becomes the long-term resolution, and ongoing challenges will bring about more long-term bandages.
- It is believed that a third-party solution certainly could not provide the customization needed for the company’s business and therefore it would be most beneficial to build an in-house-designed application rather than buying and re-customizing portions of an available third-party system.
When coupled with the varying Business-to-Business (B2B) data formats and production requirements that frequently change from customer to customer, a company can quickly find itself trapped in situations where it becomes more costly to implement and maintain a new customer than the gained revenue by adding that new customer. Continue reading