Guidelines for designing services

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

Building the service catalog

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

We recommend that you use the following best practices to align your services with the design goals and strategies:

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.

Guidelines for designing services

Design best practices

Comments