16 December, 2020
25 November, 2020
19 November, 2020
28 October, 2020
27 August, 2014
Business Services: What are they, really?
The TOGAF 9.1 Metamodel has a box that is in the center of the diagram called: Business Services”. Quite often I’m asked: what do we mean by “business services”? Looking at the specification and the definition, we find the following definition: “Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.”
Right, we understand that business capabilities help us to identify what are the services that the business needs with a certain level of granularity, to enable business agility, to be implemented by IT but it does not really explain what it really means and how you identify them. Business capabilities align perfectly with the notion that a service, in the Service Oriented Architecture (SOA) sense, is a black box whose implementation is encapsulated behind a standard interface.
In the SOA section of the specification, you also find:
“A Service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.) and:
■ Is self-contained
■ May be composed of other Business Services
■ Is a "black box" to consumers of the service “
The questions remains…What, exactly are these Business Services, how do we identify them, and what is the right level of granularity?
In ArchiMate 2.1 we also do have a definition which is probably more detailed, saying: “A business process, business function, or business interaction may realize a business service”, but that does not answer our question: What, exactly, is a Business Service?
A Leads Management System would likely implement a number of Business Services (e.g. Lead Identification service, Prospect Identification service, etc.) that would be accessed by the sales person (as part of the sales process). To gain access to functionality in a service-oriented architecture, one would just need to be aware of the set of services (and not of the underlying applications/systems).
Business Services are also more business-friendly in the way they are represented. A Business Service characterises a unique "element of business behaviour" in terms of a "business activity ", undertaken by a "specific role" that together support a specific "business goal ".
Now, are Business Services within TOGAF similar to the ones in ArchiMate and SOA services?
Starting with Business Processes
As a starting point, we can focus on the business processes from the process landscape comprised of core and noncore functionality. These processes can usually be represented at various abstraction levels referred to as process levels in a process model (e.g. descriptive, analytical/operational, and executable).
Business services can then be identified and extracted from these levels with a top-down approach. Higher abstraction levels provide inputs for composite Business services, while lower levels provide inputs for fine grained candidates. Such a focus on processes and Business service candidates would also help identify functional redundancy across the enterprise.
Still the results from such approach may differ from one organization to another.
A Business Service is characterized by a unique "element of business behaviour" in terms of a "business activity ", undertaken by a "specific role" that, together, support a specific "business goal”. Below are some examples of Business Services. Two are for an Insurance Company and one is for a Bank:
Example 1 Insurance
► Business capability
All these concepts may be linked to the individual entities (the boxes) described in the TOGAF Metamodel.
The business service “Customer Contract Creation” supports the business function “Contract Management” (and is an integral part of the business capability “Customer Contract Management”, not shown on the diagram).
In this example, the customers are internal, because the “Contract Management” function is a supporting business function which may provide a “Customer Contract Creation” business service to several business division of the Insurance Company. Sometimes, the customers of the business function can be both internal and external; they may be considered as being shared business services. A Business Service relates to processes, information, capabilities and people.
Example 2 Insurance Company
► Business capability
Example 3 Banking Business Services (associated with Banking products)
► Banking Products
using a :
► Business Service
I have in these three examples identified the following Business Services:
However are these appropriate? Are they correct? Is this the right level of granularity?
The Service Model
Even if your chosen architecture style is not SOA, you cannot really face the challenge of properly identifying the right level of Business Services without considering a Service Model. We have increasingly seen over the last few years an increasing number of implementation of Business Services as SOA Services which are directly related to software capabilities. It must also be said that other communities, such as those focused on IT Service Management (ITIL), are also looking for additional clarity.
That Service Model should relate the Business Services to the Information System services from the TOGAF’s Application Architecture and then to the SOA and ITIL Services.
Business Services and SOA-ITIL Services are related, but indirectly.
A SOA service is not quite a Business Service because it is quite often a series of software patterns written by developers to provide information, transform data or do some calculations. It is a component providing a service which exposes an interface hiding the internal implementation technology. It is composed of three parts; a service class that implements the service to be provided, a host environment to host the service and one or more endpoints to which clients will connect.
An interpretation of an Information System (IS) Service as defined by TOGAF is: “The automated elements of a business service. An information system service may deliver or support part or all of one or more business services.” One possible interpretation is that a SOA service inherits from the IS Service and that a SOA service could be categorized as providing one or more results (process, access, application, information, services…etc.). A SOA Reference Architecture might be of benefit and should also be considered.
Another aspect to consider are the ITIL Services; “An IT service is made up of a combination of information technology, people and processes. A customer-facing IT service directly supports the business processes of one or more customers and its service level targets should be defined in a service level agreement. Other IT services, called supporting services, are not directly used by the business but are required by the service provider to deliver customer-facing services“. We could also imagine that ITIL IT services inherit from the same IS Service.
This model below illustrates a way of extending the TOGAF Metamodel to show dependencies between Capabilities, Processes, Product, Business Services, IS Services, SOA and ITIL services. A Business Service combines people, products, and process and technology resources for a specific process.
SOA services are provided by deployed software. ITIL (or IT) services are also provided by software and that is why we may also add the TOGAF architecture domains below the various levels of services.
Coming back to the Example 1 where we had
► Business Service
► ITIL Service
The SOA service will be a piece of software based on Data-Application-Technology architecture (eventually) using a reference architecture. That is why the TOGAF architecture domains have been added below the hierarchy of services.
ITIL IT services are of the general kind rather than SOA type of services. There also may be a relationship between an IT service and one too many SOA services.
From an Enterprise Architecture or ITSM perspective, Business Services are delivered to customers, supporting their needs, sometimes through the support of a business process or directly supporting a service or product delivered to the end customers.
Business Capabilities can deliver Business Services which may be supported by one or more ITIL IT Service(s), which themselves may or may not be realized by SOA services (depending on the choice of an SOA Architectural or not).
This is one approach (there are certainly others) which helps to clarify how to integrate these different type of services, specifically for TOGAF practitioners.
Thanks to Ed Harrington for having reviewed the text.
Right, we understand that business capabilities help us to identify what are the services that the business needs with a certain level of granularity, to enable business agility, to be implemented by IT but it does not really explain what it really means and how you identify them. Business capabilities align perfectly with the notion that a service, in the Service Oriented Architecture (SOA) sense, is a black box whose implementation is encapsulated behind a standard interface.
In the SOA section of the specification, you also find:
“A Service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.) and:
■ Is self-contained
■ May be composed of other Business Services
■ Is a "black box" to consumers of the service “
The questions remains…What, exactly are these Business Services, how do we identify them, and what is the right level of granularity?
In ArchiMate 2.1 we also do have a definition which is probably more detailed, saying: “A business process, business function, or business interaction may realize a business service”, but that does not answer our question: What, exactly, is a Business Service?
A Leads Management System would likely implement a number of Business Services (e.g. Lead Identification service, Prospect Identification service, etc.) that would be accessed by the sales person (as part of the sales process). To gain access to functionality in a service-oriented architecture, one would just need to be aware of the set of services (and not of the underlying applications/systems).
Business Services are also more business-friendly in the way they are represented. A Business Service characterises a unique "element of business behaviour" in terms of a "business activity ", undertaken by a "specific role" that together support a specific "business goal ".
Now, are Business Services within TOGAF similar to the ones in ArchiMate and SOA services?
Starting with Business Processes
As a starting point, we can focus on the business processes from the process landscape comprised of core and noncore functionality. These processes can usually be represented at various abstraction levels referred to as process levels in a process model (e.g. descriptive, analytical/operational, and executable).
Business services can then be identified and extracted from these levels with a top-down approach. Higher abstraction levels provide inputs for composite Business services, while lower levels provide inputs for fine grained candidates. Such a focus on processes and Business service candidates would also help identify functional redundancy across the enterprise.
Still the results from such approach may differ from one organization to another.
A Business Service is characterized by a unique "element of business behaviour" in terms of a "business activity ", undertaken by a "specific role" that, together, support a specific "business goal”. Below are some examples of Business Services. Two are for an Insurance Company and one is for a Bank:
Example 1 Insurance
► Business capability
- Customer Contract Management
- Ensure quality Customer Contract
- Create a Customer contract
- Contract Management
- Contract Management Process
- Contract Specialist
- Customer Contract Creation
All these concepts may be linked to the individual entities (the boxes) described in the TOGAF Metamodel.
The business service “Customer Contract Creation” supports the business function “Contract Management” (and is an integral part of the business capability “Customer Contract Management”, not shown on the diagram).
In this example, the customers are internal, because the “Contract Management” function is a supporting business function which may provide a “Customer Contract Creation” business service to several business division of the Insurance Company. Sometimes, the customers of the business function can be both internal and external; they may be considered as being shared business services. A Business Service relates to processes, information, capabilities and people.
Example 2 Insurance Company
► Business capability
- Insurance Claim Management
- Adhere to Insurance Policy
- Accept Insurance Claim
- Claim Management
- Claim Management Process
- Insurance Claims Acceptor
- Insurance Claim Acceptance
Example 3 Banking Business Services (associated with Banking products)
► Banking Products
- Current Account
- Overdraft Account
using a :
► Business Service
- Cash Withdrawal / Deposit
- May require several Application/System components based on the banking channel used by the customer: ATM, Kiosk, Internet banking, mobile banking, branch banking
I have in these three examples identified the following Business Services:
- Customer Contract Creation
- Insurance Claim Acceptance
- Cash Withdrawal / Deposit
However are these appropriate? Are they correct? Is this the right level of granularity?
The Service Model
Even if your chosen architecture style is not SOA, you cannot really face the challenge of properly identifying the right level of Business Services without considering a Service Model. We have increasingly seen over the last few years an increasing number of implementation of Business Services as SOA Services which are directly related to software capabilities. It must also be said that other communities, such as those focused on IT Service Management (ITIL), are also looking for additional clarity.
That Service Model should relate the Business Services to the Information System services from the TOGAF’s Application Architecture and then to the SOA and ITIL Services.
Business Services and SOA-ITIL Services are related, but indirectly.
A SOA service is not quite a Business Service because it is quite often a series of software patterns written by developers to provide information, transform data or do some calculations. It is a component providing a service which exposes an interface hiding the internal implementation technology. It is composed of three parts; a service class that implements the service to be provided, a host environment to host the service and one or more endpoints to which clients will connect.
An interpretation of an Information System (IS) Service as defined by TOGAF is: “The automated elements of a business service. An information system service may deliver or support part or all of one or more business services.” One possible interpretation is that a SOA service inherits from the IS Service and that a SOA service could be categorized as providing one or more results (process, access, application, information, services…etc.). A SOA Reference Architecture might be of benefit and should also be considered.
Another aspect to consider are the ITIL Services; “An IT service is made up of a combination of information technology, people and processes. A customer-facing IT service directly supports the business processes of one or more customers and its service level targets should be defined in a service level agreement. Other IT services, called supporting services, are not directly used by the business but are required by the service provider to deliver customer-facing services“. We could also imagine that ITIL IT services inherit from the same IS Service.
This model below illustrates a way of extending the TOGAF Metamodel to show dependencies between Capabilities, Processes, Product, Business Services, IS Services, SOA and ITIL services. A Business Service combines people, products, and process and technology resources for a specific process.
SOA services are provided by deployed software. ITIL (or IT) services are also provided by software and that is why we may also add the TOGAF architecture domains below the various levels of services.
Coming back to the Example 1 where we had
► Business Service
- Customer Contract Creation
► ITIL Service
- Service Name: Contract Management Service (which includes the contract creation)
- Service Description: This service provides to suppliers, such as carriers, ports, warehouses etc., quotes and agreement conditions; manages procurement and sales contracts, IP licenses, internal agreements, etc.; automates and accelerates the entire contract lifecycle, etc…
- Availability: 07:00 - 19:00 Monday to Friday
- Target Availability: 99%
- Backup
- Service Owner
- Service Representative
- Service Criticality
- Etc.
- Contract Creation Service
The SOA service will be a piece of software based on Data-Application-Technology architecture (eventually) using a reference architecture. That is why the TOGAF architecture domains have been added below the hierarchy of services.
ITIL IT services are of the general kind rather than SOA type of services. There also may be a relationship between an IT service and one too many SOA services.
From an Enterprise Architecture or ITSM perspective, Business Services are delivered to customers, supporting their needs, sometimes through the support of a business process or directly supporting a service or product delivered to the end customers.
Business Capabilities can deliver Business Services which may be supported by one or more ITIL IT Service(s), which themselves may or may not be realized by SOA services (depending on the choice of an SOA Architectural or not).
This is one approach (there are certainly others) which helps to clarify how to integrate these different type of services, specifically for TOGAF practitioners.
Thanks to Ed Harrington for having reviewed the text.
Subscribe to:
Posts (Atom)
