Identifying Requirements for Operations Manager 2007
Applies To: Operations Manager 2007 R2, Operations Manager 2007 SP1
Identifying your company's requirements is the next step in your Operations Manager design process. The requirements can be divided into three categories: business requirements, IT requirements, and optimization requirements or goals. The requirements gathering step is the single most important step in developing your Operations Manager 2007 design. By having a thorough understanding of the requirements, you can then build a solution that is aligned with those expectations. If the project deliverable is not aligned with expectations, the project might not succeed.
To make sure that you have an accurate understanding of the requirements, you have to talk to different groups of people. To start with, you must understand the expectations of the key stakeholders and sponsors. If they expect Operations Manager to be able to do something that it can't, now is your opportunity to educate them and set expectations appropriately. You must also work with the groups that will use or consume data from Operations Manager. This means not only the helpdesk and application administration teams but also their management, who will likely be consuming the reports from Operations Manager and who will want to know the status of their application at a single glance.
After you have completed the requirements gathering, compile the data and then publish it in a public way for all the interested parties to see. This provides another opportunity to clarify capabilities. To further ensure agreement on the requirements, you can choose to have the project sponsors and key stakeholders sign off on them.
The business owners that you need to work with are not just the top-level executives who are sponsoring your Operations Manager project; they are the managers and directors who are responsible for the business processes that make your company money. They might not be particularly interested in Operations Manager as a product, but they are very interested in the level of service that IT is providing to support their mission-critical applications.
When you are having your discussions with people in these roles, their interests will likely center on four areas:
Ongoing service from IT
Performance information about their application
Return on IT costs
Ongoing Service from IT
What business owners primarily want from IT is to make sure that their application is up and running. If it is not, they must know immediately. They will want to know the impact of the outage on their business process and its expected duration. Understanding their business process is key to meeting their needs. In your conversations with them, make sure you understand these points:
What are the applications they use to perform operations that affect their core business? Knowing this identifies which applications you must provide end-to-end service monitoring for.
What are the components of those applications? Knowing this helps you build a distributed application model that you will monitor.
Does the application have a critical component that runs on workstations or other clients? Knowing this will help you plan your client monitoring strategy.
Have them describe a complete transaction in their application. Operations Manager 2007 can use synthetic transactions to regularly test an application, as well as provide monitoring data of the end-user experience with the application.
When you are discussing what the business owners need to know about application performance information, it is important to distinguish between business process performance and application performance. Business process performance (or metrics) are provided by business intelligence applications, usually in the form of reports and balanced scorecards, and are not part of this conversation. The expectations that you must understand here are those relating to application performance. Make sure you understand and discuss these points:
What application performance information are they receiving today? What would they like to receive? Knowing this will help you with role planning (profiles and scopes).
How are they receiving application performance information today? How would they like to receive it? Knowing this helps you decide how to provide access to the performance information. For example, do they need an Operations console with Read-Only Operator and Reports access scoped to their application, or would the Web console suffice?
Regulatory compliance is a critical issue with business process owners now and into the future. The business process owners look to IT to participate in the company's plans to achieve compliancy and to stay compliant. Be sure to cover these points:
Does the business process fall under regulation? If it does, what do the regulations state? Knowing this will help with your Audit Collection Service (ACS) planning and role planning.
What sort of data is the business process owner looking to IT to provide and for what time frames? This will help with reporting planning and data-retention planning.
Return on IT Costs
Either through direct charge backs or through an indirect overhead charge, the business owners are paying for IT services, and like all good business owners, they want to know what they are getting for their payments. You can use Operations Manager Reporting as a vehicle for providing these answers, but you need to know what it is the business owner finds value in. Be sure to cover these points:
What do they see as the most valuable services that IT provides to them? Knowing this helps with report planning.
Are they aware of what they are getting for their IT overhead now? Knowing this, you might choose to assemble different reports that demonstrate the services provided to the business owner that are outside of their application.
The IT requirements are going to drive the topology of Operations Manager and its supporting infrastructure. The two main factors that will shape your IT requirements are your optimization goals and the IT environment that Operations Manager will exist in. You will gather these requirements from IT sponsors, key stakeholders, and consumers of Operations Manager data. These conversations should consist of broad, open-ended questions on your part. Start by asking how Operations Manager should be used in the environment and what the implementation should be optimized for. Be sure to cover the following points.
Optimization goals are aspects of your Operations Manager implementation that must be met by the design. They are exemplified by statements such as the following:
Availability/Recoverability--Operations Manager must be available with minimal outages. Knowing this helps you with your high availability and backup/recovery planning.
Cost--Operations Manager must be implemented as economically as possible. Knowing and operating within the budgetary constraints is critical to the success of the project.
Performance--For example, Operations Manager must report data from the environment in no more than 1 minute and console access must occur in no more than 10 seconds after the console is launched. Knowing this helps with the hardware planning.
Scope--Operations Manager must provide a single view of the entire environment. Knowing this helps you with planning the number of management groups that will be needed and the relationships between them.
Administration--Operations Manager administration must be restricted (or available) to certain groups. Knowing this helps you plan security groups, roles, access, and potentially the number of management groups that you will implement.
Location of Access Points--Operations Manager data must be accessible only from within the company's intranet, or it must be available internally and externally. Knowing this helps you plan where Operations consoles and Web consoles will be made available.
Integration--Operations Manager must integrate with the existing trouble ticketing system or other enterprise-monitoring product. Knowing this helps you plan where Operations Manager and its features will fit in your environment and the role it will play. It also helps you decide if third-party connectors or connectors developed in house will be necessary.
Inventory of Current Environment
Getting an accurate inventory of your current environment helps you in two regards. First, it tells you about what Operations Manager will be monitoring, and second, it tells you the restrictions or boundaries it must operate within. Be sure to include the following points:
Scale--The approximate number of devices that will be monitored.
Management packs needed--The applications that will be monitored.
Type of devices that support the applications—This list includes Windows computers, network devices, and UNIX or Linux-based computers.
Topology--The physical and network location of the devices that will be monitored.
Topology and console distribution--The physical and network location of the people who will use Operations Manager data.
Certificate and gateway server needs--Your environment's Active Directory Trust boundaries.
Current Management and Helpdesk products--All other products that are used to perform monitoring, alerting, and reporting.
Topology and gateway planning--Firewalls and wide area network (WAN) links that define network boundaries.
Topology and role planning--IT administrative boundaries for monitored devices and applications.
Topology and localization--Language and geopolitical boundaries that your environment spans.
Inventory Current Procedures
In one way or another, all environments are monitored and managed. The techniques and technologies used to accomplish this vary in levels of sophistication and maturity. Following the Infrastructure Optimization Model, all environments can be described by using four categories: Basic, Standardized, Rationalized, and Dynamic. See the Infrastructure Optimization Assessment for more information about these four categories and a self-evaluation tool to provide an estimate as to where your process and environment lie.
To plan how the capabilities of Operations Manager 2007 will be used, you must understand the procedures that are used to monitor and manage your environment now. This will help you plan how alert information is responded to and who responds to it. It will help you plan how notifications are sent out and who receives them. It will help you plan out administrative control of management groups and data security.
Following are the main questions to ask in this phase:
How does my organization perform monitoring today?
How does my organization act on information provided by the monitoring process/system?
Also be sure to cover these points:
Who normally responds to issues or alerts that are raised by automated systems or helpdesk? Knowing this will help determine who needs direct access to the Operations console and what data the console should contain.
Does the help desk usually resolve server issues, or are issues passed to the server support teams?
Does the company have a manned Network Operations Center or other manned monitoring system in place? If yes, how many people and how many consoles are in continuous use? This helps determine where management groups can be placed so that they will receive adequate support.
How many locations other than datacenters will have agents deployed to them, and where are they on the network?
What are the available bandwidth statistics between the sites where managed devices are and the sites where the management servers are?
How is security logging performed currently?
How are desktop or client applications monitored currently?
How is monitoring performed for UNIX-based or Linux-based computers and network devices?