Monthly Association Meeting
Date: September 3, 1987
Time: 12:00 Noon
Topic: "Latest Procurement Topics" Impact of New Contract Legislation
Speaker: Meredith Jennings, Director of State Purchasing Division
Newsletter Table of Contents
IPMA Meetings Schedule
1987 - 1988 IPMA Officers
September 3, 1987, Association Meeting Agenda
July 2, 1987, Association Meeting Minutes
August 5, 1987, Board Meeting Minutes
A/I Expert Systems Group
Information Management Planning & Scheduling
Michael Brackett Article on Data Characterization
We want your input!
The IPMA Newsletter staff is always looking for articles of specific interest to our Stateinformation processing community. Send your drafts to:
Kathy Marston, Editor
DIS - 1310 Jefferson
Mail Stop: PE-11
Fall Forum Update
October 20-21, 1987
The following vendors have expressed in writing their intention to participate: AT&TInformation Systems; Apple Computers, Inc.; Banyan Systems, Inc; Capital Business Machines;Digital Equipment Corp.; General Data Comm. Inc; Harris Corp.; Hewlett Packard; IBM; ITTCourier Terminal Systems; PAC TEL Info Systems; Prime Computer Inc; Software AG; TandemComputers Inc.; Unisys Corp.; Wang Laboratories, Inc.; Xerox Corp; Cray Research, Inc.;Recognition Equipment, Inc; Mannesmann Tally; and the two Service Centers (DIS). Tektronixmay also participate.
This year there will be a common display area at the Tyee, i.e., vendors are not isolated inseparate rooms.
There are also rooms reserved for hospitality purposes, i.e., some vendors may treat the FORUMaudience at their own convenience.
LUNCHEONS & DINNER
This is a new FORUM event which reflects the FORUM goal for promoting professionalism andnetworking among state agencies. Dinner will take place on October 20, and luncheons onOctober 20th and 21st. Prices of dinner (including entertainment) and luncheons will beannounced later. Reservation forms containing the menu and related information will be printedin the September issue of this Newsletter.
IPMA MEETING SCHEDULE
The IPMA meeting schedule for the remainder of this fiscal year is as follows:
September 3, 1987
October 1, 1987
November 5, 1987
December 3, 1987
January 7, 1988
February 4, 1988
March 3, 1988
April 7, 1988
May, 5, 1988
June 2, 1988
IPMA Board and Officers for 1987-88
Darrel Riffe, Chairman (REV), MS: AX-02, PH: 753-2058
Richard Morgan (WCCC), Redmond, PH: 881-444
Jim Andersen (OFM), MS: AQ-44, PH: 753-4573
Butch Stussy (WLN), MS: AJ-11, PH: 459-6526
Lenny Roberts (DOL), MS: PB-01, PH: 753-6926
Kathy Marston (WDPSC), MS: PE-11, PH: 586-2832
Tara Wolff (DSHS), MS: LC-17, PH: 586-1256
Jeff Boyce (OAC), MS: EZ- 11, PH: 753-3365
September 3, 1987, Association Meeting Agenda
1. Introduction of Guests
2. Guest Speaker
Meredith Jennings, Director State Purchasing Division
"Latest Procurement Topics"
Impact of New Contract Legislation
3. Approval of Minutes
4. IPMA Board Report
5. DPA Announcements
6. Old Business
7. New Business
9. Other Comments/Announcements
July 2, 1987, Association Meeting Minutes
By Tara Wolff, IPMA Secretary
Darrel Rifle, our new chairman, opened the, meeting at 12:30 before 24 members and guests.
John Gerrits, substituting for Program Chairman Jeff Boyce, introduced Paul Kraabel of Kraabel& Company representing the Society for Information Management (SIM), a non-profitorganization. Mr. Kraabel and two associates from SIM gave a briefing on the SIM NationalConference being held in Seattle this Fall. The conference is being held at the Westin Hotel,October 11-15, 1987, The theme of this year's conference is "Beyond Planning: Implementingthe Vision." Mr. Kraabel said that SIM conducted a national search for experts in implementingsystems. These experts will also present case studies and talk about"'what really makes systemswork."
Mr. Kraabel then introduced Mr. Pat Smith, Chairman of the Northwest Chapter of SIM. Hedescribed SIM's national organization as well as the local chapter. The national organization has1,700 members representing 500 major organizations. There are two types of membershipsavailable; 1) top executives and managers of informational resources and 2) institutionalmembers.
The local Northwest chapter has quarterly meetings/workshops featuring high caliber speakerssuch as James Martin and Dick Dooley. They also have luncheons with guest speakers.
Pat then introduced Clay Sundermeyer, an executive MIS consultant from Digital EquipmentCorporation who talked more about the national conference. He Indicated that Bob Edwards isthe local liaison for the program and will have some written material available on conferencedetails. Clay announced that the keynote speakers will include William Gates (Microsoft) andRobert Dryden (Boeing Computer Services). Other speakers will include Richard Nolan,Stephen Covey and Admiral Grace Hopper (via satellite). The cost of the conference ranges from$250 to $1,300 depending on how much of the conference you want to participate in andv~nether or not you are a member of SIM. Clay also reminded the audience that the AAAIConference on Artificial Intelligence will be held in Seattle soon.
Jim Michael, outgoing Secretary Treasurer, reported a checking balance of and a savings balanceof $300 and a savings balance of $8,000.
John Flanagan announced that Will Wolf is Acting Director of the Department of InformationServices.
There was no old or new business.
Meeting adjourned at 1:10 p.m.
August 5, 1987, Board Meeting Minutes
By: Tara Wolff, IPMA Secretary
Chairman, Darrel Rifle, opened the meeting at 1:30 with a quorum present (Lenny Roberts, JimAnderson, Butch Stussy, and Gary Longmire).
Darrel Rifle gave an update on the 1987 Fall Forum plans. He briefly reviewed the list ofparticipants, and the tentative schedule of speakers and events.
Darrel announced that John Long had resigned from his post as Chairman of the ProfessionalEducational Committee. Jim Anderson agreed to lead the search for a new chairperson.
Darrel Rifle mentioned that there had been some discussion regarding an affiliation between theIPMA and DRMA He indicated that recently he had been contacted by yet another technicalgroup wishing to examine affiliation with the IPMA. Discussion followed and the board agreedto reconvene at a latter date to define IPMA guidelines for such an affiliation, and to clarify whatthe IPMA's role would be in such an affiliation.
Lenny Roberts reported on the status of some research being conducted on the feasibility of aCIC Assistant position; to date the overwhelming majority of the agencies polled respondedfavorably to the creation of a CIC Assistant position.
Some problems with the present arrangement with Arnold's Restaurant resurfaced and ButchStussy agreed to look into some alternative meeting places. He will report back at the next boardmeeting.
Tara Wolf indicated that the IPMA Budget for 1987-88 needs to be created; this issue will betaken up at the next IPMA Board Meeting.
The meeting adjourned at 3:30 p.m.
Artificial Intelligence / Expert Systems Group
Are you interested in forming a professional group on the Capitol campus? Several people in theIP community have had the same idea. We would like to meet with you and discuss our mutualinterests. Please contact any of us. We are compiling a list of those interested. We will be callinga meeting at a later date. THIS IS AN INDIVIDUAL OR PERSONAL ENDEAVOR. NONE OFUS IS REPRESENTING HIS/HER AGENCY IN AN OFFICIAL CAPACITY.
Dr. Ruben L. Marti, ED & TD, 586-1348
Ralph Crawford, State Treasurer, 586-1782
Javad Naini, WDPSC, 586-2287
Rush Brandis, WLN, 459-6522
Information Management Planning and Scheduling
Submitted by Twila Perry
Planning and scheduling workloads is no problem if the facts are known and the resources areavailable. The facts needed are:
1. What needs to be done?
2. How long will it take?
3. What materials, equipment supplies, personnel, are required?
4. When is the product or service needed?
5. What skills are necessary?
6. What circumstances could delay the project?
Management of an Information Processing section usually involves both maintenance of existingproduction systems and development and implementation of new applications. Problems thatoccur are primarily due to conflicts between available resources and due dates for the services.Scheduling, therefore, becomes less of a planning exercise and more of a prioritizing function.Those applications in production status normally take precedence over new development, andthe original planned implementation date for new systems slides, and slides, and slides. At somepoint higher management becomes impatient and insists on "Getting it up and running."Overtime is authorized, production systems are neglected, everyone involved becomes tense andirritated, and the new process is installed; incomplete, over budget, and with a year or more ofexpensive maintenance required before it runs acceptably.
With a track record like this, it will take time and hard work to restore user confidence in thecredibility of Information Processing support.
Question 1, "What needs to be done?" is the main key to successful scheduling. If therequirements of the new system are defined at this point in enough detail, a list of tasks willemerge. A time can then be estimated for completion of each task, and the sum of these timestotaled to give the answer to question 2, "How long will it take?". The same tasks are thenreexamined to give the answer to question 3, "What is needed to support the project?."
At this point it is essential to have some historical background on the amount of time spent bythe staff on maintenance, administrative duties, training, and any other activities that willsubtract from time available for the new project. With this information, a projected schedule isdrawn, showing the anticipated implementation date for the project if done with existingresources. If the system is needed sooner, more people must be acquired. This sounds Just great,but in this real world, people are not 'acquired' and "de-acquired" as needed. The answer mostoften heard at this point is, "Cut back somewhere else, and get the Job done!". The answer toquestion 4, "When is it needed?" is nearly always unrealistic. The answer to question 5, "Whatskills are needed?", is hypothetical, again, in real life, you work with what you've got.
The last question, "What could delay the project?", deserves the most careful consideration.People do get sick, machines do break down, transportation does fail, and mistakes do happen.
While planning is defined as a "Future shaping activity", this activity must be on-going as thefuture inexorably becomes the past. The problems of balancing resources against demandsbecomes a technique of fine-tuning as circumstances change. Ideally, surplus power, whetherstaff or machine, can ensure continuity of services through peak load periods. The cost ofmaintaining the surplus must somehow be absorbed during periods of low activity. The reversesituation of maintaining resources barely adequate for normal processing, leads to disruption ofservices when volumes increase or unexpected demands arise. This is when prioritizing must bedone, and is most successful if contingencies have been anticipated, and ground rules, (Planning)set-up in advance. Somewhere between these two extremes lies the best operationalmanagement.
In summary, in spite of the fact that few schedules are met, it is still a very good idea to haveone; it makes you look organized and efficient to your boss, it gives you something to wave atyour subordinates as you scream about missed deadlines, and if you carefully document thecauses of the delay, your status reports are written.
By: Michael Brackett, Washington State University
A data characteristic is a single piece of data that cannot be subdivided and still retain meaning.For instance, a person's age is a single data characteristic about a person. If that person's age, e.g.39, were subdivided into a 3 and a 9, those two individual digits would have no meaning as faras a persons age. The 3 and the 9 must appear together as a single data characteristic to havemeaning as a person's age.
A true data attribute represents a single data characteristic and has a name that uniquelyidentifies that characteristic within the enterprise. Data attributes that represent more or less thana single data characteristic are not true data attributes and should be avoided when defining adatabase. Any formal data design technique should assure that each data attribute represents asingle data characteristic.
A data attribute that does not represent a single data characteristic causes problems withunderstanding the data in a database, integrity of the data, and access to that database. Forinstance, combining the data characteristics for a person's height and weight into one dataattribute representing a person's body build, e.g., 68135, would cause problems with bothunderstanding and access. What does a body build of 68135 mean? How would the database beaccessed by either height or weight individually? This multiple characteristic data attribute forbody build should be subdivided into two single characteristic data attributes representing aperson's height and weight.
Most data attributes that are encountered in the real world are either single characteristic dataattributes or some form of multiple characteristic data attributes. In order to assure that each dataattribute in a database is a single characteristic data attribute, the data designer must be able torecognize data attributes that contain more than one data characteristic and redefine them assingle characteristic data attributes. This recognition begins with an awareness of the variousforms of multiple characteristic data attributes that can occur. The following definitions providea base for that awareness.
A multiple characteristic data attribute contains more than one data characteristic, Forinstance, a data attribute .might be defined to identify the quarter and year for a payment, such asPayment Quarter Year, The value for this data attribute might be 287 for the second quarter of1987, This data attribute really contains two data characteristics, one for Payment Quarter andone for Payment Year, and should be redefined as two data attributes.
Multiple characteristic data attributes can be either fixed sequential, variable sequential, orintertwined. The example above is a typical example of a fixed sequential multiple characteristicdata attribute because the data characteristics are sequential, quarter followed by year, .and thepositions are fixed, one position for quarter and two positions for year.
A variable sequential multiple characteristic data attribute has multiple data characteristics thatare always in the same sequence, but the positions are variable m length. For instance, a dataattribute for Employee Name might be defined with first name, middle name, and last name asthe sequence. However, the length of each word in the name varies from person to personmaking the positioning of each word in the name variable.
An intertwined multiple characteristic data attribute has multiple data characteristics but thecombination of the values of those characteristics is represented by some coded value, Forinstance, a Customer Type Code data attribute might be defined for hair color, eye color, andgender. Code I would represent blond hair. blue eyes, female; code 2 would represent blond hair,blue eyes, male; code 3 would represent blond hair, brown eyes, female; etc. The individualcharacteristics for hair color, eye color and gender are intertwined such that they are not readilyidentifiable.
A variable characteristic data attribute contains a different data characteristic based on thestatus of the data occurrence. For instance, a student data entity might contain prospectivestudents, undergraduate students, and graduate students, A data attribute for Student Status Datamight mean the date first interviewed for students, and the date of undergraduate graduation forgraduate students, The data characteristic is variable depending on whether the student isprospective, undergraduate, or graduate.
A complex characteristic data attribute contains multiple characteristics that are variable, i.e.it contains a combination of the multiple characteristic and the variable characteristic forms ofdata attributes, For instance, there are three types of customers: new customers whose credit Isunknown, existing customers with good credit, and existing customers with poor credit. A dataattribute for Customer Code is defined which includes a combination of income, interests, andpotential buying power for new customers; a combination of maximum credit and rate ofpayment for customers with good credit, and a combination of credit rating and probability ofcollection for customers with poor credit. These three sets of multiple characteristics are variabledepending on the type of customer.
Mutually exclusive data attributes are two or more data attributes that are defined to representtwo or more values of a single data characteristic, i.e., one data attribute for each data value. Forinstance, a product may be shipped to a customer via air, raft, truck, or the U.S. Mail. A separatedata attribute is defined for each of the four methods of shipping but only one data attributecontains a value for any one shipment. The other three data attributes are either null or blank.
All of these non-single characteristic forms Of data attributes cause major problems withunderstanding the database, data integrity, and access to the database. The problems are theirseverity vary with the form of the data attribute.
One of the major problems the understanding of the data m the database by people other thanthose who designed the database. Imagine going to the database and trying to decipher the values for the Customer Code described above, particularly when there is no documentation of that dataattribute. Even if the individual code values were defined, imagine the problems of interpretingthose codes based on the type of customer. Obviously, seven separate single characteristic dataattributes would be far easier to understand, with or without adequate documentation.
A second major problem is access to the database, particularly in an environment where ad hocprocessing by users is becoming popular. Again, imagine trying to select occurrences from adatabase that met criteria that were buried in a variable characteristic or complex characteristicdata attribute. The inquirer would need to know additional information about the type ofoccurrences and would need to develop additional process logic to acquire those occurrences.
A third major problem is the redundant data that occurs with non-single characteristic dataattributes. For instance, ff hair color were part of three separate intertwined multiplecharacteristic data attributes, then hair color is stored redundantly in the database. This implieddata redundancy is just as serious, ff not more serious, than any explicit data redundancy. Itcreates the potential for storage anomalies the same as explicit data redundancy and leaves usersin a quandary when redundant values disagree.
A fourth major problem is the loss of useful data. For instance, when there is a change in thestatus of a data occurrence, such as from prospective to undergraduate student, the date ofinterview is lost. If the date is no longer needed the loss is acceptable, but if that date is neededfor any future inquire the loss is not acceptable. It is better to have single characteristic dataattributes and plan the acquisition and destruction of data based on the individual characteristics.
Data characterization is the process of assuring that each data attribute contains a single datacharacteristic. Once single characteristic data attributes have been defined, they can benormalized into their proper data entity. Then each data attribute can be named according to aformal naming taxonomy.
New data attributes should be defined as single characteristic data attributes. Existing dataattributes that contain multiple characteristics need to be redefined into single characteristic dataattributes. This redefinition still leaves the multiple characteristic data attributes in the database,but it does set the stage to either restructure the database or to use some form of data converterwhen accessing the database. These data converters are a form of data independence that allow aprogram to use single characteristic data attributes from a database that contains multiplecharacteristic data attributes.
In some cases there may be a valid reason to define a multiple characteristic data attribute. Whenthese cases arise, a sequential multiple characteristics data attribute can be defined, but nevervariable, complex or mutually exclusive data attributes.
The first case is where there is no need for accessing the individual characteristics. For instance,a date containing day, month, and year, or a persons name containing first name, middle initial,and last name, could be defined as one data attribute if the individual characteristics of that dateor name were never needed. Since it is hard to substantiate "never", it may be better to definesingle characteristic data attributes and define a data attribute group for the date or the name.
Another case is where the DBMS cannot handle all the data attributes needed to define theprimary key. A sequential multiple characteristic data attribute needs to be defined where all orpart of the single characteristic data attributes are concatenated to meet the limitations of theDBMS. In this case it is advisable to maintain both the single characteristic data attributes andthe multiple characteristic data attribute. Even though this creates data redundancy, it is a knownand controlled data redundancy.
There may be other cases for defining multiple characteristic data attributes, but each caseshould be evaluated and alternative methods investigated.
The objective for defining data attributes is to define single characteristic data attributes.Whenever multiple characteristic or mutually exclusive data attributes are defined problems withunderstanding the data, data integrity, and database access are created. When singlecharacteristic data attributes are defined the understanding is increased, data integrity ismaintained, and access to the database becomes easier. An awareness of the existence ofmultiple characteristic data attributes and their various forms helps the data designer redefineexisting data attributes and properly define new data attributes.