INFORMATION GOVERNANCE
Kpatel
Chapter6-BINF4515-kmk.pptxChapter 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
