Skip to main content

ITIL for BAs – Part VIII; What is Design?

A colleague of mine who is much wiser than I (that could be pretty much anyone!) defined “design” as “the art of tradeoffs”.

It is easy to “design” an IT solution for 100% availability, more than enough capacity, extremely secure, with all the functionality currently desired, etc. – and such a design would surely meet business needs!  But in most cases such designs are neither practical nor feasible and are thus empty exercises.  True design replaces thoughtless overkill with a prioritization of the dimensions of a solution in a way that reflects the solution’s intent.  That prioritization informs tradeoff decisions driven by the realities of cost and schedule.

In earlier posts I had discussed ITIL’s general coverage of Quality of Service (QoS) requirements.  In ITIL V3, the Service Design book covers five specific QoS-related processes that should be considered during design.  (The book also covers Service Catalog Management and Service Level Management, which we discussed earlier).  During elicitation, analysis, and solution investigation, it is quite important for the BA to engage IT, through these processes, to ensure that

  1. those QoS characteristics are properly prioritized relative to the solution’s desired business outcome (not just the business requirements, but the outcomes that ought to be realized by meeting those requirements), and
  2. tradeoffs between these various QoS requirements, functional scope, cost, schedule, and risk are rigorously rationalized

Capacity Management ensures “that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner”.  The consideration of “current and future needs” is at the level of specific applications and solutions as well as the overall IT infrastructure and organization itself (e.g., the possibility of mergers and acquisitions).

Availability Management ensures “that the level of availability delivered in all services is matched to or exceeds the current and future agreed needs of the business, in a cost-effective manner.”

IT Service Continuity Management supports “the overall Business Continuity Management process by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, data repositories, communications, environment, technical support and Service Desk) can be resumed within required, and agreed, business timescales.”

Information Security Management seeks to “align IT security with business security and ensure that information security is effectively managed in all service and Service Management activities.”

Supplier Management’s goal is “to manage suppliers and the services they supply, to provide seamless quality of IT Service to the business, ensuring value for money is obtained.”

ITIL V3 defines a “manager” role for each of the above processes. The more mature these processes and roles are in IT, the more IT is able to participate effectively with BA in

  • requirements elicitation and analysis
  • negotiation (since there will undoubtedly be times when the business asks for more than IT is presently capable of delivering)
  • solution rationalization

Furthermore, IT in and of itself is not in a position to make tradeoff decisions but needs the BA’s involvement in and knowledge of the requirements and desired business outcomes, in order to make those tradeoffs.

There is of course much more to design than is covered here, such as designing for manageability and supportability, planning the solution’s retirement, etc., and the Service Design book covers all of that and more.

The key takeaway from today’s post is (a) QoS requirements can and should be reflected in the IT’s organizational structure and capabilities and (b) omitting consideration of these QoS characteristics can open the business to significant risks.

How mature is your IT organization with respect to these design activities?  Do you and your fellow BAs engage IT early on in the requirements process?  Are there past cases where in retrospect that did not happen but should have? 

Please feel free to share your comments with your fellow readers.