DDL Script

Define the specifications for the design and development of systems and software is a bit like the classic Gershwin song and what I personally consider the biggest cause of confusion in the field of information technology as long as I remember, this is more than 30 years in the industry. Some people say specifications should be based on the inherent properties of information, others believe it is based on a screen / report or file layout, still others think it should be categorically based on the process specifications and data. Interestingly, all are absolutely correct. The difference lies in the perspective of the person and the job. For example, how we define the specifications for the design of a car is certainly different from the way we specify a skyscraper. The same is true in the IT area where we have different things to be produced by different people, for example:1. The programmer (aka, Software Engineer) requires precise specifications in order to develop a program code (source and object). It normally takes the form of processing requirements (eg, hardware, types of transactions to be processed, the volume, timing, messages, etc.) and the need for physical data (input / output / file layouts).

2. DBA (Data Base Administrator) requires precise specifications to select a management technique appropriate file (eg DBMS) and produce the necessary data definition language (DDL) for that. It normally takes the form of a model database representing the logical relationships between data entities.

3. The analyst (aka, Systems Analyst, Systems Engineer, Systems Architect, Business Analyst) – requires specification of the information requirements of the end user to design a system solution. This is normally based on a definition of commercial activities of the user and / or decisions that must be supported. After the system design, the analyst product specifications required by the programmer and DBA to fulfill their part of the puzzle. In this perspective, the analyst is the translator between the user and programmer and DBA.

Each party has its own unique perspective to the puzzle, and as such, requires different “specifications”. To compound the problem, however, the role of the analyst greatly diminished over the years, leaving programmers to try to determine what the needs of end users, a skill they are generally not trained or suited for. To illustrate, I recall the history of the IT Director in a shoe manufacturing company that has received a call from corporate sales manager for help on a pressing problem. The Director has sent more than one of its programmers to meet the sales manager and discuss the problem. Basically, the manager wanted a sense of all footwear sales sorted by model, volume, type, color, etc. The programmer immediately knew how to access the necessary data and sorted accordingly, producing a large print (three feet high) he dutifully delivered to the user.