Day-2 operations is where the system generates an outcome for the organization. Thus, continually seek improvements in day-2 operations, to maximize benefits.
Day-2 operations doesn't necessarily refer to the 2nd day of operations. Sorry for being Captain Obvious here [sic] but let's clear this up. Once 'something' goes into operations, 'day 2 operations' is the remaining time period until this 'something' isn't killed or replaced with 'something else.'
When we look at the various stages in the life of a business process, application or an IT infrastructure, some people like to depict them as a recycle process. I believe this is because one tends to use the word 'life-cycle of an application' and somehow get trapped into believing the picture has to circle back to the beginning. The various stages usually move forward in time and do not take you back to the beginning.
Now let's call 'X' something that an organization or an entity requires - this could be either a business process, an application, or some IT infrastructure. Technically speaking, whenever someone envisions X, there is always a starting point - let's call it 'Day Zero'(Geek Speak: This is a hangover from high school physics where a starting point in time is usually T-Zero). Day-Zero may not be a single day: it is the time period required to come up with and document a complete set of requirements for X. These activities may include a high-level design, documenting and selling benefits to someone, writing business cases, seeking funding, etc.
The next step in the process is to build and set this up. Day-1 includes all activities that start from a detailed (or low-level) design to building, testing, coming up with any required processes and staff to support X for the benefit of the organization. In many cases, there may be some procurement activities involved here as well. Once it is installed, setup, configured and approved ('good to go') X is considered 'live' or 'open for business.'
From this point on, and until X is decommissioned, killed, retired or replaced, we have Day-2 Operations. This includes the set of activities to keep X running, caring for and feeding X so that it runs optimally, ensuring that X operates and delivers outcomes that match the original intent and expectation. Vuescan 9 5 11 download free. Monitoring utilization, ensuring availability, and cost optimization add to the usual housekeeping activities to keep X performing in 'tip-top' fashion.
As the requirements of the world around us change, it is up to the organization to decide whether tweaks or upgrades to X, that will invariably be required, are to be called an entire overhaul or merely an upgrade. If this is an entire overhaul, one may assume that X is decommissioned and replaced with a new system, Y. If X is no longer needed, then day-2 operations for X ends. If the new X is just an incremental improvement over the previous X, day-2 operations will continue and encompass all activities to incrementally improve X.
A quick side note: the concepts of 'immutable systems' where one tends to improve availability by not allowing changes but by always deploying new systems doesn't conflict with the above. The process of managing an immutable system becomes part of day-2 operations.
For most businesses, day-2 operations are repetitive in nature. But this is where the system is generating an outcome for the organization. It should, therefore, be natural to continually seek improvements in day-2 operations, one that delivers maximum benefits.
Day-2 operations is where the system generates an outcome for the organization. Thus, continually seek improvements in day-2 operations, to maximize benefits.
Day-2 operations doesn't necessarily refer to the 2nd day of operations. Sorry for being Captain Obvious here [sic] but let's clear this up. Once 'something' goes into operations, 'day 2 operations' is the remaining time period until this 'something' isn't killed or replaced with 'something else.'
When we look at the various stages in the life of a business process, application or an IT infrastructure, some people like to depict them as a recycle process. I believe this is because one tends to use the word 'life-cycle of an application' and somehow get trapped into believing the picture has to circle back to the beginning. The various stages usually move forward in time and do not take you back to the beginning.
Now let's call 'X' something that an organization or an entity requires - this could be either a business process, an application, or some IT infrastructure. Technically speaking, whenever someone envisions X, there is always a starting point - let's call it 'Day Zero'(Geek Speak: This is a hangover from high school physics where a starting point in time is usually T-Zero). Day-Zero may not be a single day: it is the time period required to come up with and document a complete set of requirements for X. These activities may include a high-level design, documenting and selling benefits to someone, writing business cases, seeking funding, etc.
The next step in the process is to build and set this up. Day-1 includes all activities that start from a detailed (or low-level) design to building, testing, coming up with any required processes and staff to support X for the benefit of the organization. In many cases, there may be some procurement activities involved here as well. Once it is installed, setup, configured and approved ('good to go') X is considered 'live' or 'open for business.'
