For the purposes of this article an Availability Requirement is any requirement that is not a functional, data or process requirement concerned with defining the periods when the solution can be used. This page was created in association with Smart-BA, provider of business analysis mentoring and distance learning programs.
In the simplest terms, the purpose of the Availability Plan is to ensure that all existing and future Availability Requirements for IT services can be provided cost effectively.
If 100% availability is to be guaranteed then the logical answer is yes. Does that mirror also need a mirror? And so on.). As a Business Analyst you could record the initial requirement, and in the first case wait for the conflicting requirements and in the second case wait for the designers to come up with revised costs.
As Availability Management has both reactive and proactive components, there are lots of data sources from which meaningful information can be obtained, and stored in the Availability Management Information System (AMIS). The Availability Plan is a living document that should be updated and reviewed regularly.
For the purposes of this article an Availability Requirement is any requirement that is not a functional, data or process requirement concerned with defining the periods when the solution can be used.
Most books deal with Functional AND Non-Functional Requirements such as “Writing Better Requirements” by Ian Alexander and Richard Stevens (Paperback - 17 Jul 2002)
Again, note that CASE and other analysis tools will often allow recording non-functional requirements explicitly in pre-defined or user defined sections.
This principle can be extended to the documentation of non-functional requirements at any level.
These requirements also need to be discovered and – as with any requirements – checked that they are not in conflict with other requirements – in this case such as availability. It is up to the project Business Analyst to mediate the resolution to conflicting requirements (for example in this case gaining agreement that the availability requirements refer to times excluding planned maintenance).
Of course some solutions do genuinely and with good reason want 100% availability (air traffic control for example) but even these will have cost limitations restricting the robustness of the solution: in reality 100% availability can never be guarantee d as the designers of the Titanic discovered! In these cases it is common to use "four nines (99.99%)" or "five nines (99.999%)".
As a Business Analyst you could record the initial requirement, and in the first case wait for the conflicting requirements and in the second case wait for the designers to come up with revised costs. The alternative is that the Business Analyst raises this common issue if and when it arises with those that generated it.
In the simplest terms, the purpose of the Availability Plan is to ensure that all existing and future Availability Requirements for IT services can be provided cost effectively.
Service availability is the most visible and measurable component of any service, or to put it more accurately – service unavailability is the most visible and measurable component of any service. Ensuring expected and agreed availability should be one of the key goals for any IT provider.
Aside from planned or past actions to address availability shortfalls as described in the previous section, the Availability Plan should also contain a list of all current actions (in progress). This information is important and should be aligned with other framework components (Change Management, Knowledge Management, Service Desk function, Service Level Management, etc.) in order to avoid any confusion or miscommunication; we want to avoid multiple requests to address the same issue.
Of course, the document should state roles, responsibilities, and responsible persons for updating the plan, approvals, and expected frequency of those activities.
Everything in life is subject to change, and the Availability Plan is no exception. If there are some changes in availability requirements, make sure they are listed in a separate section.
With Availability Management tied to Incident Management, producing Availability Reports and an Availability Plan should be fairly simple tasks, yet many organizations fail to recognize the value. As in any other similar situation, I believe that IT organizations are so deep in technology that they expect that same technology to resolve any issues by default. The truth is, more technology only brings more issues if it’s not managed properly.