Inviting Life Back Into Your Unused Secondary Environment

In your Blackbaud CRM neighborhood, there’s a house where no one goes. The lights are never on, and nobody is home. The kids from the cul de sac throw rocks at the boarded up windows, and dare each other to cross the threshold of your unused secondary environment.

“I heard they used to try out experimental customizations on Blackbaud CRM in there!”

“Whatever, my dad says it was just for Training!”

Inside dwell nothing but fading memories. Once upon a time, it was a vital part of your vision for Blackbaud CRM, one gear in a complicated chain. But at some point it fell into disuse, and started the long process of collecting dust and decay.

As urban planner of Blackbaud CRM-ville, you have a decision to make: Repurpose or De-purpose? Just sitting there, it’s a waste of resources, a source of troubleshooting headaches, and a hazard to curious passing interns. From a security standpoint, it’s a problem waiting to happen. Something needs to be done, but simply getting rid of it would be an affront to all the work it took to stand it up, right?

The fact is, every deployment is unique. The decisions that you make about your secondary environments are going to lean on a lot of factors. It can be a lot to take in, so here’s a few ways to break the picture down and see what needs to change to reinvigorate the neighborhood.

“The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.”
― Frederick P. Brooks Jr

The purpose of these secondary environments are to provide a simulation of how things will behave when you change or customize your Production system, right? It’s a playground where you can mess with your creative ideas and if something breaks, no harm is done. Yet there are many cases where the secondary environment is pretty different from Production, because it’s working from outdated, stagnant information. This makes it way less applicable for testing how things will behave in Production, and makes your simulations less and less realistic.

Keep in mind, these secondary environments aren’t being updated with new data the way your Production system is. This is done by design and for good reason, as keeping this line of separation is important for protecting your Production data. But this does mean that an environment can become less useful for testing if it isn’t close to your Production data, and you end up running your tests against something very different.

The reasons for skipping or missing a database refresh can vary. You may be hitting a limit or policy with your current hosting provider. More often than not, the team can get gun-shy about touching the database because something broke the last time, like Data Warehouse. We shouldn’t be accepting this as reasonable behavior from Blackbaud CRM though. That’s when it’s time to scrutinize and sort out our processes.

At what step in the refresh did things break? How did the issue manifest, and where? What was performed to back out? These questions should be easy to answer if you have your processes and records down pat. Your development, testing, diagnostic and maintenance processes should all be heavily documented. If they aren’t, you’re left with a lot of ambiguity to grasp around in and a lot of questions to ask when something doesn’t go according to plan.

With a proper, documented process to follow, refreshing secondary environments should be a quick and easy thing to turn around in a day. It shouldn’t result in crisis, and should be a scheduled part of your ongoing processes to keep your secondary environments useful. After all, what good is testing when it’s done with an inaccurate model?

“In fact, flow charting is more preached than practiced. I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs” - Frederick P. Brooks Jr.

There’s something to be said about having documentation on how to perform various tasks within your Blackbaud CRM. They really help keep your projects and processes on track, and help fill in skill gaps in a pinch.

But day to day instructional documents may not prove very useful for understanding the landscape of the supporting systems of your Blackbaud CRM or how they come together. Some things need a birds-eye-view. This is where having a diagram to map out the big picture can prove very handy.

Having a diagram of your entire Blackbaud CRM layout or workflow is one of those things that you might not think will be useful until it is.

Starting a support ticket with Blackbaud about an important issue, but don’t want to write a massive preamble explaining your unique configuration? Send them the map.

Bringing on new staff for the project, and they have a lot of questions about how the sausage is networked? Send them the map.

Migrating to a new host, and want to ensure they have all the information they need on how things used to work on your end? Send them the map.

Want to sit down with your team to have a good look at your Blackbaud CRM environment and brainstorm what could be done to reshape it? Take a look at the map!

Starting a new documentation project can ellicit a lot of eye rolls. After all, it can feel like you’re adding work onto someones plate. I try to look at it this way, and hope that it helps: What do you hate more? Writing docs, or repeating yourself?

But referring to our words of wisdom from Fred earlier, nobody writes documentation, much less ahead of time. Why?

Because you're stopping at the point of realization, right at the "Eureka!" moment when you have figured something out, and jotting down your idea before acting on it. Most of us skip right to the "doing" part of the solution so we don't lose track of our bottled lightning. And afterward, there's all the business of making sure things REALLY are working. So when do the docs get made?

One solution could be requiring a diagram or flowchart as supporting documentation for any process change that goes to Production, or otherwise goes live into one of your Environments.

Let's say you have a new integration you want to plug in. Your team creates a mock-up in Training, since you'll need to train on it's use anyway, and it's a good test bed for Production. Before you get too far into testing it, stop, and diagram out how things are getting connected.

With a map, testing can be more guided. With a map, deployment to Production will be more straightforward. With a map, troubleshooting can be much more effective. You spend less time searching through smoke because you know where your fires start.

Now, somebody having THE map isn't a very good solution for everyone on the team. That map needs to be available for anyone that needs it. This information doesn't just need to exist, it needs to be shareable.

Of course, there could be a big difference between a network diagram that you create for your internal IT team to understand your configuration, and a diagram that you would email out to support staff at Blackbaud, for obvious security reasons. Some documents might end up having an external and internal audience, some one or the other. Keeping that organized is a challenge, but having this kind of tailored information on hand can be convenient or even project-saving.

If you already have a robust and detailed documentation process, that’s fantastic. But adding diagrams for your Blackbaud CRM configuration and processes can add a lot of utility, in addition to providing a useful aid for getting everyone on the same page when considering any changes to your environments.

“For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation.” - Frederick P. Brooks Jr.

At some point, your team had a vision of Blackbaud CRM that included all of these systems in a pretty clear way. How long ago was that, though? That much time has passed for reality, the team, their practices, and any pivots that you had to make along the way to reshape your processes substantially.

Adding to the entropy, your organization is a different animal from what it was at the beginning of this quarter, this year, or when you first set up Blackbaud CRM. The system that you have now is admittedly different from the system that you originally envisioned, because it has been shaped by the efforts of your team and how they operate.

Your environments may need to change to reflect this change in reality.

Take stock of your current environments, and what their original purposes were. Compare this with how the environments are being utilized by your team today. You might find some redundancy to cut, or even the strategic purpose of a separate, new environment. After all, every deployment is unique, and every organization finds a different way to experiment with, test, revise, and deploy Blackbaud CRM.

Consider your future as well. If you plan on bringing on another handful of devs, would there be some utility in adding another DEV zone? How does that change the overall topography? How will it change your processes?

Reviewing the differences between the ghost of your organizations past and those of it’s present and future can give you a lot of information on what has changed or needs to change about your environment and it’s systems.