Development is more Important than Production!

Some years ago, not too long after Y2K when DB2 V7 for z/OS was reasonably new, I recall a busy afternoon trying to identify the root cause of a slowdown within a recently amended critical application process in Production. New code had been deployed several days before but no issues had been identified during volume test against production like sizes of data, so it wasn’t one of those obvious issues that are quick to resolve.

At the same time, there was an outage with one of the Build/Development environments. I had been asked by several teams if I could investigate and resolve as soon as possible. I informed them that I was working on a Live issue and that Production service took priority which they understood albeit begrudgingly. After about an hour of investigation into the Production issue, we were busy testing a resolution to ensure normal service could be resumed.  A group of 3 Production Service managers were crowded behind me while we ran the test, eagerly anticipating the results when one of the business delivery Project Managers came storming over full of bluster and very red in the face.

“I understand my Development environment is still unavailable?”

“Yes, it is unfortunately”

“I’m losing valuable money while my developers sit idle and we’re already behind on our target date for build completion. Testers are also sitting doing nothing waiting for Development to be completed. When are you going to fix it?”    

“When I have finished what I am working on, the Development environment issue is my next priority” I replied calmly

“What? You are working on something else instead? What is so important?” he shouted with an even redder face

“I am working to resolve a Production issue that is impacting a customer service”

“A Production issue? Development is more important than Production!”

His comment received incredulous looks all round, but eventually the production issue was resolved and then the development environment up and running, but only after 3 hours of downtime.

Nothing can be as important as the loss of a customer service or business critical process in Production, however Development & Testing environments have become more critical: –

• More and more agile Development and shorter timespan for project lifecycle from Development to Production deployment (measured in small numbers of weeks or even days rather than many months), means even a few hours of downtime can cause critical delays and missed deadlines
• Development & Testing environment down time is costly in terms of people costs as teams of developers, testers & engineers sit idle
• Development & Testing is often taking place across many time zones, or out of hours, so a 9:00-17:00 based support window around your local time zone may not be sufficient for a rapid response to resolve any outage.
• Ultimately downtime could delay production roll out of new or improved customer functionality, failing to improve customer service and falling behind competitors

Ensure you have enough DBA coverage to be able to respond to, not just Production issues but also, those issues impacting availability of Development & Testing environments. And, much like Production, a 09:00-17:00 service support window may not be enough.

About Triton Consulting

Triton Consulting has been providing DB2 consultancy services for over 21 years. As well as expert consultancy in all areas of DB2, Triton Consulting also cover a wider spectrum of high level consultancy including senior project management, technical planning, technical architecture, performance tuning and systems programming.

Find out more about DB2 support services from Triton Consulting.

Download the Top 5 Reasons for Choosing Remote Database Support white paper.

About Paul Stoker – Director, Sales and Marketing

Favourite topics – Advanced SQL, Performance Tuning, Physical Database Design, Snowboarding & Beer!

With over 25 years in IT, Paul is an experienced data management consultant, having spent the last 20 years specialising in database technology, particularly IBM DB2 & z/OS.

Paul has undertaken many roles including, Technical Architect, Performance Tuning specialist, Physical Data Modeler & Development/Production DBA and has also managed DBA teams, Technical Support teams, Data Migration and Database Version upgrade projects. Paul’s experience covers industry sectors such as Retail Banking, Central Government, Investment Banking, Insurance & Telecoms on projects including, modernisation of a large scale 24*7 online retail application & design/implementation of data migration processes.

Paul heads up the Sales & Marketing team as well as being actively engaged with customer projects. Most recently Paul has been working in a project management and technical planning role for DB2 z/OS version migration and conducting a review of data security/test data management.

Paul is always up for the challenge of reducing elapsed time for log running transactions or reducing CPU time of CPU hungry jobs.

When he’s not battling CPU challenges Paul can be found hurtling down the mountainside on his snowboard, beer in hand!

View Paul’s blogs and tech tips. 

• Share