I had an “interesting” chat with a potential client this week. The conversation started normally with myself and my colleague going through the benefits of our Test Environment & Release Management solution, and then continuing to a “show and tell”. However, I could tell the client was somewhat distracted and had something “greater” on their mind.
So, I probed slightly & the vision became apparent:
“We want our Projects to Self-Service the Test Environments”
“OK”, I said, “can you provide me an example of which Environment?”
“Yes … A Test Environment for Payments”?
“OK”, I said, “a bit like ordering a Pepperoni Pizza online?”
“Yes, that’s right” said the client enthusiastically.
“Question ONE, do you know what your Payments Environment & Systems looks like?”
Answer: “Not really, we have some Spreadsheets & Wiki documents but they might be out of date”.
“Question TWO, are your current Infra, Data & Applications operations documented?”
Answer: “It depends on the team, I believe some do and some probably don’t”.
“Question THREE, can you currently create this platform from an Automate Script?”
Answer: “I think the Infrastructure guys have some Recipes & Scripts for MS SQL”.
Note: The latter answer amused me as there were about 150+ components, including Mainframe.
I find it somewhat crazy today, that IT Management and supposed “Subject Matter Experts” are suggesting this kind of nonsense and suggesting it seriously. I mean, sure if your environment and systems are simple enough you could offer complete automation and self-service. But they probably aren’t! Instead they probably consist of a complex web of components, relationships, processes and architectures that are poorly understood and out of date.
If an organization wants to establish Self Service Test Environment Management, then I’d offer this: “Understand your ingredients & learn how to cook first”. It might sound a bit boring. But it is 101 Environments Management. You can never expect to automate or self-service that which you don’t understand.
Relevant Articles
PII Risk in AI Is an Architecture Problem
AI is moving rapidly from experimentation into enterprise scale. Use cases are expanding, agents are emerging, and data is being pushed into pipelines at increasing speed. At the same time, organisations are trying to keep up with the associated risk. The response is...
Why Do We Need Release Gates?
Before starting this topic on the importance of Release Gates, lets first understand – what is a Release Gate? A Release Gate can be defined as a milestone or health indicator of a release at that very point in time. Milestones are like stones placed beside a road to...
SQL Server Data Masking: A Complete Guide
Imagine accidentally exposing thousands of customer records just because someone needed a database for testing. Scary, right? Data security is one of the biggest challenges enterprises face when working with SQL Server. This is where SQL Server data...
What is Data Risk Assessment? A Complete Introductory Guide
Data is vulnerable. Every enterprise handles vast amounts of sensitive information, from customer personally identifiable information (PII) to financial records and proprietary business data. Understanding where data is at risk and protecting it is...
AWS Data Masking: A Practical Guide
One careless copy of production data in the cloud can expose sensitive customer information and trigger costly compliance violations. As organizations move more data into the cloud, it’s increasingly common to replicate production datasets across development, testing,...
What are Post Implementation Reviews?
In today’s fast-paced business environment, the success of a project hinges not just on the effective execution but also on thorough post-completion analysis. This is where Post Implementation Reviews (PIRs) come into play. They are a critical component of project...