What IT Environments are Needed?

A great write-up by a third party articulating the different environments needed for a mature IT shop. What i think is missing here is Production FIX. This is the environment you develop / test in when the main environments have the next version of IT infrastructure, configurations or software.

There are typically three different environments in IT which have different roles. They tend to reflect the importance of that application/system to the end users.

1. Test/Development - used for the application developers to test their application code or new layered applications - they might have administration rights to the Windows/Linux servers in this environment.
2. Staging/UAT (User Acceptance Testing) - used for functional testing, should ideally be a replication of production. Once my code has been validated, it’s pushed to staging so that I can carry out due diligence and functional testing before I put the code/application into production. Access should be restricted so that code is validated in near production conditions.
3. Production - business affecting or user affecting systems, an outage therefore on these systems might damage our reputation or cause loss of revenue. Administration and security should be restricted in order to protect data and system reliability.

The idea is that by having the different operating environments you can limit any infrastructure or application failures through adequate testing which may include performance load testing.

[From What’s UAT then?]

Smart Weapon: The "Decision Bomb"

One of my co-workers coined a new phrase yesterday. "Decision Bomb". It is a carefully placed smart weapon of destruction which strategically targets confusion and results in a series of decisions which drive projects forward.

Starting yesterday afternoon I dropped a perfectly targeted "decision bomb" and this morning it struck home with perfect results. Today was truly a great day seeing a potential tipping point in the areas of demand planning, release concepts and code/environment management understanding.

Sometimes it is better to get something done then do nothing at all...

The title of the post sums up a current challenge at work. Sometimes folks get stuck in analysis land. I am just as guilty of this too. You see a big problem and you get wrapped up in getting the answer/analysis or process perfect, but loose sight of the goal. Sometimes, knowing 80% and going is the right thing to do. For some problems getting even close to perfect is better then not starting at all or heading down a contingency plan rabbit hole.

It is OK to make a mistake. My mantra for Monday.

Do you know your IT capacity?

What amazes me is how many IT shops have no idea of their capacity. They struggle with explaining to the business why they can't deliver consistently or in a timely manner. Amazingly enough all that is needed as a first step is a really simple capacity vs demand tool. It is quite simple really.

Take your total capacity in any given area.

Subtract out your administrative overhead and PTO hours for your staff.

What is remaining is your true capacity.

Then plot out your project hours by release, or month.

Compare your capacity to your demand and produce a chart. It will quite clearly show the problem and will be quite easily consumed by business leadership.

The next discussion is how to adjust demand and perhaps change scope or delivery dates. I will discuss more about this in another post.