INFORMATION GOVERNANCE
Ace your studies with our custom writing services! We've got your back for top grades and timely submissions, so you can say goodbye to the stress. Trust us to get you there!
Order a Similar Paper Order a Different Paper
Data Architecture
Data architecture comprises the design and maintenance of the enterprise information architecture. This includes development and implementation of policies, standards, processes and methodologies for identifying and defining what information is collected, and how it is stored, standardized and integrated throughout the enterprise. Data architecture activities include the development, use, and maintenance of artifacts such as diagrams of business processes and data flows and data models that support information systems development and maintenance.
Data architecture management is the foundational component for any information system. The artifacts produced from data architecture activities, such as use cases, DFDs, and data models, guide the remainder of information systems development.
Data architecture management, however, does not stop with systems development. It is an ongoing process. The artifacts produced from the requirements analysis stage live on past system implementation, and they play a vital role as communication documents for developers who make changes and upgrades to an information system at a future time.
Ensuring that organizations have quality data starts with the beginning of the SDLC. If business and end user requirements are not adequately identified, documented, and translated into meaningful and accurately documented artifacts that guide the rest of the development cycle, then the developmental effort runs the risk of producing systems that have accessibility, usability, reliability, and data quality problem.
The following are among the functions of data architecture management:
- Establish standards, policies, and practices that support data architecture management functions
- Develop quality control metrics and practices for data architecture management
- Apply techniques, tools, and documentation such as, interview, observation, document analysis and Joint Application Development, for identifying and gathering functional and non-functional system requirements
- Apply techniques and tools such as use cases, data flow diagrams, and entity relationship diagrams for analysis of current and proposed systems
- Develop, maintain, and update conceptual, logical and physical database models
- Create, maintain, and update the data dictionary containing all metadata entity names, attributes, and relationships
Systems Development Life Cycle
The chapter covers the first two stages, system initiation and requirements analysis, of the SDLC in detail. This document covers the remaining SDLC stages.
Refer to textbook page 107 for an explanation of the following:
· System Initiation
· Requirements Analysis
· System Design
· System Construction
· System Acceptance
· System Implementation
System Design Phase
When the requirements analysis phase has been completed and the functional requirements identified, the system is designed. The systems design phase provides the design or blueprint for the technical solution for the proposed system. The design phase describes how the system should function. This includes how:
· Users interact with the system and the types of user interfaces they need
· Components of the system interact with each other and existing application programs
· The data model for the system integrates with existing data models
· The application will be programmed
· The technical environment for the system will be prepared
· System testing will be conducted
· System migration will be handled
A special technical team is assigned for the system design phase. One of the first steps is to assess the existing technical infrastructure and capabilities and to attempt to leverage these as much as possible. However, the team may discover that new technology platforms are required to support the new system. Items such as data access and storage, runtime and batch time requirements, reporting, archiving, security and auditing, and interface development are identified.
An important part of the design phase is to specify design standards. Among these standards are specifications for naming conventions, programming techniques, screen formatting and graphical user interface design, report generation, application navigation, documentation formats, and application testing. Configuration management standards that prescribe the way changes to the software are tracked and how backup and recovery procedures are handled are also specified. Design standards would fall under data governance policies and procedures.
The logical data model is transformed into a physical data model. Physical database repositories are created to handle the application. In designing the physical database, designers take into consideration items such as how the data is used, number of users expected to access the database simultaneously, anticipated peak user loads, and retention requirements.
During this phase, prototypes of the system are often developed. The prototypes address aspects of the system such as screen and usability design, navigation, controls such as buttons, and presentation and report styles. Prototypes help the end user assess the functionality of the system. It is easier and less costly to make adjustments and refinements in this stage than in construction and implementation states.
The output of this phase is a technical architecture document that specifies the hardware, software, database, and tools and peripherals needed, performance requirements of the system, technical risks, and data and code migration plan.
System Construction
System construction includes all of the activities required to build and test the system. Training materials and system documentation are also developed during this stage. Individual components and utilities of the system are developed and then are tested individually by the construction team using test scripts to ensure functional requirements are met. Test scripts identify the function and technical requirements the system must perform and expected outcomes. Any deviations from the specifications are noted, examined, and corrected. Once each module is tested, then the technical team initiates integration testing. Integration testing is an iterative approach. It involves adding module after module to the system and testing each successive addition to ensure that technical and functional requirements are met. A final end-to-end system test is then performed with all modules and utilities.
System Acceptance
After system construction, the system is handed over to the end-users and the project team to validate that it meets all of the functional requirements identified during requirements analysis. An acceptance test plan is developed and used to assess the system operation. This stage of the SDLC is critical because it is the last opportunity to identify and correct defects prior to the system going into production. Emphasis is placed on testing the application and the data. Data throughput, manipulations, and load should be thoroughly tested to ensure that expected outputs are produced. The system acceptance environment should be as close as possible to the actual production environment and the testing team composed of representatives from all end user roles that will be using the system.
System Implementation
System implementation includes the deployment of the system and its continuing maintenance. The project team develops detailed implementation plans. Unlike other SDLC stages, the implementation stage affects real business operations. Errors or missteps during this stage can have a potentially catastrophic impact on the business. Training end users is a significant part of this stage of the life cycle.
Several different approaches may be used for implementation. Each has its own risks and costs. These approaches are called parallel, phased, and direct conversion. Frequently, a new implementation is replacing an older system. When this is the case, a parallel approach may be used. This involves running both the old and the new systems until the managers and technical staff are confident that the new system is functioning as intended. This approach is costly and can be confusing to staff, but it ensures that a backup system would be available if needed.
A second approach is the phased approach. The phased approach is usually implemented in one of two ways. In one approach, portions of the new system are implemented over time, usually module by module, instead of installing the entire system at once. This allows for easier identification and remedy of any defects found by the user and technical teams. The system can also be phased in location by location. In this approach the entire system may be implemented in one or a few units at a time rather than implementation occurring throughout the entire organization. This approach limits the impact of any defects and risks to a smaller segment of the business.
The final approach is called a direct cutover, where the entire system is implemented on a specified date throughout the organization. This approach is risky but can work if there was sufficient testing and if there are adequate backup and recovery procedures in place.
Implementation also involves ensuring that the system is meeting all functional and technical requirements. Evaluation scripts are developed and used to identify any lingering defects.
Once all evaluation is completed, the system is considered to be operational and enters the maintenance phase. The responsibilities for the system are then turned over from the implementation team to a maintenance team.
Chapter 6
Data Architecture Management
St. Rita’s EIM Team Questions
What falls within the scope of architecture management?
What is the data life cycle and how does it fit within data architecture management?
What are system development methods?
How is data governance (DG) applied to data architecture management?
Life Cycles for Managing Systems development
Managing Systems Development
Project management life cycle
Systems development life cycle (SDLC)
Systems Development life cycle (SDLC)
Systems Development Life Cycle
Systems Development Life Cycle
System initiation
The business case and project solution are validated to ensure they meet business needs
Resources including staff, budget, and time are identified
Project schedule is developed
Final approval by authorizing authority
Systems Development Life Cycle
Requirements analysis
Business requirements that the system will support are identified
Accomplished by business analysts and end users identifying current business processes (the “as-is” system), determining what improvements or changes need to be made to the current processes, and identifying the characteristics and functions of the new (“to-be”) system
Development of artifacts such as data flow diagrams, data models, and use cases
This slide can accompany the Student Workbook section for chapter 6.
8
Systems Development Life Cycle
System design
Functionalities and processes are translated by the project team into a technical design or architecture and includes:
Identifying the hardware and system software
Creating the physical database, security strategy, and performance requirements
Prototyping system components
This slide can accompany the Student Workbook section for chapter 6.
9
Systems Development Life Cycle
System construction
The activities required to build and test the system including:
Building and testing the individual system components
Integrating and testing the components as a whole
Producing user and technical documentation
This slide can accompany the Student Workbook section for chapter 6.
10
Systems Development Life Cycle
System acceptance
The system is validated (tested) by the project team and end users to determine if it meets all of the functional and technical specifications; this may include:
System walk-throughs
Manual and automated testing
Revision of technical and user documentation
This slide can accompany the Student Workbook section for chapter 6.
11
Systems Development Life Cycle
System implementation
System deployment into the real world environment and includes:
User education
Putting the system into production
Transitioning ongoing support and maintenance of the system to the appropriate units of the organization
This slide can accompany the Student Workbook section for chapter 6.
12
System initiation
Example System Initiation Process
SDLC Development methods
SDLC Development Methods
Waterfall Method
Oldest development method
Implemented sequentially
Benefits
All planning done before software development
Minimizes scope creep
Disadvantages
Time delay to deployment
Costs of redesign
Minimal end user input
SDLC Development Methods
Parallel Method
Project divide into sub-projects that are developed and implemented parallel with each other
Benefit
Reduces development time
Disadvantage
May introduce integration problems if development of each subpart is developed completely independent
SDLC Development Methods
Validation and Verification Model
Also called V-model
Integrates testing design with all the life cycle stages
Benefits
Overall quality of system improves
Disadvantage
Retains rigidity of waterfall method
Rapid Application Development Methods (RAD)
A group of developmental methodologies that address the long development time problem
Goes through the analysis, design, construction, and acceptance stages of the SDLC quickly and gets essential parts of the system to the end user as soon as possible
Uses a combination of tools and techniques to move through the SDLC stages quickly
RAD Methods
Iterative method
Prototyping
Spiral method
Agile development
Requirements analysis
Requirements Analysis
The set of processes used for identifying what function(s) an information system must perform and how it is to provide them
Fundamental building block of all information systems
The most difficult step in information systems development, and most defects originate in the requirements analysis and design phases
Requirements Analysis
Gathering Techniques
Document analysis
Observation
Interviewing
Joint application development (JAD)
Requirements Analysis
Outputs
Group of key artifacts that guide the system’s design and construction that include:
Data flow diagrams
Process flow diagrams
Use cases
Data models
Functional specification documents
data ARCHITECTURE DOCUMENTATION
Data Architecture Documentation
Tools, techniques, and documentation strategies are used to provide discipline, structure, communication, and integration among analysis tasks
Documents produced are called artifacts
Artifacts are crucial for communication between the development team and stakeholders and providing documentation for future changes
Data Architecture Documentation
Use Cases
Technique used by analysts for capturing and documenting user requirements
Identify and clarify the interactions between an end user and the proposed system
A story of the steps or actions that are taken between a user and a system to achieve an end result
Data Architecture Documentation
Use Cases
Use case types
Essential use case (business use case)
Describes the business process and interaction of the end user with the system without specifying any technology details
System use case
Provides the technology and operational details of the system and is used by the technical staff
Data Architecture Documentation
Use Cases
Differing format types
Common elements
Use case name specified by a verb or verb phrase
End users identified by label “actor”
Section that identifies main steps performed
Extension or variation section describing alternate flows or actions
Sample Use Case Documentation
Data Architecture Documentation
Data Flow Diagram (DFD)
A visual process model used to model the processes, flow, and transformation of data in a system.
Used to model “as-is” and “to-be” system processes
Provides the opportunity to assess differences in “as-is” and “to-be” systems
Data Architecture Documentation
Data Flow Diagram (DFD)
Developed from use cases or created directly from the results of requirements gathering
Shows a system’s functionality at a high level
Logical DFDs
Describe processes from a business view
Physical DFDs
Describe system technical details
Data Architecture Documentation
Data Flow Diagram (DFD)
DFD components
External entity (EE)
A person, company, agency outside the organization or system under discussion (SuD)
Process
Any activity performed electronically or manually
Data flow (DF)
Any input to or output from processes or data stores
Data store (DS)
Organized collection of data, such as database or file
Data Architecture Documentation
DFD Notation Styles
Data Architecture Documentation
DFD Modeling
Consists of a set of hierarchical DFD diagrams
Sequentially breaks down a process to its most basic parts
Context diagram consists of the highest-named process or system and includes the EE and the data that flows from and to the process
Level 0 and successive diagrams provide specifics about the sub-processes composing the main process in the context diagram
DFD Context Diagram
DFD Level 0 Diagram
Data Architecture Documentation
Data Model
Data model purpose
Describe the things about which an organization wishes to collect data
Convey this meaning to:
End users
System designers
Technical staff
Use as basis to design and construct actual system
Data Architecture Documentation
Data Model
Entity Relationship Diagram (ERD)
One of the most common of data modeling methods
Used for modeling relational databases
Models entities, attributes, and relationships
Data Architecture Documentation
Data Model
Data model includes
Entities
A person, place, thing, or event
Attributes
Describe an entity
Relationships among entities
Data Architecture Documentation
Data Model
Types of data models:
Conceptual
Logical
Enterprise
Physical
Data Architecture Documentation
Data Model
Conceptual data model
The highest representation
Includes entities in a business and the relationship among them
Does not contain attributes of entities
Precedes development of the logical data model
Data Architecture Documentation
Data Model
Logical data model
A representation of the logical organization of the data, usually for one system or subject area of the business
Does not reference any technical details such as how the data are stored, indexed, retrieved, or manipulated
Data Architecture Documentation
Data Model
Enterprise data model
A logical data model that is a representation of the logical organization of enterprise data showing overlaps between enterprise systems
Data Architecture Documentation
Data Model
Physical data model
Represents how the data are physically stored in the database
Based on the logical data model
Includes the tables and columns and metadata such as data type and field length
Data Architecture Documentation
Data Model Example
Database Structures
Flat file
Hierarchical
Network
Relational
Object-oriented
Database Structures
Flat file structure
First type of database structure
Files are not structurally related to each other
Create data redundancy, consistency, insertion, and update problems
Database Structures
Hierarchical structure
First appeared as a commercial product in the mid-1960s
Tree structure based on the concept of “parent” and “child” relationships
Strength is its ability to traverse a hierarchy very quickly for data retrieval
Random access to data across patients, non-routine, and ad hoc queries can be extremely slow
Database Structures
Network structure
Remedies problem of slow data across entities of hierarchical structure by allowing more than one parent table to share child tables
Drawback is that if the logical data model changes, the physical structure of the database is not easily modified
Database Structures
Relational structure
The most prominent architecture used today
First developed in 1960’s and based on relational algebra
Makes many improvements in data management over the flat file, hierarchical, and network models
Provides structure to establish relationship among files
Database Structures
Relational structure benefits
Enables quick access to data
Permits flexibility in changing database structure
Accommodates the use of complex queries to retrieve data
Ensures propagation of data changes throughout the database
Offers data integrity controls
Allows efficient modification and development of application programs
Provides standard query language (SQL)
Database Structures
Object Oriented (OO) Structure
Developed to deal with increasingly complex data types such as graphics, engineering designs, spatial, and audio-visual data
Combines the concepts of the hierarchical database and object-oriented programming
Combines the attributes (the data) and the programming code (methods) in an object
Benefits: Modularizes and permits reuse of the object by different parts of the system
Case tools
Data Architecture Documentation
CASE Tools
Computer assisted software engineering (CASE) tools
Support documentation and communication aspects of the SDLC
Integrate tasks throughout the life cycle stages
Categories include visual aids, prototypes, data dictionary (DD) development, analysis, design, and code generation tools
Data Architecture Documentation
CASE Tools
Upper CASE tools
Support the analysis phase
Such as DFDs, data process diagrams, use cases, logical ERDs
Lower CASE tools
Support design and implementation
Such as physical ERDs, screen designs, prototypes, and code generation
Data Architecture Documentation
CASE Tools
Benefits
Reduced time to complete analysis and development tasks
Decreased analysis and developmental costs
Better documentation than manual processes
Disciplined development approach
Higher software quality
Improved communication among developers and other stakeholders
Shared project and system documentation repository
CASE Data Entry Screen Example
Data Architecture Documentation
Data Dictionary
The central repository for information about
Tables, attributes, and relationships
Includes metadata such as:
Data definitions, default values, validation criteria, and messages
Used by analysts, programmers, and end users to understand the system
Strict naming conventions for tables, attributes, and relationships should be established
Applying DG to data architecture management
Data Architecture DG
Develop, update, and maintain data models and data model policies and standards
Define roles, responsibilities, and accountabilities for data architecture management
Develop, maintain, and evaluate policies and standards for requirements analysis
Develop and maintain data artifacts and standards
Develop and implement a quality control program and metrics for data architecture management
Introduction
Developing of an information system may fail.
There are many factors that must be considered and come together in order to develop a successful information system.
The SDLC = Systems Development Life Cycle is one approach to reduce the risk of failure.
What do businesses build information systems?
How does the business though when it is time to replace the old information system with a new one?
Typically: workers will request new systems to help them perform their work.
1
The System Development Life Cycle
What is an information system (IS)?
Hardware, software, data, people, and procedures that work together to produce quality information
System—Set of components that interact to achieve common goal
Businesses use many types of systems
The System Development Life Cycle
What are the phases of the system development cycle?
Phase 1. Planning
Phase 2. Analysis
Phase 3. Design
Phase 4. Implementation
Phase 5. Support
Review project requests
Prioritize project requests
Allocate resources
Identify project development team
Conduct preliminary investigation
Perform detailed analysis activities:
Study current system
Determine user requirements
Recommend solution
Acquire hardware and software, if necessary
Develop details of system
Develop programs, if necessary
Install and test new system
Train users
Convert to new system
Conduct post-implementation system review
Identify errors and enhancements
Monitor system performance
There are literally hundreds of activities associated with each phase of the SDLC
Such activities include:
Determining budgets
Gathering systems requirements
Documentation
Modeling
3
Arrange tasks into phases (groups of activities)
The System Development Life Cycle
What are guidelines for system development?
Involve users (anyone for whom system is being built)
Develop clearly defined standards (procedures company expects employees to follow)
The System Development Life Cycle
Who participates in the system development life cycle?
The System Development Life Cycle
What is a systems analyst?
Responsible for designing and developing information system
Liaison between users and IT professionals
The System Development Life Cycle
What is the project team?
Consists of users, systems analyst, and other IT professionals
Formed to work on project from beginning to end
Project leader—one member of the team who
manages and controls project budget and schedule
The System Development Life Cycle
What is feasibility?
Measure of how suitable system development will be to the company
Operational feasibility
Schedule feasibility
Four feasibility tests:
Technical feasibility
Economic feasibility (also called cost/benefit feasibility)
The System Development Life Cycle
What is documentation?
Includes reports, diagrams,
programs, and other deliverables
Collection and summarization
of data and information
The System Development Life Cycle
What are six data and information gathering techniques?
Review documentation
Observe
Questionnaire
Interview
Joint-application
design (JAD) session
Research
The System Development Life Cycle
What are some reasons to create or modify an information system?
Competition can
lead to change
To improve
existing system
Outside group may
mandate change
To correct problem
in existing system
The System Development Life Cycle
What is a request for system services?
Formal request for
new or modified
information system
Also called
project request
The System Development Life Cycle
What is the planning phase?
Begins when steering committee receives project request
Steering committee—decision-making body for the company
Function of committee:
Review and approve project requests
Allocate resources
Form project development team for each approved project
Prioritize project requests
Planning phase – involves determining a solid plan for developing your information system.
The three of the most important activities involved during the planning phase:
Identify and select the system for development
Set project scope
Develop project plan
13
The System Development Life Cycle
What is the analysis phase?
Conduct preliminary investigation, also
called feasibility
study
Perform detailed analysis
The System Development Life Cycle
What is the preliminary investigation?
Determine exact nature of problem or improvement and whether it is worth pursuing
Findings are presented in feasibility report, also known as a feasibility study
The System Development Life Cycle
What is detailed analysis?
Sometimes called logical design
2. Determine user’s wants, needs, and requirements
3. Recommend solution
1. Study how current system works
The analysis phase involves
The end users
The IT specialists
Working together to understand and document the business requirements for the system.
16
Presented to steering committee, which decides how system will be developed
The System Development Life Cycle
What is the
system proposal?
Assesses feasibility
of each alternative solution
Recommends the most feasible solution for the project
The System Development Life Cycle
What are possible solutions?
Buy packaged software—prewritten software available for purchase
Outsource—have outside source develop software
Write own custom software—software developed at user’s request
Vertical market software—designed for particular industry
Horizontal market software—meets needs of many companies
The System Development Life Cycle
What is the design phase?
Acquire hardware and software
Develop all details of new or modified information system
The primary goal of the design phase
Build the technical architecture required to support the system.
This includes
Design of the technical architecture
Design system models.
19
Visit vendors’ stores
The System Development Life Cycle
What is needed to acquire new hardware and software?
Identify all hardware and software requirements of new or modified system
Surf Web
Read print and online trade journals, newspapers, and magazines
Talk with other
systems analysts
Technical architecture –
Defines the hardware, software, and telecommunications equipment required to run the system.
The final architecture must meet you needs in terms of
Time
Cost
Technical feasibility
Flexibility
It is important to ensure that the final architecture meet
Current system needs
Future system needs
20
The System Development Life Cycle
What are three basic documents used to summarize technical specifications?
Less formal method that uses standard form to request information about product or service
Vendor quotes price(s) for listed product(s)
Vendor selects product(s) that meet(s) your requirements and then quotes price(s)
Identifies product(s) you want
Request for information (RFI)
Request for proposal (RFP)
Request for quotation (RFQ)
The System Development Life Cycle
How do systems analysts test software products?
References from vendor
Talk to current users of product
Product demonstrations
Trial version of software
Benchmark test measures performance
The System Development Life Cycle
What is a detailed design?
Includes several activities
Database
design
Input and
output design
Program
design
Detailed design specifications for components in proposed solution
The System Development Life Cycle
What is a mockup?
Sample of input or output that contains actual data
The System Development Life Cycle
What is a prototype?
Working model of
proposed system
Beginning a prototype too early may lead to problems
The System Development Life Cycle
What is computer-aided software engineering (CASE)?
Software tools designed to support activities of system development cycle
Convert to new system
The System Development Life Cycle
What is the implementation phase?
Purpose is to construct, or build, new or modified system and then deliver it to users
Train users
Install and test new system
Develop programs
Implementation phase
Bringing the system into life by placing it in the organization
During this phase
You distribute the system to all of the knowledge workers and they begin using the system to perform their everyday jobs.
You create User documentation
Highlights how to use the system.
You perform training to the employees to use the system
27
The System Development Life Cycle
What are the three types of tests performed by system developers?
Verifies application works with other applications
Systems test
Integration Test
Unit Test
Verifies each individual program works by itself
Verifies all programs in application work together
Testing is critical
Must have test plans
28
The System Development Life Cycle
What is training?
Showing users exactly how they will use new hardware and software in system
Online training – runs over the Internet
Workshop training – is held in a classroom environment and lead by an instructor.
29
The System Development Life Cycle
What is the support phase?
Conduct post-implementation system review—meeting to find out if information system is performing according to expectations
Identify errors
Identify enhancements
Monitor system performance
Provides ongoing assistance after system is implemented
Once the system is in place you need to provide support
Build a help desk to support the system users.
Provide an environment to support system changes.
30
The Practice Side: Case Study
The data model was key
A community hospital purchased a new automated MPI system. The hospital selection and implementation team had conducted a requirements analysis and obtained a data model of the new system from the vendor. The team conducted a walk-through of the conceptual data model from the vendor and determined that it met all of the hospital’s requirements. The hospital scheduled the conversion from the old to the new system to occur overnight when activity was minimal. System technicians loaded all of the MPI data from the old to the new system without incident.
The next morning when registration clerks attempted to access information from the MPI for patient clinic visits and admissions to the hospital, they could not retrieve correct patient medical record numbers. The new system was immediately shut down and technical personnel had to convert back to the old system until the problem was identified. A major concern was that the new system might corrupt other downstream systems that relied on MPI data, such as laboratory, R-ADT, and radiology systems.
An immediate investigation took place to identify the problem. It was discovered that the new system allocated 7 characters for the medical record number when the actual medical record number was eleven characters long. During conversion, medical record numbers were truncated in the new system and trailing digits were added to the next medical record number. During a debriefing of the situation, the implementation team recognized that while the conceptual data model met functional requirements, it did not provide sufficient detail about entity attributes such as field type and length. A major breakdown in the team’s analysis was not comparing the new system physical data model to data model in the old system. An underlying problem was that there was no physical data model for the old system.
Questions
1. What governance standards might be applied to ensure that this kind of problem would not occur again?
2. Since the hospital did not have a data model for the old system, what options might they have used to ensure that the new data model met their requirements?
Looking for top-notch essay writing services? We've got you covered! Connect with our writing experts today. Placing your order is easy, taking less than 5 minutes. Click below to get started.
Order a Similar Paper Order a Different Paper
