Hi All,
As we start to model our business in the tool, running into some areas that require a bit of thought, perhaps two questions with a similar theme, which is "How granular should we be?".
1. Application Services
As we map out the application estate, we run into the situation where an application needs to have the services it provides described to make various reports function (and to answer the relevant questions).
My question is what was the intention in how this was to be used? and how are people approaching this? Calling the services more generically , or more specific in terms of the context an app is being used in?
For instance,
Does ServiceNow provide :
* Case Management Services
or does it provide
* Incident Management Services
* Problem Management Services
* Configuration Management Services
If the former, then it's perhaps easier to see where else ServiceNow may fit - or other applications providing similar functions
If the latter, then easier to see potential duplication, but not the nuances?
Is this a case where I should also be using Application Capabilities to 'summarise' the services?
2. Business Capabilities
In a similar vein, we could decompose capabilities to almost a 1:1 relationship with processes - however in doing so we end up with the challenge of knowing which capability to attach a process to. Presumably keeping things high-level and using processes to decompose is better in this situation?
As an example
InfoSec Operations
* Security Incident Management
** PII Security Incident Management
** Major Incident Management
Is anyone decomposing to this level?
C.
Granularity of Classes
Hi,
For Applications, we generally recommend using Application Capabilities for high level grouping (e.g. Case Management) of functionality and Application Services for the detail (Incident Management Services etc) that provides context, for example "When Organisation X performs Process Y, they use "Incident Management Services" provided by Application B". In addition, we also have Application Functions that can be used to Application Services down into their individual functions, However, we rarely see organisations model to this level of detail.
For the Business Layer, your presumption is correct. For various reasons (e.g. maintainability), we do not advise decomposing Business Capabilities down to a the level where they are effectively 1:1 with Business Processes. We have seen a few organisations attempt to model to that level of detail, but they very quickly realised that this level of granularity provided very little value for the effort required to maintain them
On a separate, but related note, If there is a need to model different Business Processes that are effectively variants of the same process, then we would recommend using the logical Business Process Family class to group them.
Regards,
Jason
For Applications, we generally recommend using Application Capabilities for high level grouping (e.g. Case Management) of functionality and Application Services for the detail (Incident Management Services etc) that provides context, for example "When Organisation X performs Process Y, they use "Incident Management Services" provided by Application B". In addition, we also have Application Functions that can be used to Application Services down into their individual functions, However, we rarely see organisations model to this level of detail.
For the Business Layer, your presumption is correct. For various reasons (e.g. maintainability), we do not advise decomposing Business Capabilities down to a the level where they are effectively 1:1 with Business Processes. We have seen a few organisations attempt to model to that level of detail, but they very quickly realised that this level of granularity provided very little value for the effort required to maintain them
On a separate, but related note, If there is a need to model different Business Processes that are effectively variants of the same process, then we would recommend using the logical Business Process Family class to group them.
Regards,
Jason
