Using package applications without a defined data architecture strategy creates silos of data, making sharing data across applications extremely difficult.
Introduction
I once worked with a client where the business and IT did not have a peaceful history. The business made a strategic decision to move to packaged applications. They were convinced that the business would make the decisions and IT was not going to interfere in their packaged implementation. When the meetings were set-up for the application configuration IT did not play a significant role. There was a mistaken impression that the increased usage of packaged applications means a decreased role of data architecture . The opposite should be true. A solid enterprise architecture is crucial in a packaged application environment. When basic data quality rules are ignored, mistakes happen that will affect a company for years.
Without a defined data architecture strategy, packaged applications will create silos of data. The data will not be easily shareable between applications. Each department has the tendency to set-up a package in the way that makes the most sense for their department without being completely aware of the ramifications of their decisions. Viewing all data as an enterprise resource ensures that the data will be shareable across systems. When decisions are being made in the configuration of the accounts receivable package it is critical that it is clearly understood how those decisions will affect the customer service system. We must keep in mind that each data source is one piece of a larger puzzle. We must ensure that each new piece fits in with the existing pieces.
1) Pick a system of record for each business attribute
If a customer’s account number exists in four different systems, even if it is named differently, it still represents the same thing. It is one business attribute despite the fact that different packages may call it different things. It is therefore very important that one system becomes the system of record or owner for each attribute, and that the associated metadata be recorded in each system for enterprise use.
2) Define business attributes that cross packages as close to the system of record as possible
If we have multiple packaged applications using the same business attribute we should ensure that the applications define the usage of the field as close to the system of record as possible. Often packaged applications let you add user defined edit rules to a data attribute. For example let’s say that the account number in the system of record is numeric and we purchase another application where the account number is alphanumeric. We should then set up the second application to accept only numeric account numbers, using the same assignment method as the system of record, and record all relevant metadata for both sources.
3) Avoid embedded meaning in keys and codes
I have often heard the terms “smart keys” or “bundled elements” used when describing a key with meaning embedded in different positions of the field. In reality, this is not a very smart idea. For example let’s assume that we need to assign a unique number to each of our sales representatives. To make it easier for us to report we decide to embed the sales area as the first 2 digits of the sales representative ID. The remaining digits will be a unique number within region. This causes many problems. What if the sales rep changes regions? What if he temporarily covers for someone in a near-by region? Sales rep id and region id should be 2 separate attributes. Initially embedded meaning may seem like a good idea but it will cause confusion later. Then, the only people who can accurately use the data are the few people that understand all the hidden meanings.
4) Avoid misusing fields for other than their intended purpose
When it is discovered that a package does not meet the needs of the business one of the first things people try to do is force square pegs into round holes. Fields begin to be used for something other than their intended purpose. Sometimes with packages this is unavoidable but if it is occurring too much you may want to questions whether you purchased the correct package. Be careful of consultants who represent the software company encouraging the misuse of fields to cover up flaws or deficiencies in their software. Before a packaged application is purchased, the available data fields should be compared with the requirements to determine how closely the architecture matches the business requirements. Misuse of data fields and embedding meaning in keys result in a system that only a handful of people understand.
5) When setting-up user defined fields use the same rules as would be applied when defining new data elements
Another area that invites misuse is user-defined fields. Many packaged applications allow the user to “create” user-defined fields to be used by the application. Users can dynamically define fields to the application. When configuring these fields the same rules should be applied as adding any new elements to the enterprise. Among other things they should be named according to standards and avoid embedded meaning. Once again, record all relevant business and technical metadata.
6) Involve the right people
Any set-up and configuration decisions should not be made in a vacuum. There should be a mix of business users and IT. Along with representatives of the owning business area, there should also be representation from other areas that are directly affected by the decisions.
7) Document all requirements and decisions
In the simplest form, this means record the decisions made and any deviations taken in a usable and useful manner. This does not mean meeting minutes; it means a useful repository of information needed by the users of the data to properly exploit the data. Anyone using the data should have access to the decisions that affect how they use and/or report on the data. Ensure links among common business attributes that appear in multiple applications. The differences in the package definitions of these common attributes should also be documented.
8) Define the architecture before purchasing and configuring the packages
Don’t start building a house and then realize you should have drawn up blueprints. Draw your blueprints first then start building your house. If you do not know what your requirements are, how can you accurately evaluate vendor packages to pick the correct one?
Conclusion
When converting to packaged applications a good architecture is critical. Decisions should not be made in a vacuum. The right people need to be involved. If you must deviate from normal rules document your decisions. A defined data architecture is critical to the success of any IT initiative. Part two will look at these points in more detail.
