unitIT4

Study Unit IT4 - Strategies and Platforms

Copyright Notice: This material was written and published in Wales by Derek J. Smith (Chartered Engineer). It forms part of a multifile e-learning resource, and subject only to acknowledging Derek J. Smith's rights under international copyright law to be identified as author may be freely downloaded and printed off in single complete copies solely for the purposes of private study and/or review. Commercial exploitation rights are reserved. The remote hyperlinks have been selected for the academic appropriacy of their contents; they were free of offensive and litigious content when selected, and will be periodically checked to have remained so. Copyright © 2001-2003, Derek J. Smith (Chartered Engineer).

First published 07:59 GMT 20th February 2001; this version [v1.2 - with graphics] 11:10 BST 24th June 2003

This is the fourth of nine post-foundation study units making up the INFORMATICS e-learning resource published and supported by Derek J. Smith (Chartered Engineer). For further information, please e-mail me.

Unit Aims and Outcomes: This study unit looks at the main ways to computerise a business process, and at how a combination of strategic and technical factors often prevents a totally free choice between them. When you have completed it, you will be able to deploy with enhanced confidence and accuracy the specific skills and vocabulary listed below:

Specific Skills	Vocabulary
1. Distinguish strategies from tactics, and carry out a small strategy study.	corporate vision; hardware platform; strategy study; strategies vs tactics; system architecture
2. With interdisciplinary assistance where appropriate, consider a range of possible technical solutions to the problem at hand.	application service provision (ASP); business process re-engineering (BPR); database; laptop vs desktop; network; software houses; standalone; "stiffing"; turnkey
3. In the light of (2), shortlist and formally describe systems architectures appropriate to the problem at hand.	prototyping

Unit Structure: This unit contains three short lessons, each contributing to the overall unit outcomes, each with its own hyperlinked support material, and each with its own additional reading and tutorial task(s). Here is the learning sequence:

Lesson IT4.1: Strategies and Standards

Lesson IT4.2: Possible Systems Architectures

Lesson IT4.3: Documenting Your Choice

So Where To Next?

References

Lesson IT4.1: Strategies and Standards

Key Concept - Strategies vs Tactics: A strategy is "the art of a commander-in-chief; the art of projecting and directing the larger military movements and operations of a campaign. Usually distinguished from tactics, which is the art of handling forces in battle" (O.E.D.). Strategies thus call for foresight and cunning in advance of a battle, whilst tactics require the best possible disposition of your forces on the day itself.

Key Concept - Systems Architectures: A system architecture is a particular arrangement of system assets, both hardware and software, in which configuration it operates in a certain way. For examples, see Lesson 3.

Only when you get immersed in specifying your required functionality do you realise how many ways there actually are to deliver it. You will come across a bewildering array of hardware and software products, and - unless you are very lucky - no single option is going to match all your requirements (not within budget and/or timescale, at least). Fortunately, you do not have a totally free hand in selecting either your hardware platform - the makes and models of your computer and its peripherals - or in deciding your basic system architecture (as defined above), because many of the most delicate decisions will already have been made for you. Specifically, you will be constrained by a number of external factors, as follows (in descending order of importance):

Corporate Vision: These are the things an organisation has decided it is going to value, typically in the interests (a) of customers, (b) of employees, and (c) of good public relations. For good examples, click here, or here, or here.

Corporate Strategy: These are very high-level statements of how your organisation intends going about its business in the coming years, and thereby achieving its corporate vision. These strategies control the flow of investment, and will thus favour developments in some application areas but not others. Corporate strategies are set ultimately by an organisation's CEO (ie. Chief Executive Officer). Here are some examples:

Tesco's decision to roll out Internet shopping cautiously. [A broadly successful strategy.]

Channel 4 Television's decision not to produce any programmes in house (Cooper, 2001). [A broadly successful strategy.]

Marks and Spencer's decision to abandon its buy-British policy. [A possibly self-defeating strategy, given their poor performance in 2000.]

IBM's decision not to concentrate on the personal computer market in the 1980s. [A seriously bad decision, estimated to have cost them $90 billion (sic) in lost sales (Byrne, 1997).]

Information Strategy: These are statements of how information is to be used as a strategic resource in supporting the higher level corporate strategies. This will include identifying what information is owned, how and with whom it is shared, how and by whom it is protected, and how long it is kept. Information strategies are set ultimately by an organisation's CIO (ie. Chief Information Officer) (if it has one), and are intended to be user-led rather than technology-led. Here are some examples:

Channel 4 Television's decision to use its Intranet to deliver the bulk of its training needs by e-learning packages (Cooper, 2001).

Harland and Woolf's decision to introduce business-to-business ("B2B") working "in the medium term" (Computer Weekly, 10th August 2000).

British Aerospace's decision to give high priority to solving its internal knowledge management problems (Computer Weekly, 10th August 2000).

The NHS's decision ("Information for Health", 1998) to give high priority to the electronic patient record (EPR), the electronic health record (EHR), and to online services such as the National Electronic Library for Health (NeLH). [For full details, click here.]

IT Strategy: These are edicts from your IT department instructing you how IT is to be used in delivering the information strategy. IT strategies cover such things as the technology you are allowed to buy, and what suppliers you are allowed to buy it from. They might, for example, disallow purchases of software from companies not selling under UK law because you would not easily be able to sue them if anything went wrong.

Data Standard: These are very low-level statements of what your corporate data is allowed to look like. Thus there will be data standards telling you how big each data field is allowed to be, what is allowed to be in it, and how much spare capacity should be included to allow for natural expansion (as in the recent UK telephone number changes). These standards will be set centrally by an officer known as the data administrator and will apply to all systems, even those - like small departmental systems - about which little is known centrally. It is vital to follow them (a) for the sake of consistent corporate image in the eyes of outsiders, and (b) to ease efficient and error-free communication between systems internally. [The point has already been made elsewhere that most systems have "to interface" in some way or another across subsystem boundaries. Click here to reread the appropriate section.]

When you have completed this part of your research, you need to do two things. Firstly, you should record what you have found out about your organisation's strategies in a short memorandum known as a Strategy Study, and secondly you should carefully archive what you have found out about data standards for use (a) when sizing your system, and (b) at the system specification stage.

LESSON RATIONALE: And why does all this matter? Because your proposed system will only fit "seamlessly" into the organisation as a whole if your strategy study was thorough, and if your data is compatible with all the other systems it is going to have to interface with.

EXERCISES (AND STANDARD STUDY TIMES): Depending on how thoroughly you have been exploring the hyperlinks provided, it has probably taken you less than 30 minutes to read the foregoing text, and now you have to do some real work. Complete the following exercises, taking careful note of the expected study times:
IT4.1.0	Browse the Internet, starting with the keywords <corporate vision>, <corporate strategy>, and <information strategy>, but probing ever more deeply and widely as other potential keywords take your eye. Look to build up a small e-folio of useful general commentary, recent research, and up-and-coming new theories (advertisements for forthcoming conferences are very useful in this respect). Study this information carefully, and you will suddenly find yourself as good at, if not better than, the experts in your organisation. Specialist reference archives are particularly valuable so note their location carefully. [No formal time limit.]
IT4.1.1	Ask your IT department contact for that department's views on having lots of small local systems inputting data into large systems. When was the last time one of these systems (a) submitted unreadable data, or (b) submitted the same data twice? [30 minutes.]
IT4.1.2	What is your organisation's recommended format for name and title? Pick a system with which you are familiar, and find out whether it would be able to cope with an entry for Brigadier-General Archibald Featherstonehaugh-Willoughby, KBE (who will write nasty letters to you if you fail to print his name correctly). [1 hour.]
IT4.1.3	Get your IT department contact to explain (a) the perils of using "freeware", and (b) why it can be better investing in the costly Windows NT/2000 platform rather than the apparently much cheaper Linux operating system. [1 hour.]
IT4.1.4	Ask your IT department contact how they handled the recent lengthening of UK telephone numbers. For a Cardiff number which of the following formats (if any) do they store? 02920416829 02920 416829 029 2041 6829 029-2041-6829 (029)20416829 something else altogether Could their systems cope with adding yet another digit? Could they cope with having two telephone numbers per customer (one static and one mobile)? Do they store an e-mail address? [1 hour.]
Submitting Exercises for Assessment and Feedback (Fee-Paying Clients Only): Simply e-mail your answer(s) for full tutorial feedback. State each conclusion clearly, and briefly explain how you arrived at it. You may do this one exercise at a time, or all at once. Additional questions may then be asked, and additional tasks given as required. [Submit an Exercise] Please cooperate with this student-tutor exchange, because it will eventually form the basis of your individual student progress record. Do not proceed to Lesson IT4.2 until all the tutorial tasks are completed and signed off.

Lesson IT4.2: Possible Systems Architectures

Strategies will not make all your decisions for you, however, and perhaps the largest single decision of all - setting your basic design philosophy - will probably have been left entirely to you. Fortunately, there are only a handful of basic philosophies to choose from, and some of these are easy to exclude. Here are the six major options, plus another about to hit the headlines, more or less in the order you would need to consider them:

Option 1 - Minimum Technology: Your first option is to stay (or perhaps revert to being) uncomputerised, ie. to go for old-fashioned clerical procedures such as pen and paper, supplemented by calculator, photocopier, telephony, and fax. Here are the strengths and weaknesses of this approach:

Strengths	Weaknesses	Verdict
cheap if uses existing spare clerical capacity; potentially excellent control and accuracy	slow and bulky; expensive if involves additional staff; potentially atrocious control and accuracy; potentially ridiculous diversion of skilled professional resource from its primary target	minimum technology solutions are often the best option, but avoid BPR (see below) unless accompanied by an expert, because it has a 70% failure rate (Allen and Fifield, 1999)

Key Concept - Business Process Re-Engineering (BPR): Under this heading we also need to mention the organisational equivalent of major surgery. Rather than trying to computerise your way out of an information bottleneck, you simply do away with that particular business process altogether. You re-engineer the organisation itself. Hammer (1990) describes how the Ford Motor Company, in an attempt to streamline its accounts payable department, found that the bulk of the 400+ staff spent their entire working life sorting out minor aggravations. So Ford refused to automate. They amputated. They simply instructed suppliers not to bother invoicing at all, and started to pay against the initial delivery note. This removed all the minor aggravations. It cost them a few dollars in lost interest because they paid out sooner, but it saved them 300+ jobs. More recent BPR initiatives include:

Leicester Royal Infirmary's "Whole Hospital Re-Engineering"

St Helier NHS Trust's "Patient-Focussed Care"

five UK universities' re-engineered administrative and teaching systems [reviewed in Allen and Fifield, 1999]

Manukau Health's re-engineered rehabilitation service [for case details, click here]

Option 2 - Large Corporate Systems: This is the "made to measure" (or "bespoke") option, and it costs a fortune. As such, it will not be a workable option for a local departmental budget, although it is worth enquiring whether an existing system which does not currently address your needs could be made to do so with a minor enhancement. Here are the strengths and weaknesses of this approach:

Strengths	Weaknesses	Verdict
potentially excellent professional support; tends only to cost in for large departments, high volumes of data, and relatively straightforward processing	cost, cost, cost, cost, and cost [although for an interesting argument that the bespoke option is not always only for the very rich, click here.]	unlikely to be a runner, because there is usually a good reason why your department was left out in the first place - but enquire carefully to establish (a) whether any relevant systems are due to be "rolled out" in your direction in the near future, and (b) whether you can meet your requirements by commissioning an enhancement to one of these systems

Option 3 - "Turnkey" Application Systems: These are "mass-produced" application systems, where the initial cost is borne by many customers. It is software bought "off the peg", and the people who sell it are known as software houses. These systems should be seriously considered and thoroughly investigated, but will only work well if what you want to buy (as set down in your functionality list) is what the sellers have to sell. Turnkey systems may on occasions be obtained for next to nothing in house, from departments who have already managed to solve similar problems to yours. Here are the strengths and weaknesses of this approach:

Strengths	Weaknesses	Verdict
relatively low cost if bought; free or perhaps nominal charge if obtained in house	these systems almost always force you to compromise on functionality; can be costly to upgrade; will probably have non-standard data definitions	needs to be looked into; an in-house solution would be ideal, if available, because you would gets lots of house-specific functionality and house-standard data for little or no outlay - so do lots of ringing around! (Equally, if you are the first to solve a common problem, tell them!)

Option 4 - Bureau and "ASP" Systems: The computer bureau concept goes back at least to the 1960s, and involved buying processing time on other people's mainframes. That approach is now largely obsolete, but the concept of buying in application systems is being resurrected on the Internet by companies known as application service providers (ASPs). Here are the strengths and weaknesses of this approach:

Strengths	Weaknesses	Verdict
relatively low cost (a) to implement, and (b) to replace when obsolete; very fast "time to market"	these systems almost always force you to compromise on functionality; can be costly to upgrade	worth looking into, but watch compatibility and cost

Option 5 - Standalone Microcomputer with "Packaged" Software: Technically, your fifth option is to go for a standalone desktop or laptop microcomputer (ie. for a system which does not talk directly to any other system), but see panel verdict below. Here are the strengths and weaknesses of this approach:

Strengths	Weaknesses	Verdict
cheap; plentiful skills; plentiful packaged software; databases excellent for a mixture of routine and occasional ad hoc data interrogation	standalone, so no e-mail or Internet	cheap and cheerful, but largely obsolete, even for home computing. So you might as well go for an Internet-compatible machine - see next. Beware of heavily discounted kit - standalones are rapidly going out of fashion! Only use database for very light use.
Important Note: Microcomputer database packages are tools, rather than systems. They have no intelligence, and you, the operator, make all the decisions. Databases are particularly difficult to maintain without pre-programmed and fully tested applications. You can program an application system onto a microcomputer, but it calls for quite extensive programming skills.

Option 6 - Networked Microcomputer: Your sixth option is to go for an Internet-compatible desktop or laptop microcomputer. This is very similar to standalone technology, save that the hardware is now linked to the Internet and can run e-mail and web applications. This sort of technology is ideal for general purpose office chores. As for your software, the prime example is the word processing package. Other offerings worthy of note are authoring packages, which do word processing for Internet-destined text, spreadsheets, which help you manage text and numeric arrays, statistics packages, which help you analyse research data, graphics packages, which help you draw pictures, flow diagrams, graphs, pie-charts, etc, and project management packages, which help you produce a number of important management documents and charts. Networked microcomputers may also be used on Intranet systems - see Extended Option 6 below. Here are the strengths and weaknesses of this approach:

Strengths	Weaknesses	Verdict
as Option 5, plus ..... e-mail and network access; professional operational support staff	any standalone applications risk being uncoordinated, which invites constant reinvention of the wheel; only ideal for office applications; potentially atrocious control and accuracy; potentially insecure; databases difficult to set up and need continuous maintenance; potentially litigious	value for money, but needs to be treated as a tool rather than a system (see note below)
Important Note: Microcomputer database packages are tools, rather than systems. They have no intelligence, and you, the operator, make all the decisions. Databases are particularly difficult to maintain without pre-programmed and fully tested applications. You can program an application system onto a microcomputer, but it calls for quite extensive programming skills. Alternatively, you can access ASP application systems via the network.

Option 6 (Extension) - Intranet System: Your final option is to go for a closed corporate network. This looks and feels very like the Internet option, but the local network is private and will allow access to the main corporate systems. Here are the strengths and weaknesses of this approach:

Strengths	Weaknesses	Verdict
cheap if the cabling is already in place and the necessary support staff are already in post; plentiful skills; plentiful packaged software; but now commercially confidential into the bargain; easy access to mainframe and bureau systems	cost of initial set-up and continuing support; otherwise as basic Option 6, but nowhere near as insecure; only works for static workstations or by dial-up from the field (but see next)	an industry standard solution, but well beyond a local budget unless the basics are already in place

Option 7 - Wireless Networks:

COMING SOON - WATCH THIS SPACE.

Having considered the foregoing options, and with interprofessional advice where appropriate, you will now be in a position to complete your strategic decision making. This is what is shown in the following lesson.

LESSON RATIONALE: And why does all this matter? Because not all options are going to cost in for a small departmental system, and because it is good practice, when dealing with expensive but imperfect products in an area you know little about, to take every opportunity for interprofessional enquiry and advice.

EXERCISES (AND STANDARD STUDY TIMES): Depending on how thoroughly you have been exploring the hyperlinks provided, it has probably taken you less than 30 minutes to read the foregoing text, and now you have to do some real work. Complete the following exercises, taking careful note of the expected study times:
IT4.2.0	Browse the Internet, starting with the keywords <turnkey>, <ASP>, and <Intranet>, but probing ever more deeply and widely as other potential keywords take your eye. Look to build up a small e-folio of useful general commentary, recent research, and up-and-coming new theories (advertisements for forthcoming conferences are very useful in this respect). Study this information carefully, and you will suddenly find yourself as good at, if not better than, the experts in your organisation. Specialist reference archives are particularly valuable so note their location carefully. [No formal time limit.]
IT4.2.1	You have decided to use a standalone database system on a networked PC to computerise your professional records. Consult a major PC retailer, and see how many hardware products meet your organisation's IT strategies. Collect specification sheets and prices for the platform you would purchase is you had (a) £5000 to spend, or (b) £2000 to spend. [This will require 1 or 2 hours on site at said retailer.]
IT4.2.2	Get your IT department contact to explain the pros and cons of purchasing commercial turnkey systems (take your functionality list with you). You might well find that one of your IT strategies is to throw relatively cheap turnkey systems at as many problems as possible in the hope that some will stick. Why might this strategy ultimately raise more problems than it solves? Why might it ultimately solve more than it raises? What is "stiffing"? [2 hour.]
IT4.2.3	Research the market for ready-to-run systems in your professional area. Select one of these systems and answer the following questions [a day or two's research]: Name of system, the software house which produced it, what hardware it will run on, what operating system it will run on, how much RAM it needs, how much filestore it needs, how many simultaneous users it will support, how much it all costs (i) up front, and (ii) each year, what helpdesk facilities are on offer, and how reliable is (i) the kit, and (ii) the application system.
Submitting Exercises for Assessment and Feedback (Fee-Paying Clients Only): Simply e-mail your answer(s) for full tutorial feedback. State each conclusion clearly, and briefly explain how you arrived at it. You may do this one exercise at a time, or all at once. Additional questions may then be asked, and additional tasks given as required. [Submit an Exercise] Please cooperate with this student-tutor exchange, because it will eventually form the basis of your individual student progress record. Do not proceed to Lesson 4.3 until all the tutorial tasks are completed and signed off.

Lesson IT4.3: Documenting Your Choice

At the end of your design investigations, you need to narrow down your optional systems architectures to the major "runners" only. Each of these will have been appraised technically by your IT contact, and costed reasonably accurately from the product literature you will have accumulated. Your final tasks at this stage are therefore (a) to select your shortlist, and (b) to put that decision on record. Here are some of the questions you need to ask yourself during this decision making.

Decision Flowchart for Shortlisting Systems Architectures

[decision chart]

Q1. Is your business process computerisable in the first place? If NO, then consider the minimum technology route. If YES, then go to Q2.

Q2. Do you really know what functionality you want and how best it can be provided technically? If NO, then take the prototyping route (see below - always an excellent solution). If YES, then go to Q3.

Q3. Can you beg, steal, or borrow a ready-to-run system in house? If YES, then do so. If NO, then go to Q4.

Q4. Is there a readily enhanceable major system nearby? If YES, then take the system enhancement route. If NO, then go to Q5.

Q5. Can you afford to commission a new major system from scratch? If YES, then consider the bespoke system option. If NO, then go to Q6.

Q6. If your IT strategies permit their use, are there turnkey systems which provide the functionality you need at a price you can afford? If YES, then consider the turnkey system option. If NO, then go to Q7.

Q7. If your IT strategies permit their use, are there ASP systems which provide the functionality you need at a price you can afford? If YES, then consider them. If NO, then e-mail for a personalised consultation.

In practice, the most useful questions are Q1 and Q2. The rationale for Q1 is that many processes are still impossible to computerise, and the rationale for Q2 is that it is actually a good thing NOT to know what you really want out of a system. This is because there is a tried and tested way of improving your knowledge. This is to commission a system "in miniature", which can be played around with "on the cheap" until a clearer idea of the application area emerges. This approach is known as prototyping, and prototyping makes for very cost-effective use of IT, because it prevents guesswork, waffle, and (usually disastrous) leaps in the dark. Indeed, most billion-pound IT disasters [click here] could easily have been avoided by £50,000 worth of prototyping!

Key Concept - Prototyping: Prototyping is the process of learning by "hands-on" experience how to introduce computerisation into a given application area or professionalism. This hands-on experience is gained on systems "in miniature" until the necessary understanding has built up to allow specification of a larger system. Prototyping requires a very special type of development environment, specifically one in which system change is encouraged and supported.

This is how you might phrase the corresponding design statement (note that having a networked microcomputer does not prevent you from running standalone applications):

"Proposal: To prototype a standalone database on a networked PC. Agree database record layout and experiment with applications and machine-user dialogues during a two year trial period, and then reconsider."

And here is a specimen design statement for the system enhancement route shown above:

"Proposal: To submit a system enhancement request (SER) against the [insert the name of the computer system to be enhanced] computer system, requesting it to extend its functionality to include [summarise the functionality you want it to provide]"

LESSON RATIONALE: As Lesson 2.

EXERCISES (AND STANDARD STUDY TIMES): Depending on how thoroughly you have been exploring the hyperlinks provided, it has probably taken you less than 30 minutes to read the foregoing text, and now you have to do some real work. Complete the following exercises, taking careful note of the expected study times:
IT4.3.0	Browse the Internet, starting with the keyword <prototyping>, but probing ever more deeply and widely as other potential keywords take your eye. Look to build up a small e-folio of useful general commentary, recent research, and up-and-coming new theories (advertisements for forthcoming conferences are very useful in this respect). Study this information carefully, and you will suddenly find yourself as good at, if not better than, the experts in your organisation. Specialist reference archives are particularly valuable so note their location carefully. [No formal time limit.]
Submitting Exercises for Assessment and Feedback (Fee-Paying Clients Only): Simply e-mail your answer(s) for full tutorial feedback. State each conclusion clearly, and briefly explain how you arrived at it. You may do this one exercise at a time, or all at once. Additional questions may then be asked, and additional tasks given as required. [Submit an Exercise] Please cooperate with this student-tutor exchange, because it will eventually form the basis of your individual student progress record. Do not proceed until all the tutorial tasks are completed and signed off.

So Where To Next?

If you have got to this point by mistake, click to return as appropriate:

Restart Lesson IT4.1

Restart Lesson IT4.2

Restart Lesson IT4.3

Otherwise, congratulations!! You have reached the end of Unit IT4 of the INFORMATICS programme. Click to proceed to Unit IT5, and good luck!

References

Cooper, C. (2001). Connect four. People Management, 8th February 2001, 42-44.

Hammer, M. (1990). Re-engineering work: Don't automate, obliterate. Harvard Business Review, July-August 1990, 104-112.