Business Application/Application Service realtionship best practise

[1__Fredrik_CSDM]

Hi

We will soon replace our existing ITSM tool with the ServiceNow platform in which we will also use the IRM/GRC module. Our hope is that the new platform will be able to help us streamline the many and expensive governance, risk and compliance related activities that revolve around our +1000 IT systems. We are considering taking the opportunity to consolidate the systems in connection with introducing them into CSDM 4.

In the example attached, we have two systems that have in common that they only support the management of deposit accounts but in different ways:

1. System XXXX which implements branch applications for the bank branches' administration of deposit accounts,          e.g. opening a new or closing an existing account. These are only used by our bank branch employees.

2. System YYYY which is a deposit ledger with a database and all the services that a ledger needs to provide. These          services are used partly by system YYYY but also by several other systems of the bank that need to be able to retrieve account information (e.g. account balance) but also be able to perform other activities such as opening accounts.

Both systems are operated on IBM's mainframe z but in completely different operating environments (Java in WebSpere and COBOL in IMS).

We are considering consolidating these into one Business Application which will then represent the total of the two systems XXXX and YYYY. This Business Application (YYYY Deposit Ledger) will have relationships to two different Application Services; XXXX Branch Applications for Deposit Accounts and YYYY Deposit Ledger so from an operational perspective they will continue to be managed separately.

(In addition to the above, we will also relate our Business Applications to Business Capabilities and Information Objects.)

What should we consider when doing this?

 

[Marshall Parker]

When you are looking at a consolidation effort to reduce your Business Application footprint it is helpful to take the OOB definition and ensure you have a standard that works for your organization. Being able to have a quick reference to review helps answer "Is this a Business Application?"

For reference: What is a Business Application? (is a helpful ServiceNow article that goes into depth on this topic)

Once you have a good point of view, some tips in designing a consolidation structure:

• 1 Business Application may consume 1 or more Application Service(s)
• 1 Application Service should only be consumed by 1 Business Application
• If 2 Application Services appear that they collapse into 1 Business Application, ask:
  • Do both of these roll-up to the same set of Business Capabilities?
  • Do both of these roll-up to the same organizational owners?
  • Are they running in the same type of platform / code base [more important when/if you implement APM or EA Workspace]?
• Further, as you prepare to expand into a Services view of the world instead of an Application view of the world when you introduce Technical Service & Business Service, some of these systems may be a good idea to ask - is this even an application (Deployed stack of software and infrastructure), or is this a service that is fulfilled by applications, processes or people?

[1__Fredrik_CSDM]

Thank you for your insights!

[Mathew Hillyard]

To add to Marshall's reply, think of the Business App as the implementation-agnostic representation of some form of application technology that provides one or more business capabilities and can fulfil one or more business processes (note that Business Process is a field on Business App but this doesn't reflect reality as big apps often provide multiple processes). The App Services are instantiations of that technology in a given environment or geography.

For complex technologies, how to they relate to one another? For a platform there is the option to create a PLatform Host and then relate the Applications that run on it to that Host.

In terms of app to app relationships outside of a given technology, there are two options:

1. Link App Service to App Service (sends data to/receives data from or depends on/used by depending on the relationship type).
2. Use Digital Integration Management, where you can define APIs and interfaces to track the flow of information in your technology ecosystem.

Also, when planning building out such service maps be very clear which attributes belong on which table. It's a common problem that support/operational attributes end up in Business Applications instead of inside an App Service or Service Offering.

I hope this helps!

Mat

[1__Fredrik_CSDM]

Thank you for your insights