![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Yes, indeed, you've got the weight of the world on your shoulders -- that is, if you're in operations. Like the famous Atlas of Greek mythology, everything falls to you in the end. All the other teams have the opportunity to play with new toys, but you must make it work and deliver the promises other groups have made in your name. This is your mission. This is also the reason why your services must be structured through a defined architecture; otherwise, mayhem will ensue. Nobody wants mayhem in information technology (IT), although for many organizations, mayhem is a way of life. Everyone goes off to do their own thing, operations teams don't communicate with each other, or worse, they implement tools without regard for other teams' needs -- tools that invariably are incompatible with others and cause even more woes.
You can find several examples. Some deal with IT teams themselves, especially teams that are from different schools of thought: Linux® or UNIX® against Microsoft® Windows® or vice-versa. Others deal with the customers that IT teams service -- their user base. One example is the way IT "gurus" often treat users. Users just don't get any respect. Phrases such as "User is a four-letter word" or "Code 18: The problem is 18 inches in front of the screen" are all too common in IT circles. Why is that? Is it job security? Why do IT personnel still, today, in the twenty-first century, think of themselves as a different breed, a breed with arcane knowledge, and that users should bow down to them whenever they run into them in office corridors? If you've learned anything from this series of articles, you should know that IT is a service, and as a service provider, your job is to provide the very best quality to your customers: the users. If a user has a particular problem with something you just delivered, it may very well not be the user's fault. Perhaps -- just perhaps -- you might have forgotten about that one little thing that goes beyond just basic service delivery, the edge that would provide true quality.
Like all other architectures, the operations architecture must run through the 10 steps to complete its design. The first step is the vision. In this case, it should be, The weight of the world on our shoulders. While you might think this motto is depressing -- everyone relies on you, and only you, to do everything -- it is, in fact, quite positive. Operations teams are heroes that everyone can rely on to make things run smoothly. That is, because like Atlas of old, the operations architecture supports all other architectures, as Figure 1 shows. If the operations teams perform their work properly, business runs smoothly and IT becomes an enabler instead of a show stopper. This is the true purpose of IT.
Figure 1. The role of the operations architecture
So, how do you get there? One of the first aspects to work on in this architecture is team roles. This means focusing on step 5: identifying the principal actors in the architecture. Operations teams consist of personnel who play several different roles in the organization. Depending on the organization's size, the same person may be playing several different roles, but it is still important to identify the roles that are required to ensure that nothing is missed. Organizations that have successfully transited to an enterprise architecture -- one that relies fully on a proper operations architecture -- have introduced the following team roles:
- Project management
- Process management
- Business relationship management (BRM)
- Technical architecture
- Desktop operations
- Server operations
- Network operations
- Security operations
- Services administration and coordination
This list of roles is not exhaustive, but organizations that use these roles in conjunction with others have better success with their operations teams. Four roles stand out as essential. Project management is absolutely required, especially in today's project-oriented business world; someone must coordinate the actions of the team as a whole. Process management is also essential. This role works closely with the business to analyze and understand what business actually needs, which tasks it must perform, and how the tasks flow together into an integrated workflow. The process management role is also responsible for identifying target technologies in support of the business requirement. The person or people playing this role must be intimately familiar with the business architecture.
BRM is the next critical role. Operations personnel interact with users on a regular basis. Having someone responsible for these interactions, especially someone whom users see as being "on their side," greatly facilitates these interactions; this person is a kind of operations ombudsman. Familiarity with the business architecture is also an asset in this position. Finally, the technical architecture role is one of guardianship and is responsible for the integration of any new process into existing technologies and architectures. Close familiarity with the infrastructure and the integration architectures is an asset in this role.
These four roles help organizations make the transition from business need to day-to-day operations and help control the proliferation of technologies and technological solutions in the infrastructure. They also help realign operations from an IT-centric view to one of customer service and integration into the business as a whole. Yes, it's true: IT is not an island, but it is part of a larger landscape.
It is also important to understand that operations is responsible for the support of all architectures. Most commonly, this means supporting the infrastructure, development, and integration architectures, because each of these architectures requires constant and controlled operation to function. One common failing is the lack of support for the integration architecture. In fact, it is operation's responsibility to provide access to this architecture to all who need it. Operation's customers are not only business users but also other IT personnel. So, for example, when a new project begins, operations would be responsible for guiding the new project team through the entire integration process, beginning by providing them with initial machine images for unit development and testing, providing guidance on machine use, helping the new team set computers up, identifying acquisition requirements, and supporting the team when issues arise. From there on, the operations team will lead the new project team through each level that makes up the integration architecture and, eventually, into production.
Operations is not only responsible for building and delivering production machines but also for building and delivering preproduction systems. In addition, these preproduction systems must be integrated into the ongoing maintenance that the operations team performs for production systems. Finally, the operations team is responsible for the coordination of activities, especially when project teams must coexist in the shared integration environments.
Operation's tasks are not only technical but delve into the realm of administration, training, and communication. Once again, it is the communication aspect of this team's responsibilities that can help make or break it. The best way to ensure that this aspect is successful is to ensure that proper message flows move throughout the team and between the team and the other groups with which operations must interact (see Resources). In addition, it is important to make sure that the support infrastructure on which operations relies is up to date (see Figure 2), since it is one of the most common communications interfaces that operations personnel use with users (see Appendix: Move to twenty-first-century support).
Figure 2. The synergy of usage support and problem management
Reviewing the operations architecture, making changes, and moving on to implement the full, seven-part enterprise architecture is no easy task. But the benefits of this approach are clear: You will know and understand your business much better, you will forge links among the various teams that make up your organization -- technical and nontechnical teams -- and through this effort, you will work at delivering an IT service that meets and exceeds world-class service levels. Nothing need be complicated or overstructured; everything should rely on common sense and straightforward approaches toward problem resolution.
No, it's not going to be easy, and no, it's not going to happen overnight. We're on our way through the twenty-first century -- a time when all of us thought we would have flying cars and talking refrigerators. Well, the talking fridge isn't too far off, but the flying cars just aren't happening, yet. Isn't it time that we moved to a new outlook in IT and got rid of our own dinosaurs? IT professionals are not a breed apart. There is nothing arcane about IT, and there needn't be. We are here to provide a service, and we must make sure that it is the very best we can do. That's it. Simple, isn't it? Try it. You'll see. There is no way your business can suffer if simplicity and interaction are your goals.
Appendix: Move to twenty-first-century support
Modern support infrastructures include structured approaches to technical support. This involves using the right toolkit -- both technical and procedural. Even if the number of support issues remains constant, users have a better experience with the support team, because they are informed during the course of the resolution of the problem. Even if the resolution rate hasn't improved, at least it appears to users that it's more controlled. Some tools you can rely on to make all this happen include the following:
- Remote Control - Organizations must use some form of remote control for internal problem resolution. Operating systems today, including Windows and Linux distributions, offer integrated remote assistance or remote control technologies. This means that in large organizations, there will be fewer personal interactions among support personnel and users. One way to mitigate this is to use a conferencing technology internally. Even if no face-to-face communication occurs, the ability to share information through conferencing technologies helps facilitate the communications process.
- Call management software - Organizations that put in place a call-management system typically have a shorter problem-resolution time. This system need not necessarily be based on a complex commercial call-management system. It can be as simple as relying on free collaboration tools. Simply set up a collaboration Web site particular to call resolution, and use it to track and monitor calls. In contrast, larger organizations will want a commercial call-management system, especially one that they can integrate into a larger system-management product. Such a system helps inform the support professional about both system configuration and problem history for the system at hand when a problem arises. One of the most important aspects of this type of system is search -- being able to search the problem database for previous resolutions, ensuring that solutions are not invented from scratch each time the same problem occurs.
- Call status tracking - When problems take longer to resolve, users need to know the status of their request. Every organization that publishes call status information on the company intranet has better client satisfaction rates than those that don't.
- Server status monitoring - Organizations that have some form of server monitoring system in place will also benefit from shorter problem-resolution times. When your monitoring system warns you of potential problems, support personnel can often address those problems before users are even aware of them.
- Critical server status - Organizations that publish the state of their critical servers in e-mail messages and the like also have better customer satisfaction, not to mention fewer help desk calls for known problems. The information presented to users on the status of critical servers should include the current state of the server, its long-term maintenance schedule, and the status of any ongoing issue. Users should also be trained in problem identification. It users have problems with their e-mail clients, they should know to first check the server status page, then move to contacting the help desk, if necessary.
There is no doubt that maintaining a dialog among users and support teams is a major contributing factor to reduced problem-resolution times as well as reduced problem reporting. But communication doesn't address one of the most important aspects of user support: training. The current trend toward self-support does not meet the demand. Organizations that rely solely on this mechanism for user support fail at this critical task. Why? Because users usually rely on the following scenario:
- The user relies on the application's internal help system.
How many of you are able to find exactly what you're looking for when using a system's help? You typically have to know the exact key word required to draw out the information you need. Worse, the system asks you to rate the most useless answers it provides you.
- The user relies on Internet search tools to attempt to find the answer
online.
Once again, the user achieves success only if he or she asks the right questions.
- Invariably, the user -- up to 70% of users today, according to our research --
turn to a coworker or peer to see whether that person knows how to fix the
problem.
If this person does not know the answer, more peers will be drawn in. The next thing you know, instead of having one person who is no longer productive, you have several. Who can afford this?
Because this process is the natural reaction of many users, perhaps the best way to deal with it is to make this solution official. This means identifying key personnel in each office -- personnel who can become application agents throughout your organization. Then, provide these people with more advanced training in each area in which your users will require help. The best way to identify these areas is to rely on the data captured in the problem-resolution tracking system. Provide custom training to these agents, and make sure that your users are aware of who they are. One group of users often stands out as being the ideal group for this task: the secretarial or administrative staff of the organization. By default, they know more than others, because they are often faced with accomplishing tasks that no one else has had to perform. In addition, they are a natural point of contact in the organization. Slightly modifying their duties can easily transform them into the first line of defense when it comes to system support.
No magical solutions exist for problem resolution in any organization. But you must start by making sure that all your architectures flow together into one unified whole. When it comes to operations, look to the proper toolkit, and don't be afraid to enlist other parts of the organization and engage them in your common goal: making your organization's business run as smoothly as possible. Problem management and usage support are part of the same whole.
-
Stay current with
developerWorks
technical events and webcasts.
-
Read "Chapter 8:
Communications in an Enterprise Management Framework," a sample chapter from
Preparing for .NET Enterprise Technologies.
-
Participate in developerWorks blogs
and get involved in the developerWorks community.
Danielle Ruest is a senior enterprise IT architect (EITA) focused on people and organizational issues for large IT projects. Danielle has been involved in the design and support of complex collaboration implementations, including deployment of technologies for e-mail, team sharing, and secure instant messaging. With her partner Nelson Ruest, she is the author of Preparing for .NET Enterprise Technologies, (Addison Wesley, 2001). and Windows Server 2003: Best Practices for Enterprise Deployments (McGraw-Hill Osborne, 2003) and participates in many webcasts and conferences. You can reach Danielle at architectures@reso-net.com
Nelson Ruest is a senior enterprise IT architect (EITA) with more than 20 years of experience in migration planning and network, computer, server, and overall solution design (including MCSE, MCT, Microsoft MVP Windows Server). He has been a computer operator, a systems administrator, a trainer, a help desk operator, a support engineer, an IT manager, a project manager, and now, an IT architect. He was recently named a Microsoft Most Valuable Professional for the Windows Server product line. You can reach Nelson at architectures@reso-net.com.
