|
Newsletters
(Maj, 1998)
- Customers and Consultants in Focus
- The Clever Developers at Company D
- Ups and Downs in Prototyping - The fixed Deposit System
- Year 2000 - An Implementation Experience
Customers and Consultants in Focus Tilbage
123
My last position was as Account Manager by a large IT-supplier where I was sales responsible for several large industrial companies. From having been talking about Network integration, standard applications and similar, I now have to make myself acquainted with the terms of the Maineframe business. During the last month I have had the pleasure of meeting almost all customers and consultants in Denmark which are primarily based in the financial sector. At these visits I have realised that there are many similarities in the challenges the companies faces, no matter which line of business you are in.
Bellow I have drawn up a list that mentions some of the challenges:
Difficulties in keeping employees (permanent and external)
Lack of resources (few applicants, lack of qualifications)
Very short deadlines
Too many projects
Lack of specific know-how
In the following I will try to outline how I view Contracters A/S and my future role in today’s turbulent market for consultants.
“Hit the mark”
By means of the consultants who are employed at Contracters A/S, it is my assignment to try to help the customer. I have to relate to the urgent needs of the customer and to the best of my ability find the resource that matches the customers needs. My personal success criterion is to “Hit the mark” and work with a professional attitude.
Reliability
To be able to maintain a good and long-lasting partnership to both customers and consultants it is necessary to communicate well and keep focus. We want to build up a relation based on reliability and trust. To be able to live up to the demands and expectations of our customers, we will always present new consultants through well documented CVs and in person.
Furthermore our consultants are firmly tied to Contracters A/S which means that we offer our customers a steady manpower.
Through our careful selection of consultants with different backgrounds and experiences, we are able to offer our customers exactly the resources they need.
Follow-up
When the consultant has started his work at the customer, I or another representative of Contracters A/S will visit the company frequently. I believe that it is important to stay in close contact to both the customer and consultant during the contract period, to be able to solve eventual problems and face new challenges right away. We wish to make sure that our consultants have a steady and positive relation to the company they are working for. We are staying in close contact with the project leader, who has the daily contact with the consultant.
Service office in Denmark
To be able to offer our Danish customers an optimum service we are at the moment establishing a new office in Risskov. We expect to open the office at the end of May and will by then have a modern office with all the newest electronic tools. It will be possible to get all relevant information about our available resources etc. either by telephone, telefax or e-mail. As everybody agrees that time is in short supply, we want it to be fast and effective to do business with Contracters A/S.
Customer and Consultant in Focus
As mentioned in the headline we are focusing on all conditions around the customer and the consultant. We think about more than only pure numbers, we are highly attentive to other variables such as human chemistry, job satisfaction, family and spare time. By focusing towards all the above mentioned aspects I look forward to a long and fruitful co-operation with you in my new job at Contracters A/S.
The Clever Developers at Company D Tilbage
123
The author of this article was a member of the user application development team in Company D between 1986 and 1995, and as such was to gain first hand experience in confronting end users with the challenge of the continual change and evolution in the world of data processing.
The Situation in 1986
Company D never had the problem of downsizing. Even though it had 20'000 employees in subsidiaries spread over the whole non-communist world, it managed its business consistently with the minimum of materials and resources.
This policy was clearly reflected in the structure of the group computer development centre at head office. In 1986 this consisted of the system development team of 6, the application development team of 6, the department manager, his assistant and a secretary, whereby each team included the one team responsible.
The Resources
All system and application work was carried out on a PDP machine of Digital Equipment Corporation. The systems team developed the tools with which the applications team constructed the end user applications. It was the job of the department manager to maintain contact with the end users and specify what their requirements were for computer processing. The applications supported the two most important functions of the business, forwarding and accounting, to start with. Beginning with head office itself, all subsidiaries of the company were expected to supercede their manual business processes with the newly developed computer applications, and to this end the department manager’s assistant arranged for the delivery of an appropriate model PDP computer to each subsidiary. He then visited each subsidiary equipped with a suitcase full of tapes and installed the software. A workshop was convened at head office and the computer responsibles of each subsidiary were instructed in the operation and the functionality of the new business tools. Of course, there were business methods which were different from country to country, and where the local person responsible was unable to modify the software himself, a developer was sent from head office to do the job.
The Development Concept
In compliance with the concept of doing business as a downsized company, it was clear that the growth in the computerised world should cost only that which was of immediate need. Why buy a luxurious database management system when one can be built tailored exactly to one’s present needs, with no superfluous functions binding resources which could be employed usefully elsewhere? Based on the same consideration, why licence a programming language compiler where functions peculiar to this business are missing, but offering others of no use at all? Hence the direction chosen by Company D was that of complete independence from proprietary software wherever possible, and as far as manpower resources and know-how would allow it.
The Products of the Systems Team
A programming language was envisaged following the syntax of IBM’s PL1 compiler and to be called PLD. As soon as Digital brought their VAX machines on to the market their advantages were immediately recognised and PLD was rewritten to comply with the new internal architecture. As hinted above, a database management was developed hand-in-hand and fully integrated into the compiler, so that the data manipulation statements were part of the PLD language. Each application had its own database design and any number of databases could be included in any PLD program. The database definitions were written in an editor file and then compiled with a Digital proprietary program to become active. In time this program was found to be an unnecessary expenditure and was replaced after a new team member was engaged to create a dialog system for entering the database definitions.
The Development of the Computer Development Centre
As mentioned above, systems offered the application de
Ups and Downs in Prototyping - The fixed Deposit System Tilbage
123
This is a description of a project which shows examples of the strengths and weaknesses of using prototypes in systems development.
In 1994, I was attached to a project which had the goal of creating a system to handle fixed deposits in a bank. Using the HPS I-CASE tool we started by analysing the existing business procedures and systems, thus making sure that we knew the business of handling fixed deposits.
The Business
The procedure of handling fixed deposits is largely like this: a customer calls the bank. He has 1 million fr. that he wishes to deposit for 3 weeks. Based on this information the customer gets a quotation saying that for a deposit of 1 million fr. in 3 weeks, he can have a 4˝% interest rate. If the customer accepts the quotation, it turns into an agreement, the customer receives a written notification of the terms and the money is transferred from a current account or another source into a fixed deposits account. After 3 weeks the money, with interest, is then transferred back to the customer’s current account.
Even though we felt that we had analysed the business of handling fixed deposits quite thoroughly, there was a problem. How should we validate this with the users? It was very nice to think that we understood the users’ situation, but did they agree? We had to find a way to show them our understanding of their situation.
Prototyping
Data modelling is a fairly central component in HPS systems development. This is a one of the great advantages of HPS, because many systems developers tend to consider data modelling a more passable approach to analysis and design than the traditional functional analysis, for instance data flow diagramming. In HPS, data modelling results in a number of business objects. A business object is one or more entities, i.e. things we want to store data about. In the first part of the fixed deposits project we identified two business objects, quotation and agreement.
Largely speaking, when you have defined the business objects in HPS, you automatically gain the user dialogue flow, i.e. you know what screens you have to produce. So from that point it didn’t take long to produce what in HPS terminology is called a “dry“ prototype. A dry prototype is a prototype without any data. You can see the screen layout, the fields, texts, scrollbars, pushbuttons et cetera, but there are no data.
From the business objects, quotation and agreement, we did a rough screen layout, with navigation between the different screens, and presented it to the users. We told the users: “When a customer asks for a quotation, you enter the customer id here, the amount here and clicks this button to get a presentation of the different periods and the corresponding interest rates…“ We walked them through the screen layout by using the stories they told us from their everyday experiences with handling fixed deposits, often starting with “A customer calls and says…“ This way we used the prototype to show the users our understanding of the business of handling fixed deposits.
The users’ feedback told us that we had indeed understood the business of handling fixed deposits, even though there were several minor things that could be improved. Based on the feedback we refined the prototype, put data into it (thus making it a “wet“ prototype in the HPS terminology) and presented it to the users again. We continued this cyclic process until we finally totally agreed on the systems user interface.
The users also told us that they thought the prototype approach had one very significant benefit: they could better relate to the prototype than to the traditional written documentation, the system specification. The prototype gave the users a better impression of what the final system would be like than any system specification could do. So that was a success for prototyping.
Technical Construction
The next phase in the S
Year 2000 - An Implementation Experience Tilbage
123
Having read and heard numerous articles on the subject, I was eager to be involved in the “real thing“, as I expect most of my colleagues in the field would be. During most of 1997, I got my opportunity, joining the team of a major Dutch bank as an external consultant. I was employed in the Foreign Department. The bank assigned all Y2000 activities to the maintenance department, possibly because (rightfully) the Y2000 problem was seen as a gigantic, complex bug...
Programming Environment
The system employed was an IBM mainframe running MVS, DB2, IMS and CICS. The programs involved counted ca. 20.000 PL/1 source modules, with an average size of about 1.000 lines of code each. The age of the source modules varied between 2 and 10 years. Endevor, by Computer Associates, was used (since very recently) as the development control system.
Strategy
The maintenance team was to scan and modify all source modules in use, if only to mark the module as Y2000 proof.
A number of scanning tools were to be run against every module, e.g. to detect the occurrence of “suspect“ character strings.
Any dates, system or otherwise, had to be obtained through calls by standard modules, source code to be modified to conform to this requirement.
Files using a 6-digit date were rarely modified to “expand“ the date fields, since most of them originated from outside the bank, even outside the bank’s home country. If manipulation of these dates took place (mainly sorting chronologically), the files were only temporarily expanded in intermediate versions.
A number of changes had to be made, if necessary, to prepare for the support of the Euro, about a year prior to the millennium change. In general, this practice would have to be advised against strongly, but my guess is that the bank saw no other way of scheduling these changes in time. Furthermore, it has to be said that for the foreign department of a bank, the Euro means only support of one additional currency, and the gradual phase-out of a number of currencies.
All source modules had to be compiled prior to and after modification (even if the only change was the “Y2000 proof“ mark). The maintainer had to run program tests and system tests (“system“ refers to the application complex, varying from 20 to 70 source modules). Dates (simulated through IMS tables, invoked by the standard date routine) had to be set up for key dates around the millennium change.
After successful completion of the system test, the application complex had to be transferred to the User Acceptance Test department.
The “real world“
In general, I must say that a number of events happened as planned, but, not surprisingly, experience led to some deviations from the planned strategy. The most important change of procedures was the planned use of “detection tools“. In reality, more often than not the “suspects“ lists produced were only confusing. An avalanche of “suspects“, effectively hiding the few real candidates for program change, whereas the tool did not detect date manipulation using non standard names, giving a false sense of security. In the environment sketched at least, the old fashioned visual method could not be beaten by any (available) tools.
Since the systems department had provided useful tools for the generation of a test environment from the production environment, most time preparing for the tests was used creating or obtaining test data. Access to the complex and very volatile production data was very, very limited, no doubt for good reasons...
The approach of the standard date modules using simulated run date could not be avoided, since the bank did not have the luxury of a dedicated test mainframe, so the system could not be started with any other run date than today’s date. The approach was workable, but caused a tremendous overhead
Return to Newsletters
|
