Now, this process is often referred to as Software Sustaining Engineering. And this process of course includes the customer patching and updating, fixing, et cetera, that is involved in any software but also including the security levels and functions. We have to make sure that the software remains secure, and that's a multidimensional quality meaning that it operates with integrity, reliability, et cetera. But it has to be on balance with performance of the application itself. And we hope that this is what was built in and that our efforts are going to ensure that it will continue to operate correctly and evolve in an operationally positive and secure manner. So we're going to look at in more detail at the various tasks and functions that will help us accomplish this.

Now, through the monitoring of sustaining engineering, this must take into account the assurance aspects of reliable, resilient, and recoverable processing in our application or system while making sure that the evolutionary process that undoubtedly will take place, advances the software functionality with operational and functional security at place. Now, throughout the process, the assurance of the software security and integrity has to be maintained in accordance with the criticality of the application, the needs of the enterprise, and the function of the application itself.

Now, changes of course, can come from many different sources. If they originate within operations that lead to the retirement and superseding capabilities such as obsolete or flawed encryption algorithms and utilities, this is one definite source that has clear operational impact. We have to look at security policies because any change that we make may propagate a change to policies as well, and failing to review policies and revise them as needed means that there is an increasing disalignment between the application and user's understanding of what it is and how it will work and whether or not it's in compliance with the various practices and standards that we're part of its germination.

Now, these operational activities are also going to be invaluable and making sure that the application continues to function for both operations and security impacts at a positive level and that risk is being actively managed and mitigated on a routine daily type of basis. So in secure operations, we're going to have to have a plan that describes how the program is going to be operated. Now, this includes things like routine running of backups, routine processing of maintenance items, clearing it up, maintenance schedules, things of that kind. And this is all committed to a plan of operations that will invariably affect the Service-Level Agreement. However, in affecting the Service-Level Agreement, it becomes the routine way of the care and feeding of this particular program.

We're going to have to account for the various business cycles, of course, so that in performing the operations that we must, we're being mindful of those. And seeking to impact them as little or preferably at all, we have to regard the availability of our resources for these purposes, we have to look at services functionality, again with an eye towards what business cycles may be impacted by this and the overall capturing of elements introduced through the problem reporting and resolution process. There is a strategy that we have to put in place that leads to maintaining or increasing the stability and reliability of the program, and we have to have that same stability and reliability in the routine of activities that we're going to do in performing the operations that we're discussing.

Because we're trying to ensure very high levels of reliability and resilience that our user population has no doubt come to rely upon, this means we're going to have to have a smooth transition into the new application from whatever the old one was or the new one if there wasn't a predecessor. And we have to regard this as extremely important and that it has to be in place from day one.

So the aim of operations then, is to process the various following things: monitoring and ensuring correct and effective operations of the system in terms of what we do internally to maintain it as available and functional for our user population, we're going to have to have processes to identify any anomalies or deviations from what we considered to be quote, unquote, normal and when necessary, alert management to this, and then we're gonna have to document all the problems and incidents that occur during normal or other non-normal circumstances and capture user-originated requests for changes and then feed them into the change management process where suitable.

Now, looking at earlier generations of computer operations, this element of the workforce was typically not considered part of the overall change management process. Well, evolution and time have changed that, and now, they're very definitely integrated piece of the change management process. With the advent of client-server and distributed computing, the increasingly consumerist aspect of computing has evolved this role into, as I was mentioning, one of the primary sources originating changes. So what we've done is we've connected operations to the change process.

When we go through operations, one of the things we have to do is establish maintenance schedules, various types of availability frames, and we create the basis for the problem identification tracking through these windows of user activity. This in turn gives us a foundation for monitoring and tracking problems that occur and enables a much more focused approach for symptom observation and analysis of the conditions. Now, this may in turn, of course, lead to various changes if indeed it highlights that there is some, call it an imperfection or an anomaly or a malfunction in the software that requires a change, or if it is something that isn't present, not wrong but just not present, and we need a change to add a particular element of functionality.

Now, the logging of these events by operations starts a history. And this history is very important because it is the germination point from which a change will arise, usually, and how it arises will do much to inform the process that will follow that may ultimately result in a patch or a fix or upgrade type of an action and thereby, extension add to the baseline. So as we know a program is coming, we need to focus on what secure operations will be necessary to bring this new element in and make it conform to our processes for secure operations.

So we begin with organization processes because we want to map what the organization does to what we're trying to do so that there is an increased alignment between what we and IT do in accordance with what the business itself does. Now, this process will bring in compliance, and it will implement new practices to assure that the sustaining engineering for this software is in accordance with those missions and requirements. An example would be our observation and care about business cycles that the IT can have an impact upon if we don't plan carefully.

Now, this plan will lay out the scope and the tasks to be performed within it, what the intended results should be, any associated metrics for management reporting, and from this, we'll generate the various procedures, timeframes, schedules, et cetera, that will be used to make this process successful and on a negative scale, very, very low impact.

The strategic element is, it's going to perform tactically to ensure that the daily routines that we're going to do in operations, are gonna be executed in observance of more general activities and perhaps any special projects that may exist and could conceivably be impacted by what we're doing. So we need that feedback loop, what's going on, what's happening, who is it impacting, what sort of impact, et cetera, are things we need to capture so that we can ensure that ours results and any of these impacts, some of which may lead to changes in our schedules or operations activities or some that have produced very devastating impacts, loss of reliability, loss of functionality, et cetera or things that have done well, so that we can record those and make changes, where necessary, and when we have to escalate to management for arbitration or further response in action.

The additional actions that have to be taking place will include, of course, monitoring and control of this entire thing. Now, this means we have operations groups that are working and they're conducting any sort of activity prior to the release of software changes, to ensure fidelity such as informing the user population that something is coming. When it's coming, we need to inform the user group, in advance, that it is, inform them of various issues, training available, or other such things to prepare them for the birth of this new thing.

Now, the results of all this should be packaged up and given to whoever the authorizing officer in the organization is. And their support is sought with a formal sign off, for the decision to release to the general population. Customer support, of course, has to be in place as well. Now, this is going to be the typical user support providing information, providing problem resolution, guidance, training, or other sorts of support elements, and there needs to be a feedback loop to this as well because customer support needs to be supporting of customers, not just a blank spot in the organization that doesn't live up to the name, help desk. This can be very critical to the success of the application and acceptance. We have to make sure that this is well formed, well informed, and functional in the support that it gives because all of this is gonna be captured in a Service-Level Agreement which will be our contract with our internal-using population for what they can expect.