Operate Versus Change

Two Sides to the Coin

As Professional Manager in IT I am often charged with improving or “fixing” IT service delivery. The assignments vary from rescuing projects in trouble, improving dysfunctional departments, to re-aligning IT functions for vendor or client organizations. 

With every engagement I learn something more. Every engagement has something new to challenge. I am sad to say however, that the same recurring patterns are always present.

One thing that never cease to amaze me when I engage an IT team or organization is: IT People usually think that what we do in IT is unique. The particular problem is too complex, too difficult, too different, special and that is why it is so hard to solve it.”

How can it be that so many clever people together can get themselves so often into delivery trouble? 

However, when we stop for a moment and examine what we do, we find that it is not that different from other industries. In my experience, we can learn from how other industries, like the engineering and manufacturing industry organize and structure themselves for success. More about this later.

I can trace as much as half of IT service delivery problems to one key matter of confusion: The confusion between “Operate” and “Change”.

The one side of our business invent, design, change, improve, and create, and the other side of our business operate, support, maintain, and service. 

When an IT department starts to mix and confuse these functions, when the lines between Operate and Change is blurred, and when you find that the same IT Professional resources in the company is required to Change and Operate a solution, then you have all the makings of a successful failure in IT service delivery. 

One finds that the IT people working in these two distinctive areas of our business are quite different in their skills, personalities, the way how and what they do.

In this Blog, I will dwell a little on this key distinction. The distinction of “Operate” versus “Change”. I argue, that when we realize that there is two completely separate sides of our business, that requires completely different ways of thinking and operating, with different IT Professionals in each area, that we then have the foundation for delivering IT Services better.

This distinction also sets the scene for following Blogs where we will go into more detail on what each Role in IT does. You will have the opportunity to see what is expected from the Analyst role set, the Designer Implementer, Management and Operate and Support role sets.

Operate and Change

A simple analogy that clears up the confusion between Operate and Change can be found by comparing the motor industry value chain with that of IT Service. 

If a parallel is drawn between the IT industry and the motor industry it will be something like this:

• Requirements Management: In the motor industry the marketers interface with the customers to understand what they need and want from their next car. This enables the motor company to plan what features they will include in their next models, and it helps them to remain in touch with their consumer’s needs. In I.T. this is the job of the Analysts. They are there to sit with the client and understand what business and technical problems the client is trying to solve, what features and functionality they need, and how this will meet their objectives.
• Design and Build: In the motor industry, the customers’ requirements are then communicated to the engineers. These are the design engineers, the manufacturing engineers, etc. that is responsible for coming up with the next model vehicle in line with the consumer’s needs. Not only do they come up with the design, but they also design how it will be manufactured and distributed, and then do so. In IT the job of design and manufacturing is assigned to a Designer Implementer role set. This group of roles is lead by the Software Architect and includes, information designers, user interface designers, technical designers, test designers, and also the implementers, which include developers and testers. The job of these people is to come up with the product and to manufacture and distribute it.
• Operate and Support: The product is off the production line and in the showroom, and then the customer buys it and starts to use it. From here on the vehicle is in operate and support mode. It requires services at regular intervals to keep it operating optimally, it has onboard systems that monitor the health of the sub components, and it requires a tuning to keep it fast and fuel efficient. All this work is done by mechanics and technicians in the dealer network, and the customers interface with Service Management. If there is a failure of a system in the car, then a mechanic replace the system with a new one, but seldom, if ever engineer a better system. Rather, the failure is communicated back to the marketers/analysts and engineers, by the Service Manager so that they can provide a permanent fix for a consistent failure, or engineer a better component in the new model. In IT once the solution is in production, and being used by users, it is in the Operate and Support mode. Systems administrators service, tune and maintain it as per the instructions from the engineers, and when there is a failure in the solution, they are on point to restore the service by replacing failed components with replacement components provided by the Designer Implementers. IT Systems Administrators should never engineer a fix or a system improvement, because they probably will not have all the details on hand to do a good job. There is no way they can know all the details that went into the design and build of the solution in the first place. They put the system under further risk by trying to do this within a production state. The more complex solutions become, the more this is true. It is not to say that the engineers/designers will not value the inputs from the Systems Administrator, but ultimately the quality of the solution is the responsibility of the Software/Solutions Architect. The other role one finds in IT Operate and Support is the Support Analyst. This person, like the Service Manager in the motor dealer’s shop, is on point to interface with the users and address their concerns and complaints, and with the engineers to communicate any feedback for fixes or improvements that may be required to the solution. 

Requirements Management and Design and Build processes are part of the Change side of the IT business, and the Operate and Support processes part of the Operate side of the business. It is a simple distinction that requires separate staffing strategies, and that will make a world of difference to the quality of the IT service outcomes of your organization.

The “BAU” or "Sustainment" Problem

A terms that is often used in the New Zealand market, and I suspect in other countries too, for a solution that is already implemented and used. It is in “BAU” (Business As Usual) or "Sustainment". This is a term that is supposed to distinguish systems or solutions that are not yet in production from those that are used by consumers and requires regular support.

Change and Operate processes are grouped together under this term. Production systems are modified and improved (Changed) at the same time as it is maintained and operated, and mostly by the same IT people. When a problem is identified with the solution, it is quickly rectified by a change on the fly by whom ever is assigned to “BAU”.

Needless to say, this is where the wheels come off, all in the name of “BAU”. The moment the change processes are not separated from the Operate and Support processes, when the different responsibilities for the solution is not clearly delineated within a team, then the solution’s stability is at risk. You have a confused team and the users will know about it.

I am fast making a case in every organization that I engage to ban the term ‘BAU”. It is confusing to all involved, and it doesn’t provide value in delineating any IT processes.

I have often encountered unstable solutions, and on each occasion, I first had to intervene and clarify the roles and responsibilities of the team members along the Operate versus Change line, before we could focus attention on addressing system failures. 

And, each time I have done this, I have held two key parties accountable: Firstly the lead Software/Solutions Architect for the integrity of the design and build. Secondly, I hold the Systems Administrator accountable for the availability and service restoration of the solution. These two then work together, review each other’s work, and slowly the system is engineered back onto its feet in a controlled fashion. So far, each time with success.

Industry Frameworks

Never underestimate the importance of separating these two functions. When one analyze the standard industry processes as defined in ITIL and RUP, one finds that there is a clear delineation between process that operate and process that change.

Hendrik van Wyk