How Many Databases is Enough?

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)

ALM

Type of Project e.g.

  • Change – New Implementation, Upgrade
  • Business As Usual (BAU) – Operations / ‘RUN’

Project Life Cycle
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.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s