If your interested in IT & Test Environments Management then you have probably heard of the Environment Management Maturity Index (EMMI), the de-facto standard for measuring ones Test Environment Management capability.
If not then let me summarize: the EMMi is a maturity index that provides you with a standard frame of reference to help you assess your strengths, weaknesses, opportunities, and threats.
A powerful tool for assessing your environment and operational capability across your enterprise and help you quickly opportunities to improve.
As shown in the diagram, the EMMI does this by scoring you on eight key performance areas (KPAs). Today, I’ve decided to dive deeper into each of those key performance areas so that you can make a well-informed assessment.
KPA 1: Environment Knowledge Management
First up is environment knowledge management. This refers to your ability to understand how your projects move through all your environments, including development, testing, staging, demoing, and production.
However, this is about more than just one software team. This is about understanding how your systems are connected in each environment across multiple software systems and business units. You will likely need a few models of both low-level relationships and higher-level connections of your systems to gain a strong understanding.
When you know how your software systems are connected as they move through environments, you can avoid many problems. You reduce the risk of disruption when a team needs to release to a new environment. For example, if your billing system is dependent upon your product catalog and the product team releases a new version to QA, you may suddenly see network timeouts when you call the service. That timeout is probably due to a performance bug. If you understand how these systems are connected in QA and if you know the process well, you’ll avoid hours or days of triaging, trying to figure out why your tests are intermittently failing.
KPA 2: Environment Demand Awareness
Next up we have environment demand awareness. This is not about how much load is on your environments. It’s about why you have those environments. Ideally, you should know who’s using them and why. Some environments may have obvious uses, like development. However, other uses may be surprising.
Take QA for example. I was once on an engagement where we developers thought it was our job to test out new features before we released to production. So we kept changing the setup to suit our needs. Eventually, a flock of business analysts came our way, yelling and waving their arms for us to stop. It turned out that many of our customers used QA to test out significant pieces of data before they staged into production, and we were deleting their hard work. Knowing who’s using your environments and why will prevent these kinds of things from happening.
When you know who’s placing demands on your environments, you can also plan better. You may know of a new group of users coming in the pipeline. Or perhaps your environment is taking a hit from many users at once. If you realize you have two different sets of users in that environment, you can split that environment. You can even tailor each environment depending on those users’ needs.
KPA 3: Environment Planning & Coordination
Once you know who’s connected to your environments as well as who’s making demands of them, you can plan for their needs and yours. It’s key to be able to consistently plan and roll out environmental changes to meet upcoming milestones across your enterprise.
Imagine if one of the product team members decided to load test their catalog system and generated five million fake products in their QA environment. This ripples forth to your QA, and none of the purchasing testers can actually do any work. This in turns clogs up their deployments and delays your ability to launch. We can avoid these types of problems with good planning and coordination.
It’s also important that your planning and coordination is consistent across teams. When you have a consistent process, all the teams will know when to share knowledge and when to synchronize efforts.
KPA 4: Environment IT Service Management
It’s not enough to deliver and manage your environments. Since you have users who demand these environments, we need to put on our customer service hat and support their ongoing use. We should diligently manage incidents, changes, and releases to ensure our users are getting what they need. If we neglect the ongoing support and operations of our users in these environments, the piling amount of incidents and user demand may threaten to overwhelm us.
When we spin up a new environment, we need to ensure the appropriate teams own it end to end. They need to have the necessary tooling and operational support to maintain this environment for its entire lifetime. This means well-understood communication on incident resolution and criticality. And it means well-understood processes to manage changing environmental needs.
KPA 5: Application Release Operations
Alright, this one gets a little tricky. It’s healthy to have consistent and repeatable processes across your enterprise for releasing applications. But it’s an easy risk to read this and interpret it as “standardize your deploys.” I want to be clear: application release and deploys are not the same things.
Your deploys are all about getting packaged source code to the right place. But application release is about exposing new functionality to customers. At the lowest maturity, this happens only during deployment. But with mature teams, we can use tooling and processes to separate the idea of deploying code from activating it for customers.
This means you want to ensure your software teams are equipped to continually deliver code to production and to do it in as automated a fashion as possible. Once your teams are doing this, we can shift our focus to how to activate—or release—this code to our customers. There are many tools to help you make this change. It’s this process that you want to standardize across your organization. That way, customers know what to expect, and they’ll understand how to check if new features have arrived.
KPA 6: Data Release & Privacy Operations
Let’s talk about another key performance area: data release.
Data release across your environments is just as important as application release. But it’s often neglected. Each application team ideally owns its own data, but teams need to be explicit how they manage that across their environments.
Time for another story. I knew a team that was quickly delivering high-value financial software, but they depended on a few backend services. Some of these services had a data refresh that occurred once a quarter or so. However, they didn’t make this known to the team, so the team had set up their QA environment with a test bed of data to give them a speedy turnaround time on user stories. This data refresh hit them like a punch in the gut. It killed their velocity for weeks.
It’s healthy to avoid such problems in your enterprise. We want to ensure data release processes are well known and consistent across teams. It’s also a good idea to automate as much as possible to ensure this consistency stays intact, letting our teams work on more valuable efforts.
KPA 7: Infrastructure & Cloud Release Operations
In the same vein as data releases, infrastructure releases have an indirect but profound impact on your teams’ applications. How you handle your infrastructure has a ripple effect across multiple applications. If managed well, you can provide a cushion of protection for software systems to run and fail in isolation. If mismanaged, it can bring down a whole ecosystem of applications.
One would think I’d be out of stories by now, but I have another: I was on an engagement at a Fortune 10 company that, as far as I know, is still mismanaging their infrastructure releases. They built an in-house cloud platform from the ground up, but they didn’t consider their environmental demand, nor did they create an automated and repeatable system. They instead created a system that requires every application team on it to move every few months. And every move brings with it different problems. They provide no tooling to automate this move. At one point, they would consistently lose a data center every week for three weeks straight. Not only was the platform unstable but it also actively hampered application teams from delivering because they were too busy migrating their infrastructure.
There are many tools to help us manage this effectively. We can take advantage of external cloud platforms. We can practice infrastructure as code principles. Also, we can use configuration management tools to ensure our environments are consistent and we can always go back to a fresh state.
Think of your infrastructure releases as a bed frame, and you want your software teams to feel like they are lying on a comfortable mattress, not a bed of rocks.
KPA 8: Status Accounting & Reporting
Complex systems are quickly becoming table stakes in the world of IT. This complexity makes it harder and more valuable to stay on top of your system health and behavior. Yet the faster you can make decisions about your systems and react to problems, the more competitive you will be.
Throughout your teams, you want to ensure you have ways of understanding team health. That way, you can support troubled areas. You want to monitor system health so that you can triage and fix defects before your customers even know. And you want to get real-time data on your system behavior so that you can react faster than your competitors and get new features out quickly.
This is connected with the infrastructure release key performance area, as you want to equip your software teams with standard tooling to accomplish all of this. The more consistent your tooling, the more you can aggregate data and see behavior across multiple systems.
Multi-Dimensional Success
Getting a handle on these key performance areas across your organization is a potentially tough but worthy endeavor. Mismanaging any of these will cause pain, but handling them well will create a cohesive, value-focused set of teams.
Ready to take the next step? If you’re feeling confident about your environments or you’re just curious, go ahead and calculate your environmental maturity. The results will give you insight into what area most needs your attention.
The Author: Mark Henke.
Mark has spent over 10 years architecting systems that talk to other systems, doing DevOps before it was cool, and matching software to its business function. Every developer is a leader of something on their team, and he wants to help them see that.
