Rapid application Development (RAD) Technique
June 1, 2011
General RAD Concepts
Background
RAD refers to development lifecycle designed to give much faster development and high quality results than the traditional lifecycle.
It is designed to take maximum advantage of powerful development tools that have evolved in record years.
Need to apply RAD Technique
-Speeding up of development process which is very important in today’s business environment.
-To speedily create and amend info systems in organization in order to support the continuous changing business environment
NB: There is need to harness the characteristics of RAD so that most flexible and quality systems are delivered in the shortest time scale possible.
Characteristics of RAD
-Use of evolutionary prototyping techniques operating in an environment of high delivery time scales.
-To focus upon the identification of important users and involving them in workshops at early stages of development.
-Obtaining commitment from the business users
-The use of CASE integrated development environment
Concepts of RAD
RAD was traditionally viewed as quick fix approach but not a technique to deliver quality systems.
It was seen as a way of setting up a system quickly using a 4GL tools and DBMS products without the quality controls associated with other development projects.
The two common approaches used are:
1) The work of James Martin (1991)
Context of Information Engineering
2) Dynamic System Development Method (DSDM)
Is a framework and standards of RAD formed by a consortium of UK companies in January 1994.
Phases of RAD
a) Requirement Analysis
This concerns the definition of requirements. The techniques used in this phase are:
i. Joint Requirements Planning (JRP)
ii. Joint Application Development (JAD)
Both of these techniques are based on workshops or structured meetings.
i. Joint Requirements Planning (JRP)
The role of JRP is to identify the high level management requirements of the system at a strategic level. The participants are senior managers who have visions and understanding of the overall objective of the system and how it can contribute to the goals and strategies of the organization.
The workshops may be used to help determine those goals when they are not well understood.
JRP is a creative workshop that helps to:
Identify and create commitment to the goals of the system .
Identify priorities
Eliminate unnecessary functions
The difference between JRP & JAD is that different people are involved.
In JRP the participants need to have a contribution of overall business knowledge and specific knowledge about the proposed system with its requirements.
They also need to have the necessary authority and seniority to be able to make decisions and commitments.
It is suggested that if the right people are not available without referring to their seniors negates the RAD objectives which is to get requirements identified agreed in the shortest time possible.
b) User design
The main technique used in this phase is JAD in reality, user design is both analysis and design. Thus the JRP workshops may be combined with JAD in situations where the overall requirements are well established.
Normally, however JAD would follow on from JRP
c) Construction Phase
The construction phase in RAD concerns taking of the user design through detailed design and code generation.This phase is carried out by the IS professionals using CASE tools.
The construction highly depends on the uses of info engineering based case tools and prototyping.
The prototype are reviewed by the key users for approval where they are not approved, the requested changes are effected through series of interaction which are achieved quickly and testing enabled by use of CASE tools and prototyping.
Construction is performed by small teams of 3 to 4 experts in the use of CASE tools. The teams are kept small so as to reduce the number of interfaces and interactions between people in the teams.
They are required to work quickly, making maximum possible use of re-usable designs already in existence.
Large teams of developers would require large communication network and a number of communication resulting in low productivity as in the traditional development.
There should be a developer for each part of the system so as to reduce the number of potential interactions with other developers.
Using this approach the system can be viewed as quickly as 4-6 weeks and progressively refined and integrated with other aspects developed by other team members.
Once the detailed designs are agreed upon the code generated using the CASE tool and then the system is tested and approved.
All associated documentation is then produced and database optimization is then performed.
d) Cut-over:
This is the final phase that involves testing and the use of realistic data in operational situations. The users are trained on the system. The organization changes.
Implied by the system is implemented. The cut-over is finally effected by running the old and the new system in particular until the new system has proved itself. The old system is then phased out.
Dynamic System Development Method (DSDM)
June 1, 2011
Background
DSDM is a set of standards and framework for controls for building and maintaining systems, which meet tight time constraints and provide a recipe for repeatable RAD success.
It was initially defined by a consortium of UK RAD users and suppliers. The consortium consisted of many large organizations that had used the concept of RAD and now wanted to develop a generic framework that could be used.
The initial framework was approved and version one was published in Feb 95. Version 1 of DSDM consisted of
1) 13 Principles
2) Project Management
3) Team Structures
4) Prototyping
Feedback from the early users of DSDM led to the release of subsequent versions. In December 1995 version 2 was published. In version 2 the 13 principles were reduced to 9 principles.
In October 1997 version 3 was published.
These developments reflected the increasing use of DSDM in business process change projects.
Since then DSDM has been used successfully by organizations in public and private sectors.
Applications built using DSDM approach address the current and imminent needs for the business rather than the traditional approach of attacking all the perceived possibilities.
The resulting computer system is, therefore, expected to be a better fit in the true business needs, easier to test and more likely to be accepted to the users working practices.
DSDM provides a holistic approach to software development in a RAD project environment.
Many software development methods focus purely on one activity even as analysis and design or project management.
DSDM provides a development life cycle supported by all the necessary controls.
Overview
There are 4 philosophies behind the development of DSDM namely:
a) Mode of Development:
Development should be a team effort consisting of the users and IT professionals with the following roles
Users: Provide the good understanding of the business requirements
IT professionals: Provide the technical know-how
b) Quality Demands
High development quality is demanded in order for it to suit the users needs as well as technical competence and robustness.
c) Deadline for Delivery
Development can be delivered in incremental stages. It is better to deliver part of the development in time rather than everything way past the acceptable deadline.
In deed, a fundamental assumption of DSDM is that noting is built perfectly for the first time, but that a usable and useful 80% of the proposed system can be produced in 20% of the time it would take to produce the total system.
d) Resources Requirement:
It has to be accepted that resources will be spent if development of IS of value to the organization is to be realized in time.
It should be noted that DSDM is viewed as a framework of controls for the development of IT systems to tight time scales and a guidance of how to apply the controls and concepts of RAD rather than the view of method/methodology.
DSDM is independent of any particular set of tools and techniques and could be used by object oriented and structured analysis and design approaches in environment ranging from the individual PC to global distributed system.
DSDM defines set of process and products at a high level to give flexibility to the approach.
Developers may choose any technique, but conform to the DSDM guidelines and controls.
In a RAD environment DSDM addresses the following. These factors are:
- Project management - Testing
- Estimation - Quality Assurance
- Time boxing - Team structures
- Prototyping - Tools
- Configuration Management - Risk management
SUMMARY:
DSDM: Note:
Tools and techniques: The tools and techniques of DSDM should enable:
- Rapid development
- Users to be involved
- Support of interactive development
- The building of acceptable user interface
- Support of …… and provide good documentations.
People and Teams:
- Involve users all through
- Empower teams
- Establish key roles
Management:
- Plan for interactive delivery ie. Deliver things in bits
- Plant for continuous testing
- Plan for constant review of prototypes and progress.
Time-boxing:
- is a technique to make RAD more measurable and controllable.
Certification and Accreditation Process:Assessing risk
October 22, 2010
Risk management is all about mitigating risk to levels which an organization considers acceptable. It involves a detailed examination of vulnerabilities/ risks and prioritizing these risks
Risk assessment involves identification of assets and begins with defining the system i.e. what kind of system it is? The scope of the risk assessment defines whether risk assessment will be done on general support system (GSS), major applications, business unit process etc. after defining the scope of risk assessment, the assets such as hardware, software, data facilities and people are identified and documented.
Threat identification follows and it involves identifying and categorizing the threats. It also involves identifying the likelihood of occurrence of the threat and its impact. Vulnerability assessment is done and it involves identifying actual vulnerabilities to the assets. It’s done by assessing the available security controls against minimum security baseline and then against existing controls plus identified threats. Any control that doesn’t adequately protect against the identified threats is classified as vulnerability. The results of the risk assessment are classified are documented and put in a report. Management should use the report to select controls.
Business Process reengineering BPR
August 5, 2008
BPR is a form of organizational improvement. It aims to improve a business through restructuring of processes. BPR is given force by the thinking that old ways of organizing work are no longer appropriate for a competitive business environment. The ultimate aim of re-engineering processes to achieve better quality, service and innovativeness. The radical restructuring entailed in BPR is risky and uncertain.
Theoretical Foundations of BPR:
For hundreds of years, commercial activity has been based on the Adam Smith principle of Division of Labor. Division of labor encourages specialization and thereby leads to improved productivity.
The classical enterprise also exhibits the concepts of:
- Hierarchical control:- the classical layers of management
- Mass production of largely uniform goods/services
An organization based on these principles is successful in a stable market environment, characterized by growing demand for uniform goods/services. In a changed market environment characterized by sever competition, globalization, more demanding customers, smaller profit margins etc, the classical organizational models are less and less appropriate. BPR provides one alternative to the old methods of organizing business processes. The goals of BPR can be started in expanded form as either cost objectives or service objectives.
Cost Objectives:
- Reducing stocks: New materials or Intermediate goods
- Economies of scale in procurement
- Reduced staff costs (administrative costs)
- Competitive pricing of goods/services
Service Objectives:
- More reliable delivery system
- Stock availability
- Good after sales service
- Quick Response/adaptation to market changes
- Reduced product development lifecycle
Qualities of Re-engineered Processes:
- Several jobs are combined into one. This implies a reversal of the Adam Smith principle of division of labor and function. Workers make decisions, actual work and decision making are integrated.
- Processes are reorganized so that tasks are done in the most sensible/logical order.
- Checks and controls are reduced. The checks and controls are reduced to the minimum acceptable level. The checks and controls are also deferred.
- Reconciliation is minimized.
- A case manager is appointed to oversee the re-engineering process.
- Hybrid processes that combine centralization and decentralization by use of communication technology are often adopted.
- Processes have multiple versions (polymorphic) – the process is re-designed to include capabilities to deal with custom orders.
Contribution/Role of IT in BPR:
- IT is all essential enable of BPR; it enables processes to be re-engineered.
- It supports the re-engineered process
- Leading edge technology products can be particularly useful in process innovation. They can even lead the innovation process.
- IT also facilitates process integration.
- It has been argued that the most effective contribution of IT in business redesign is to enable an enterprise to do things that it was not doing before – extending the capabilities of the enterprise.
Candidates for BPR:
In theory, any business process can be subject to BPR; but in practice, certain processes can benefit more from BPR than others. Such processes have the following qualities
Dysfunction: The process is visibly out of order, it is problematic. Dysfunction in a process occurs when the process is slow (frustratingly slow), occasional complaints, generates errors etc.
Importance: Important processes that have a prominent place in the value chain. They contribute directly to the delivery of goods and services to the end consumer.
Feasible: From the managers stand point the BPR project is technically, economically and socially feasible/viable. Processes that require high capital input, or enjoy limited management support are less feasible for BPR.
What causes BPR projects to fail? (Pitfalls in BPR):
- Inadequate funding
- Insufficient management commitment/support
- Poor project leaders
- Inadequate feasibility evaluation
- Resistance to process change
- Failure to focus on most process re-design and dwelling on improving the existing process.
- Quitting too early or declaring victory too soon.
Re-engineering computer system:
At a minimum a computer system comprises of an ordered collection of hardware, software, and data resources. Computer systems are the basis for automated information system.
- Re-engineering computer systems means examining, rethinking and re-implementing such systems in a new form.
- The process is usually carried out on legacy options, re-implementing them in a more modern form.
- Re-engineering computer systems can be seen as a management response to the challenge of keeping old systems alive within a changing environment.
Merits
- The useful life of a system is increased
- The business value of such a system also increases
- Future maintenance costs are reduced
- The morale of maintenance staff may improve; because they know they are working in a modern system i.e. the systems become more maintainable.
Steps for BPR
- Identify process for innovations
- Manage business
- Manage people and work
- Identify change levels ( technology etc)
- Develop process vision – what you want to process must fit with the strategic direction of the organization (IS)
- Understand existing processes – study current process and understand necessary changes
- Design and prototype new process/create design of new process.
Approaches to re-engineering computer systems:
When a system is re-engineered any of the following changes may occur:
- It may be placed in a distributed platform.
- It will usually be re-documented
- The data may be migrated to a new database platform
- The code may be restricted
- The code may be written in a different language
Automatic Source Code Conversion:
This entails the use of software tools to convert source code in a given language.
- to code in a newer version e.g Cobol 74’ to Cobol 90’
- to code in a different language e.g Cobol 74’ to Oracle
The software tools cannot achieve 100% conversion and hence has to be supplemented with manual conversion.
Automated Program Restructuring
When code is maintained over an extended period, its structure and hence its efficiency, deteriorate. Indeed, the more a software product has been maintained, the more it costs to maintain it in future. When the program is re-structured:
- irreconcilable code is detected and removed
- complex control structures are simplified
- program modularity is enhanced
Use of software tools may not be fully effective. Manual rewriting of code may still be applied.
Automated program and Data Restructuring:
When the existing data structures are re-structured then even the programs that process the data have to be reviewed. When data is restructured:
- The overall model may be re-organized into one database.
- Data in a relational model may be modified to suit the needs of a different relational DBMS.
Re-engineering or Re-developing?
Systems targeted for re-engineering have 2 qualities
- They are heavily/regularly used
- They are currently being maintained a lot
Re-engineering usually has two main merits over re-developing. These are:
- Lower costs: re-engineering costs about ¼ of redeveloping
- Reduced risk: lower likelihood of making mistakes.
When deciding whether to re-engineer or to redevelop you may consider such issues as:
- budget provisions or costs constraints
- current state of the old system; the old system may be so old and messy that it may not be susceptible to re-engineering
- Time limitations: re-engineering is likely to be quicker than to redevelop
- Scope i.e. system scope; if the scope of the existing system is to be excluded substantially then it may be more practical to redesign and re-implement the system instead of re-engineering it.
- Perceived risk level; Risk arises from the combined effect of many factors. If the perceived project risk is high then it might be safer to re-engineer the system than to redevelop it.
Link between reengineering of computer systems and BPR:
Computer systems are usually embodied within business processes/systems such as accounts receivable, production planning, marketing and distribution, human resources etc. When such process/systems are re-engineered, then the supporting technology infrastructure also needs to be reviewed.
The overall aim of reengineering a computer system should be to re-align it with the existing business goals. The goals of a BPR project require an altered IT infrastructure then the existing infrastructure should be reengineered or re-developed.
System development methodology
August 4, 2008
“A methodology” is a recommended collection of philosophies, procedures, rules, techniques, phases, tools, documentation, management and training for developers of IS.
Objectives of Methodology
-
To capture, record and document accurately, the user needs.
-
To monitor the project and report on progress (project management ability)
-
To facilitate the development of quality system within the set time and set budget
-
To facilitate proper documentation of both project process and the project deliverables, assisting in future maintenance.
-
To facilitate at an early stage the mechanics of change control.
-
To facilitate the delivery of system that are liked by the end user.
-
Complete coverage of all the development activities involved in system development.
-
Simplicity: The tools, techniques e.t.c. should be easy to use.
-
Validation of the designs:- the methodology should conclude a mechanism for reviewing its own results.
-
Separation of analysis from design, there should be distinct focus on user need, quite separate from implementation needs.
A methodology can be said to have various features. These features can be categorized into technical model and managerial model.
A methodology needs to have a technical model. This model includes features like the tools, tools which will help the developers in the process of developing an Information System. These tools help in every phase or sub phase involved in the methodology. e.g. CASE tools, project management tools, Drawing tools , Data dictionary e.t.c.
A methodology also needs to have a technique. A methodology can have many techniques, Techniques helps to verify and expound on the methodology, thus they enable the phase and subphase of methodology to be carried out according to the methodology’s principle.
Technique act as guides of methodology’s phase. Technique address different parts (phases) of a methodology.
Techniques also enable easy understanding of what the methodology requires e.g. root pictures, conceptual model, DFD, Decision trees/tables, Entity Life Cycle, Structured diagrams, normalization e.t.c.
A methodology also needs to have a philosophy, in that it needs to have the underlying theories and assumptions that the authors of the methodology believes in. This feature helps to shape and guide the development of an Information System. It also enable the understanding of the methodology.
A methodology also has a managerial model that has a feature of a methodology. This feature is that of the development structure, in that a methodology needs to have a development structure that;
-
Identifies the phases, subphases, steps and tasks to be done in the methodology.
-
Identifies the outputs to be produced and under which circumstances they should be produced.
-
Constraints to be applied and people to be involved. This feature provides for the development process to be really managed and controlled.
Initially in the early 60s there was no appreciation for a methodology. Application systems were developed without the aid of an explicit Information System development methodology.
Also there was a growing appreciation of analysis and design parts of the system development and therefore the role there was increased demand for the role of an analyst and programmer.
There was also a realization that as organization grow in size and complexity. It was desirable to move away from one-off solution to a more integrated Information System.
There was also appreciation of an accepted methodology for the development of an I.S.
What is the rationale for writing a methodology
The rationale for writing a methodology are:
The methodology should improve the end product of a development process i.e. a better I.S.
A better development process: In that the methodology should provide improved management and project control so that the organization can gain from the benefits that accrue from a tightly controlled development process.
Selecting/Adopting
Theoretically speaking, the best methodology is the one that is best suited to the project work at hand. In practice, the best methodology may be the one that the designer understands well.
In some cases, the right methodology is the one that has been recommended within the organization’s standards.
Common Approaches
Adhoc: No formal recognition is given to methodologies
Contingency Approach: We use different methodologies, depending on the nature of the project.
Prototyping / Evolutionary Development: We use it in those context where the user needs are unclear, the business area is unfamiliar, the level of risk is high e.t.c.
Adavantages of a methodology
-
Increased user involvement translating to a more likeable system.
-
Prototyping has the inherent capacity for accommodating risks.
-
Quicker systems Development.
-
Superior User Interface.
-
Missing functions/features can be detected early.
Disadvantages of a methodology
-
Poor documentation.
-
Confusion between the prototype and the real system.
-
Project Management is difficult.
-
It is difficult to draw up a prototype contract.
-
As a consequence of poor documentation system maintenance may be difficult.
PRINCE (Projects IN Controlled Environments)
August 4, 2008
This project command structure may perhaps not be widely applied but it brings out the nature of the roles we tend to encounter in most systems development projects.
Steering Committee
This committee may go under different titles, but its main role is to guide expenditure on Information systems (IS) with a view to ensuring that such expenditure is in line with the business goals. It is the steering committee’s responsibility to ensure that projects concentrate on solving the business problem. Such a committee may undertake the following duties:
-
Formulating the IS strategy/plan
-
Prioritization of projects
-
Setting terms of reference for individual projects
-
Project progress control
-
Quality and acceptance testing
-
Project funding
Project executive/Sponsor
-
Taking care of project funding and organizing for the release of funds that have been allocated to the project.
-
Project progress control, perhaps in conjunction with the steering committee if one exists.
-
Justification of the project to the management body in charge.
-
Specifying the minimum requirements that the projects must meet if it is to achieve its business objectives.
-
Provide high level support as a champion for the projects
-
Keeping the project board or higher management informed of progress.
Senior User
-
Assisting in system requirements definition
-
Assisting the project team with quality review of the system interfaces.
-
Voicing the concerns of the perceived implications of a proposed system.
Project Manager/Leader
-
Supervision and motivation of the project team
-
Allocation of duties
-
Progress control on a day to day basis
-
Reporting on project progress to the project sponsor or senior management
-
Recommend termination of the project to the sponsor if necessary
-
Select and manage sub-contractors
Quality Control
This role may be served by a quality control team, quality control supervisor or some other person.
-
Setting the quality standards
-
Suggesting quality review techniques
-
Undertaking the quality review and making the appropriate recommendations
Technical roles
Depending on the project any or all of the following technical roles may be applied:
-
Business/System Analyst
-
Application programmers
-
System programmers
-
Analyst programmers
-
Telecoms engineers
-
Designers
-
Network technicians
-
Secretarial support staff
-
Data entry personnel
Analyst/programmer role
This role has become prevalent in the last 15 years and is the result of a number of forces/pressures. An analyst programmer is in charge of both system analysis and programming.
Some of the factors contributing to the increased popularity of this role are as follows:
-
A desire to reduce communication problems in system development: in the classical approach an analyst prepares a specification which a programmer subsequently applies a program coding, there is always a chance of communication breakdown between the two parties.
-
With the increased use of IT, even small enterprises are investing in the area however the system development workloads tend to be small and more attention is devoted to maintenance of existing system. It is therefore viable to have a limited number of personnel who can carry out both system analysis and programming.
-
Desire for increased productivity/efficiency: When a programmer implements a design specification that he wrote himself he may be able to do so quickly because no time is wasted in trying to understand the specification. The system is therefore implemented sooner.
-
Changes in a system development approaches, with the increased use of object oriented system development, it appears reasonable that the analysis and programming work is carried out by one person or the same group of people.
NB: This role appear to be quite popular even with the large organization indicating that the arrangement may be working well.
A person designated as a programmer analyst is likely to acquire a broader range of skills on the job with a positive effect on his career progression. However when mistakes are done there is less opportunity for detecting and correcting them. It is also likely there will be reduced rigor in problem analysis with adverse effect on overall system quality.
Object oriented technology
August 4, 2008
Emergence of Object Technology
This is essentially a software (as opposed to hardware) technology. It may be seen to be a programming design, database design or just a system development methodology. This technology is generally seen to represent a new and different system development paradigm/framework
In a way, the emergence of object oriented databases technology represents an effort to address the limitation of the popular relational model.
As a programming paradigm object oriented programming represents an attempt to radically improve on the existing structured programming practices. This technology is an entity that encapsulates both state and behaviour i.e. data, methods and processes.
Under this technology, systems are developed by or through modeling objects i.e. defining the objects, defining their states and behaviour, their interactions, classifications e.t.c.
The technology uses specialized environments; programming languages and database systems with object oriented support.
Advantages of the object technology
-
High potential for reuse i.e. objects are reusable components. This may be beneficial in that systems can be constructed quickly and cheaply.
-
Reduced maintenance load because well defined objects tend to be stable than conventional code and data tables.
-
object oriented databases tend to support higher quality data. Constraints can be more rigorous. This approach produces normalized models.
-
object oriented databases provide better performances, quicker access to data.
-
Ability to model/design advance databases systems, modeling of sounds, images in addition to text, modeling of complex inter-relatioships e.g CAD, CASE, multimedia systems e.t.c.
Why is the technology not so widely applied:
-
There is a time lag between the development of any new technology and its widespread use. People take time to adopt.
-
Object modeling seems to be conceptually more complex than its predecessors.
-
Their credit affect people who have the prerequisite skills and knowledge to steer the organization transition to this technology.
-
There is a lot of investment currently on relational DBMS and the cost of transition to object oriented will be very high
-
The relevant model is capable of handling most of the basic /conventional data processing need, thus most organisations are still benefiting from the current DBMS and thus the pressure to move to object technology is therefore minimized
-
Current database system have limited support for object technology which might be adequate for some business application.
Data Warehouse
August 4, 2008
Data Warehousing
Data warehousing represents an attempt to turn coporate data into a source of knowledge. A data warehouse has the principal aim of providing information that is truly useful for strategic decisions making. Information that constitutes a summarized and objective view of all areas of the enterprise.
A Data warehouse is a corporate decision support resource. It is a database that brings together data from diverse sources making it serve tactical/strategic decision needs.
One definition cites a warehouse as a support oriented, integrated, time variant and non-volatile collection of data in support of mangement’s decision making process.
Definition Quality of a Data Warehouse
Subject Oriented: i.e. data is organized along the lines of the key business entities e.g. suppliers, customers, stock e.t.c.
Integrated: the Data is from different subjects, sources and applications. It is held in such a way that it can all be applied collectively as one source
Qualities of Data
-
Time Variant; the data pertains to both current and past operations. The data occurs in layers parameterized by time.
-
Non-Volatile: the data is kept for a prolonged period of time without being changed or destroyed. However old data is stored in a more summarized form.
-
Specifically supports top level decision making.
-
Transaction levels are relatively low.
-
Applied at random intervals in a non-deterministic way.
Structure /Components of a Data Warehouse
-
Sources of operational Data
-
-
Old manufacture databases systems (corporate db systems)
Departmental Data (in databases or old filing systems)
External sources e.g. commercial data firms, internet etc
-
-
-
Load Manager (Front end component): this captures and prepares data, placing it in the data warehouses.
-
Warehouse Manager: This tool manages the data inside the data warehouse i.e. it does refining, back up e.t.c.
-
Query Manager (Back end component): Receives queries, schedules them and directs them to the correct data tables.
-
End user access tools: Used by the end user to place queries or otherwise process the data in a data ware house e.g. querry /reporting tools, data mining tools, online analytical processing tools.
-
Current data i.e. Data in the warehouse that pertains to recent operations. This is usually detailed data.
-
Summarized data: Data that pertains to past operations, retained in lightly or highly summarized form.
-
Archive data: old data images of the warehouse retained fort archive purposes.
Advantages of Data Warehousing
-
Very useful for trend analysis (assessing progress)
-
Improved quality of senior management decisions: good decisions often translate into better strategic advantage.
-
Great potential for competitive advantage in that analysis of the data warehouse may reveal patterns or trends that were previously unknown thus managers can capitalize on this information for competitive posturing.
-
High returns on investment
-
Improved managerial control because the manager has a broader and deeper weight into all areas of the enterprise which enables them to control the enterprise more effectively.
Disadvantages of Data Warehousing
-
Projects have a long time frame: the longer a project takes the more risky it becomes.
-
Some of the required data may be missing from operational systems; the data gaps presents a design challenge.
-
Other problems in the operational systems: if there is a problem with the system or operational system this problem may be transferred to the warehouse.
-
Data warehouse systems are high maintenance systems.
-
Underestimation of the data loading needs.
-
Need for large storage facilities: storage needs may be in the order of multiple petabytes.
-
Increased end user demands: When the warehouse is installed user requests for assistance and /or information may increase instead of reducing.
-
Data ownership; the data in the warehouse is a trully shared resource thus lack of data ownership.
-
Data homogenization: The data in the warehouse may infact not serve the intended purpose.
Data Marts
This is a small-scale data warehouse, specifically intended for departmental/divisional use.
The data mart may be a logical unit of the corporate data warehouse or it may be an independent resource.
The emergence of Data marts is a response to the challenges associated with the design and operation of enterprise wide data warehouses.
A Data mart is smaller and thus easier, cheaper and quicker to develop.
A data mart enables us to enjoy the benefits of a data warehouse, but on a smaller scale.
Critical Success Factors (CSF)
June 28, 2008
The technique suggests that strategic information requirements can be uncovered by a 3 stage process.
Firstly the identification of a number of critical success factors (CSF).
CSFs are a handful of things within someone’s job that must go right for the organization to flourish. They are the factors that the manager wishes to keep a constant eye on.
Secondly, they pinpoint critical decisions that need to be made.
The determination of the information required to support these decisions
Example:
CSF: Minimize length of time a part is kept in stock
KD: It might decide what quantities must be ordered
IR: it would need order on demand (rate of sale)
Meeting this CSF ensures that the investment in stock is kept low and that part reach dealers quickly. As this examples shows it is necessary to be clear about business objectives before embarking on CSF Analysis. The process of CSF Analysis allows managers, initially senior ones to articulate the needs in terms of their information management control that is absolutely essential to them.
These needs are influenced by factors such as:
- The industry within which the firm operates
- The environmental factors such as local politics and economic situations
- The firm’s industry position
- The Manager’s position in the management hierarchy.
Prior to the use of CSF there was a rift between the consumers of information i.e. user management and the providers of information i.e. information systems. So CSF can give some guidance on needs in such a way that the effect of the rift is minimized.
CSF must be:
- Intelligent to senior managers
- Intelligent to IS/IT Managers
- Possible to act on (capable of implementation)
CSF Analysis can be applied lower down in the management structure but it gets more and more difficult to articulate as we move down the hierarchy. However, it is generally useful to use several management levels in order to validate the CSF and get a broader picture. Below is an example of the tactical level.
CSF:
- Effective Management control of people/staff
KDs :
- Setting performance standards
- Specification of training needs
- Determination of whether or not to introduce overtime
IR
- Performance reporting
- Budget Allocation
- Exception reports
Challenges of CSF:
- The analysis needs very skilled and very perceptive interviewers to do the abstracting of CSF from senior manager.
- The more removed from the management apex a specific manager is the harder it is to apply CSF analysis. Many managers who are not already involved in strategic planning find CSF analysis too abstract.
- It is usually impossible to build a true picture of the organization’s information requirements using only CSFs.
- The decisions resulting from CSF analysis may ignore any resource constraints, surrounding their realization.
SWOT ANALYSIS and IT
June 28, 2008
b) Are there gaps/opportunities we can go for?
c) Are there dangers/threats we need protection from?
d) Are we strong in the right way to exploit the opportunity where one exists?
SWOT ANALYSIS AND INFORMATION SYSTEMS
With the particular reference to information systems a SWOT Analysis may address such issues as:
Approach to Information systems:
Whether the organization seeks to lead others or just float with the tide? Does the organization see its information systems as a necessary evil, a scarce resource or a transforming aid?
Use of Information Systems
Are there number of systems which are of poor quality i.e. not easy to use? Systems that are management oriented rather than task based?
Delivery of Information Services:
What is the role of users and user management systems development and operation? What proportion of corporate resources is tied in system maintenance? What system development tools and techniques are in use? What is the quality of technical support available?
Data availability and Management:
What is the degree of data redundancy in the application systems? Is there availability of common data across various processing applications? The quality of data management platform (DBMS)
Having become aware of the potential effect of information systems in an enterprise, we can make further use of SWOT techniques
Weigh up the risks associated with each possible decision
Possible Responses on the Basis of SWOT Analysis:
When both opportunities and strengths are present then the organization is in a position to attack its competitors through the use of information systems with a good prospect of success.
Conversely when threats are faced where there are weak capabilities then the organization must take steps to protect itself from its vulnerability to attacks from its competitors.
When there is value adding opportunities for information systems, but the organization finds itself with weak information systems capabilities then they should beware of following this up since they are less assured of success than others in their sector with more adequate information systems.
Should the organization find itself having strong information resources alongside threatening situations, it should explore avenues to both maintain that quality against the opening up of opportunities and to identify overlooked potential.
