Information Vision and Architecture

Report
Information Vision and
Architecture
IS vision
• The development of an overall management
system for information technology for an
organization is not complete without a technical
and managerial framework for future decisions
that are business driven
• Information technology vision and architectıre
is a shared understanding on how computer
technology has to be used and managed in the
business
Information technology vision and
architecture
must be specific enough to guide planning
and decision making but flexible enough to
withstand restatement each time a new
information system is developed
should provide the long term goal for the IS
planning effort-vision and architecture
represent the overall design target
Vision and architecture
an ideal view of the future and not the plan on
how to get there
must be flexible enough to provide a context for
individual decisions but more than just fluff
must focus on long term, but usually exact dates
are not specified
Vision and architecture
Information vision is a written expression of the
desired future for information use and
management in the organization
The information technology architecture depicts
the way information resources should be deployed
to deliver that vision
• An information vision and an information
vision architecture together translate a mental
image of the desired future state of information
use and management into a comprehensive set of
written guidelines, policies, pictures, or mandates
within which an organization should operate and
make decisions.
• Regardless of the form, vision and architecture
should provide the business, managerial and
technical platform for planning and executing IS
operations in the firm.
Vision and architecture
• A vision and architecture adds more value to an
organization when it is comprehensive rather than
detailed and when it is clearly communicated.
• Vision creation starts with speculating how the
competitive environment of the business will
change in the future and how the company should
take advantage of it. Once the business vision is
specified, the information vision for the
organization may then be written.
IT Architecture
• When a vision for future information use has been
formulated, the IS organization, often in cooperation with user-managers, must design an
information technology architecture.
• This architecture specifies how the resources
available to users and the IS organization must be
deployed to meet the information vision.
• Stefferud, Farber, and Dement (1982) postulate that the
design of a computing architecture consists of four
elements-processors, networks, services, and standards.
Their architecture is known as SUMURU.
• Nolan divides an information technology architecture into
data, applications, and communications components. He
also suggests that the process of building an architecture
starts by assessing current hardware, software, data,
communications, management controls, personnel, and
user elements of the system.
IT Architecture
An information technology architecture
should specify a structure in two categories:
1.Managerial
2.Technical
Managerial category:
• People - their values and beliefs
• Management systems used for guiding
information resources
Technical category:
• Hardware and network
• Data architecture for the organization
• A design for the software or applications
architecture
Decisions about these 5 areas collectively specify the
information technology architecture for an organization.
Values
•
•
•
•
•
This module states basic human beliefs that should
guide IS decision making.
Role of the user-manager
Technological leadership role
Productivity and quality emphasis
Service orientation and professionalism
Supporting diversity versus achieving integration
Management Systems
•
•
•
•
•
•
•
Role of the IS Organization
Breadth of media and application
Linking mechanism with the business plan
Corporate versus division IS responsibilities
Strategic and commodity vendors
Funding
Mechanisms for IS planning and control
Network infrastructure
•Location
•The Workstation
•General-Purpose vs Single-Purpose Nodes
•Supported Operating Systems
•Path and Node Redundancy
•Hierarchical vs Peer-to-Peer
•Supported Communications Protocols
•Public vs Private Networks
•Bandwidth
S e rv e r
Data
•
•
•
•
•
Ownership and Sharing
Stewardship
Security vs ease of access
Breadth of Data Access
Access to External Data Services
Application
• Assumed User
• Application Location
• Process-Driven or Data-Driven Design
Steps in Developing a Vision and
Architecture
1. Review of the Current Situation
2. Analysis of the Strategic Direction of the
Business
3. Recognition of General Technology Trends
4. Identification of a Vision for the Role for
Information
5. Determining the Architecture
6. Communication of the Visison and Architecture
7. Migration plan
Benefits of a Vision and Architecture
•
•
•
•
•
•
•
Better IS Planning
Communicating with Top Management
Helping Vendors
Creating a Context for Decision
Achieving Integration and Decentralization
Evaluating Options
Meeting Expectations of Management
Five-level framework for
applying IT strategies
Five-level framework
for implementation of IT
Level of IT application
Responsibility for implementation
National construction level
Public-sector agencies
Professional level
Professional institutions and and
trade associations
Construction enterprise
Enterprise
Construction project
Client and project team
Construction product
Client and project team
Why levels?
• Globalisation of construction, general
competitive pressure of market economy...
 National level IT strategy
• Deregulation, threats from outside the
industry, increasing demands for quality... 
Strategy for construction profession
Why levels?
• Competition, threat of new entrants, free
trade of services & foreign competition .....
 Enterprise level strategy (strategic mgt.)
• Fundamental operation level of construction
is the project, better project management
 Project level strategy
• Focus on core competencies, construction
process  Product level strategy
IT for Business Process
Reengineering in Construction
BPR
• Change is one of the most important elements of
succesful business management today. Continous
improvement is through change. This applies also
to construction.
• Business process reengineering (BPR) is a
methodology for implementing change
• IT plays an essential role in BPR
BPR methodology steps
1.
2.
3.
4.
5.
Identifying processes for redesign
Identifying change tools (levers)
Developing vision
Understanding existing processes
Designing new processes
(Betts 1999)
Main change levers
1. IT can help improving information flow
2. Human resources and structural change: New
types of teams (cross-functional), empowerment
and advancement policies, etc.
Process analysis
• To understand existing processes, detailed process maps
must be drawn up with some choice of flowcharting
method:
Fish-bone
Mind map
Etc.
Process change
• Typically, high-impact processes must be
addressed first
• Resistance to change will occur in organisation
(especially radical changes) especially because
BPR may cause downsizing
Process change
Example:
(‘Airline ticketing process’, Juran 1998)
BPR&IT Case 1: Kodak
• Fuji’s launch of a single-use camera had a significant market
impact which caused Kodak to take up concurrent
engineering to speed up product development. This was
facilitated through the use of a shared database with which
remote design teams could interact  parallel, independent
designs from engineering specialists but with dynamic
status-checking of the work of others through the shared
database.
BPR&IT Case 2: DEC
• Digital Equipment Corporation built an expert system
XCON building on the accumulated knowledge of their
design and field service engineers  reduced cost of
rework, reduced installation delays.
• XCON is also used by sales personnel for specifying
alternative configurations.  XCON represents a radically
new approach to internal logistics management.
Famous BPR cases
• Xerox/Canon: Canon could sell photocopiers cheaper than
Xerox’s manufacturing costs  Major process
restructuring at Xerox.
• Ford/Mazda: Mazda’s Orders Payable mechanism worked
satisfactorily with 5 employees whereas Ford had
problems with 500 employees (1986)  By 1990 only 125
Ford staff were needed, by learning from Mazda process.
BPR in construction
• More effective IT support of improved
construction processes possible, but IT
implementation must be rationalized (not
technology oriented)
http://www.ce.metu.edu.tr/~ynielsen/

similar documents