This documentation supports the 20.02 version of BMC Service Request Management.To view an earlier version, select the version from the Product version menu.

Guidelines for designing services

Before you start creating services, take the time to design your services so that they serve your users well today and into the future. 

When you design your services, consider the overlapping goals of maintainability, usability, and performance. Work towards balancing these goals to develop a reliable and extendable system, and to ensure a trouble-free experience for your users.

Related topics

Creating-services

balance_priorities.png

Goal

Desired outcomes

Design strategies

Considerations

Maintainability

  • Ease of maintenance
  • Infrequent changes
  • Consolidate lesser-used services into one service request definition (SRD)
  • Reuse components that do not need to be changed frequently
  • Minimize the number of entitlement rules
  • In your organization, would it require less maintenance to combine some services into one SRD? For example, could you consolidate lesser-used services or services that do not change frequently?
  • If you need to update a shared component, how many SRDs would be affected?
  • How easily are new users incorporated into existing entitlement rules? Can SRDs be grouped (for example, by using packages) according to the entitlement rules that should apply?

Usability

  • Simplicity
  • Responsive UI
  • High system availability
  • Present fewer questions to the user
  • Leverage auto-fill functionality to populate question responses
  • Limit query menu results by using qualifications
  • Use stand-alone SRDs for heavily-used services
  • How much time and effort does it take for users to submit a request? Are they able to answer questions completely and correctly?
  • How many results are returned when the user clicks a query menu, and is the number of choices manageable?
  • To reduce possible down time, are there some SRDs that are very heavily used and should not be tied to shared components?

Performance

  • Responsive UI
  • Fast processing
  • Successful processing
  • Use fewer conditional questions, and fewer levels of conditional questions
  • Limit query menu results by using qualifications
  • Reduce the complexity of process definition templates (PDTs). For example, limit the use of conditions, nested PDTs, and parallel application object templates (AOTs), and only create variables that you plan to use.
  • Limit the number of Open Form actions in each SRD, and make sure that:
    • Data you look up for all actions is indexed correctly for your database
    • Qualifications return a manageable number of results
  • Are too many conditional questions being processed, which increases the time needed to update the screen?
  • For the number of results returned when the user clicks a query menu, does network latency become a factor?
  • Does the PDT contain too many unused variables, conditions, and nested PDTs, which impact performance?
  • Are there too many parallel AOTs in the PDT, which can cause the system to exceed the filter limit and halt processing?
  • Do too many Open Form actions execute? Do queries return too much data or is the data non-indexed, which can increase the amount of time needed to display or update the Provide Information window?

Design best practices

BMC recommends that you use the following best practices to align your services with the design goals and strategies presented in this topic:

Functional area

Best practices

SRDs

Create no more than 1000 SRDs.

Questions

Include no more than 100 questions in a single SRD, including conditional questions.

Conditional questions

Create no more than 5 levels of conditional questions.

Query menus

Use effective qualifications to limit results returned; otherwise, results are only limited by the AR System server limit.

PDTs

Create fewer than:

  • 30 variables
  • 10 conditions
  • 6 nested PDTs
  • 20 parallel AOTs

Entitlements

  • Create one entitlement rule that includes everyone, and then apply exclusion rules for particular groups of SRDs or users.
  • Create SRD packages and configure entitlement rules for those packages.

Actions

  • Create no more than 3 Open Form actions.
  • Make sure that data you look up is indexed correctly for your database.
  • Create well-qualified queries to limit the number of records returned.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*