Database usage throughout the Extended Project Life Cycle
How many Databases do I need?
A question that often comes up when talking to Solution Architects is how many databases do I need to plan for in my technical architecture?
Now, on the surface this seems a simple question and sometimes results in a simple response, however before you jump in with a stock answer of 3 or 4 (Production, Test and Development or Production, Pre-Production, Test and Development) you should apply the 6 W’s – Who, What, Where, When, Why & hoW to the full Extended Life Cycle
Your thought process needs to cover:
Application Life Cycle Management (ALM)
Type of Project e.g.
- Change – New Implementation, Upgrade
- Business As Usual (BAU) – Operations / ‘RUN’
Major planned Project activities e.g.
- POC (Proof of Concept)
- CRP (Conference Room Pilots)
- SVT (System Validation Test)
- UAT (User Acceptance Test)
- Cutover / Go-Live
Development Methodology e.g.
- Waterfall
- Agile / SCRUM etc..
Business Testing Requirements
- Manual
- Automated
Production ‘Run’ Support
- DBA Patching
- Daily / Ad-hoc Refresh
Training and Education requirements
Databases are not just used by developers
It’s also easy to forget databases are used by more than Developers, DBA’s and Business End Users, throughout the application life cycle different teams will also have competing demands and these all need to be satisfied. This can be further complicated when a project has a phased Go-Lives which result with Project and ‘RUN’ development, test and user acceptance testing activities occurring concurrently.
Large Enterprise ERP upgrade and implementation projects suffer from complex inter-team dependencies for example Data Migration teams can not load financial data until Functional teams have configured accounting structures, technical teams can’t configure enterprise scheduling solutions until business processes are defined.
An inadequate number of databases leads to project delays as the database becomes a bottleneck with teams having to wait for other teams to complete activities before they can start their tasks. e.g. Functional consultants unable to test business processes whilst data loads are being undertaken by Data Migration team members.
Other teams and activities to consider include:
Application Functional Specialists
- Development of System Set-up
- Business Process Configuration
- Business Process Testing
Data Migration Teams
- Development of ETL (Extraction, Transformation and Load) routines
- Data Mapping
- Data Cleansing
Technical Teams
- Performance testing
- System Integration
- Automation
- Enterprise Scheduling
Business Process Owners
- Application Process Validation
Conclusion
Database demands change throughout the life cycle of a project and application, a flexible approach is required which can provide databases on-demand with minimal hardware and operational overheads.
The number of databases required should therefore be calculated to satisfy the peak demand and should not be limited by storage infrastructure. Virtual Databases remove the storage constraints and operational barriers providing project teams the required agility without requiring additional storage infrastructure.