guidance for services and applications

Enterprise Architecture | Information Services | 2011 of 18Guidance – Services and Applications

Services and ApplicationsThis document is meant to accurately capture the position of several best practices frameworks with regards to the use of the terms Service and Application. Additionally, this document will attempt outline the relevant portions of Service-Now in an effort to support a comparison between the current state, the frameworks, and a set of recommendations.

ScopeOver the last ten or more years, the word “service” has become a commonplace word in IT. The maturation of both the management and engineering disciplines within the IT domain have led to an increasing attempt to leverage the economics analogy of a service– with a provider, consumer, and a medium for exchange – in order to structure ideas for everything from software interfaces to business contracts. In economic terms, since most of IT’s value is delivered as a service, rather than a good, it is certainly a fair use of the term. But with so many applications of the word, the varied contexts and purposes have clouded its definite meaning. As such, it is important to specify its meaning here. The uses of this term in this guidance are those which apply to management of IT. There is also a limited look into IT architecture as well, since this domain attempts to rationalize not only IT services but the components that support them, such as infrastructure and applications. The other uses of service in IT, such as those that would appear in software engineering – web services, for example – are not the scope of this paper.

Framework SourcesHere will be an examination of several frameworks – ITIL, IT Value Chain, CMMI-SVC, ArchiMate, TOGAF, and FEAF – according to terms and information which applies to Services and Applications.

ITIL v3The following terms apply to this domain and are provided here as a reference to the ITIL v3 documentation. These definitions are word for word duplications from ITIL v3.

Service – a means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.

IT Service – a Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the user of Information Technology and supports the Customer’s Business Processes. An IT Service is made up from a combination of people, Processes, and technology and should be defined in a Service Level Agreement.

Business Service – an IT Service that directly supports a Business Process, as opposed to an Infrastructure Service, which is used internally by the IT Service Provider and is not usually visible to the Business. The term Business Service is also used to mean a service that is delivered to Business Customer by Business Units. For example, delivery of financial services to Customers of a bank, or goods to the Customers of a retail store. Successful delivery of Business Services often depends on one more or IT Services.

Infrastructure Service – an IT Service that is not directly used by the Business, but is required by the IT Service Provider so they can provide other IT Services. For example directory services, naming services, or communication services.

Technical Service – see Infrastructure Service.

Application – software that provides Functions that are required by an IT Service. Each Application may be part of more than one IT Service. An Application runs on one or more Servers or Clients.


Service Catalogue – a database or structured Document with information about all the IT Services, including available for Deployment. The Service Catalogue is only part of the Service Portfolio published to Customers and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes. The Service Catalog has two aspects:

- The Business Service Catalogue containing details of all of the IT services delivered to the customer together with relationships to the business units and the business process that rely on the IT services. This is the customer view of the Service Catalogue.

- The Technical Service Catalogue containing details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business. This should underpin the Business Service Catalogue and not form part of the customer view.

Service Request – a request from a User for information or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests usually handled by a Service Desk, and do not require an RFC to be submitted.

The following is a representation of this author’s interpretation of the ITIL definitions and is an attempt to rationalize them into a coherent concept-level data model. For definition of relationship lines/shapes, see ArchiMate Relationships 1 .

Figure 1 - ITIL Service and Application Data Model

IT Value Chain2

The following terms apply to this domain and are provided here as a reference to the IT Value Chain integrated IT process management approach proposed by Charles T. Betz. They are not in 100% agreement with the ITIL model in the previous section, therefore any study of these terms should be done with a fresh perspective in an attempt to understand Betz’ view on the world. While this view has been informed by ITIL v2, it is Betz’ perspective that ITIL, CMMI, CobIT, and other related frameworks do not provide a holistic architecture – which is the aim of his IT Value Chain as well as the supporting data and systems models. All indented sections below are direct quotes from Betz.

1 ArchiMate v1.0, Chapter 8: Relationships http://www.opengroup.org/archimate/doc/ts_archimate/chap8.html 2 From Charles Betz’ Making Shoes for the Cobbler’s Children, 2007

http://www.opengroup.org/archimate/doc/ts_archimate/chap8.html




The Base Technology StackBefore discussing the particulars of the CI and its subtypes, some discussion of the general IT stack is called for.The concept of a “stack” has a long history in information technology, perhaps originating with the OSI networking model. In ITSM, an extended stack is often depicted something like the one shown below.

Business ProcessIT ServiceSoftware SystemDatabaseServerNetwork

Service – Service is a general concept with two major subtypes: Ordered Service and Application. Where the Orderable Service may be “provide email to new user,” the Ordered Service is “provide email to Peter Baskerville,” accompanied by the various workflow steps documenting the provision of that Service from start to finish. (In this case, the Service Offering is a Subscription.) A service is an instance of a Service Offering.Services may not depend on automation. The IT organization may provide a purely human-based Process with no Application involved; it may provide a Service based strictly on the availability and performance of an Application, or it may provide both—a Service based on the human execution of a Process backed by automated Applications. The Service aspect of Applications is distinct from Services focused on provisioning consumers. Provisioning consumers results in many Services for one Service Offering.

Service Offering – a Service Offering is a defined entry in the enterprise service catalog. It is a measurable and specific offering of the IT organization to external clients. It should be seen as a “logical API,” or application programming interface, of the service provider; everything behind it (in theory) may be opaque to the service consumer. Service Offerings are of two major types: Orderable Service and Hosting Service. (In this model, the Project orders the Hosting Service using a Service Request.) Service Offerings and Services themselves may be created by Projects. In effect, the Project can be seen as the Service Offering of “create new Service.”

Betz differentiates between a Service and a Service Offering, the first of which he considers a Production CI, against which Events, for example, can occur and he classifies the second as an Operational CI, against which Metrics can be specified and which would be included in a Service Catalog.


Figure 2 – Production CI and Operational CI Differentiation Figure 3 – Service to Service Offering Model

Figure 4 – Service Layering with Email Service Example

In order to better understand Betz on this point, included here is an example of an email service using both the Service and Service Offering concepts:

Service–Service Offering – a Service Offering may have many Service instances.

Figure 5 – Orderable Service Offering vs. Ordered Service

Probably one of the most striking aspects of Betz’ model is that he does not differentiate between Application and Service; the former is a more specific type of the latter.

CMMI for ServicesThe following are definitions for services and related terms from the Software Engineering Institute’s Capability Maturity Model Integration for Services:

Service – a product that is intangible and non-storable. (See also “product,” “customer,” and “work product.”)Services are delivered through the use of service systems that have been designed to satisfy service requirements. (See also “service system.”) Many service providers deliver combinations of services and goods. A single service system can deliver both types of products. For example, a training organization can deliver training


materials along with its training services. Services may be delivered through combinations of manual and automated processes.

Service System – an integrated and interdependent combination of component resources that satisfies service requirements. (See also “service system component” and “service requirements.”) A service system encompasses everything required for service delivery, including work products, processes, facilities, tools, consumables, and human resources. Note that a service system includes the people necessary to perform the service system’s processes. In contexts where end users perform some processes for service delivery to be accomplished, those end users are also part of the service system (at least for the duration of those interactions). A complex service system may be divisible into multiple distinct delivery and support systems or subsystems. While these divisions and distinctions may be significant to the service provider organization, they may not be as meaningful to other stakeholders

Service System Component – A resource required for a service system to successfully deliver services.Some components can remain owned by a customer, end user, or third party before service delivery begins and after service delivery ends. (See also “customer” and “end user.”) Some components can be transient resources that are part of the service system for a limited time (e.g., items that are under repair in a maintenance shop).Components can include processes and people. The word “component” can be used in place of “service system component” for brevity when the context makes the meaning clear. The word “infrastructure” can be used to refer collectively to service system components that are tangible and essentially permanent. Depending on the context and type of service, infrastructure can include human resources.

Architecture Perspective from ArchiMate, TOGAF, and FEAFDue to the ubiquity of the service and application construct in IT, Enterprise Architecture frameworks and meta-models make fair use of these concepts as well. Therefore, to offer some more terminology for consideration, the below definitions are provided from ArchiMate, The Open Group Architecture Framework (TOGAF), and Federal Enterprise Architecture Framework (FEAF):

ArchiMateBusiness Service – the externally visible (“logical”) functionality, which is meaningful to the environment and is realized by business behavior (business process, business function, or business interaction).

Application Service – an externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment.

Application Component – an application component is defined as a modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces.

Infrastructure Service – an externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment.

TOGAFBusiness Service – supports business capabilities through an explicitly defined interface and is explicitlygoverned by an organization.


Application – a deployed and operational IT system that supports business functions and services; for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application.

Application Component – an encapsulation of application functionality that is aligned to implementation structuring.

Technology Component – an encapsulation of technology infrastructure that represents a class of technologyproduct or specific technology product.

Platform Service – a technical capability required to provide enabling infrastructure that supports the delivery ofapplications.

FEAFService – discrete unit of functionality that can be requested (provided a set of preconditions is met), performs one or more operations (typically applying business rules and accessing a database), and returns a set of results to the requester. Completion of a service always leaves business and data integrity intact.

Business Services – defined by the agency business model, business services include the foundational mechanisms and back-office services used to achieve the purpose of the agency, e.g., inspections and auditing, direct loans, program monitoring, and financial management.

Enterprise Services – common or shared IT services that support core mission areas and business services. Enterprise services are defined by the agency service component model and include the applications and service components used to achieve the purpose of the agency (e.g., knowledge management, records management, mapping/GIS, business intelligence, and reporting).


Service-Now Current State The following provides a baseline from which to compare frameworks as well as to provide recommendations in the following section. Though the models are accurate according to tables and forms in Service-Now today, the definitions provided represent this author’s interpretation based on previous discussions and experiences.

Configuration Item Data ModelThis data model captures the relationships between relevant Service-Now tables.

Figure 6 – Service-Now Business Service, Technical Service, and Application Tables

Configuration Item – base type for all CMDB CIs in the Service-Now CMDB; a type is not a CMDB CI unless it inherits from this type. Though it does not provide a physical reference to itself, a Configuration Item can have relationship with any other CMDB CI via the CI Relationships table.

Business Service – a type which inherits from the Configuration Item type meant to represent the logical collection of IT applications and infrastructure used to provide value to customers within a specific problem or solution domain; this CI is the top of the service model and identifies the customer entry point to IT using a customer identifiable IT capability or product name. This is also the point in the service model where the Service Catalog relates Catalog items to the CMDB for traceability and reporting.

Technical Service – a custom type which inherits from the Business Service type meant to represent the infrastructural services and applications required to fulfill a Business Service. Its primary function is to allow the modeling of technical infrastructure and applications in a manner which is logical to IT personnel without having to take into account customer understanding or relevance. While Business Services will be directly related to Service Catalog Items, Technical Services provide a terminology mapping between “internal IT services” and “external IT services” both in formation and terminology.


IP Service Instance – a type which inherits from the Configuration Item type meant to represent all infrastructure layer services, such as those that are in the TCP/IP stack, at the operating system level, or are would otherwise be considered core infrastructure. Unlike other “service” tables, this is not a logical entity in that each use of this type or subtypes of this type will likely represent a first order discovered instance of the record running in real life. Entries in this table or subtyped tables will represent an actual running instance of something.

IP Service – a subtype of IP Service Instance, this represents all running instances what would be considered “network services.” This does not exclusively refer to any particular layer within the OSI model, but is rather a domain or topical separation between services which would likely operated by network professionals versus those that would be operated by systems professionals – Windows Service and Unix Daemon, for example. NOTE: Such distinctions are not as precise at Liberty and therefore would probably be less likely to be used by a single group than it appears Service-Now intended.

Windows Service – a subtype of IP Service Instance, this represents all running instances of services on a machine running a Windows operating system.

Unix Daemon – a subtype of IP Service Instance, this represents all running instances of services on a machine running Unix, Linux, or equivalent.

CI Relationships – type whose table contains all relationships between Configuration Items. This table exhibits the service model in Service-Now as it is the expression of relationships between all CIs. Any relationships that are outside of this table, such as those physically between cmdb_ci and sys_user, are not relevant to the service model or the Service-Now Business Service Map (BSM). They can be reported on, but these physical relationships are not taken into account when attempting to understand dependence between CIs, nor are they technically a part of the CMDB. It could be said that the Service-Now CMDB is the cmdb_ci type hierarchy plus the relationships captured in this table: nothing more.

Service Catalog Data ModelAnother important aspect of the Service-Now data model is the relationship between Configuration Item and Catalog Item. In Service-Now, the Service Catalog is constructed of Catalog Items which have a custom relationship to the Configuration Item via the sc_cat_item.u_cmdb_ci. Many Catalog Items can relate to one Configuration Item.


Figure 6 – Catalog Item to Configuration Item and Related Tables

Catalog Request – an instance of someone requesting against the Catalog. This includes requesting one or more items in one “checkout.” This is conceptually equivalent to an online order with a shopping cart full of items. This request is a single reference for all items ordered during that one time through the checkout process.

Catalog Item – an externally accessible item in the Service Catalog which is represented by a link and a form. It acts as the template for the request which, when submitted, is instantiated in a Catalog Request Item.

Catalog Request Item – this is the instance of someone requesting against a Catalog Item.

Catalog Task – a Catalog Request Item can have multiple Catalog Tasks required to fulfill that item. These tasks are generated and assigned via the preconfigured fulfillment workflow.


Figure 8 – Service Catalog Process

Pictured in Figure 8 is the sequential relationship between these tables. It should be noted, that while the Catalog Request, Catalog Request Item, and Catalog Task could be associated with the CMDB CI Business Service for which these request entities apply, this is not happening currently. Today, the only record in the chain that contains a structured link to the Business Service is the Catalog Item. Figure 9 below is a simplified depiction of the Service Catalog and CMDB.

Figure 9 – Catalog Item and Catalog Request Item Relationship to Business Service

Service-Now Table OwnershipThis table shows the current ownership of the tables by the two relevant subcommittees.

Servic

e Catalog

Configuration M

anag

ement

Service-Now TableConfiguration Item XBusiness Service XTechnical Service XCI Relationships XCatalog Item XCatalog Request XCatalog Request Item XCatalog Task X

Table 1 – Tables and Subcommittees

It should be noted that the Business Service CMDB CI is currently owned by the Service Catalog subcommittee. This is the case for the following reasons:

There is a desire by the Service Catalog subcommittee to ensure that the customer is able to experience IT’s services using a set of terminology that are comfortable, familiar, and relevant.


Even though it is possible for the Catalog Item and the Business Service to have different names – where the former is “customer friendly” and the latter is more relevant to internal IT – other than the Service Catalog, there are reports and dashboards (such as Nicus and Outages) that customers will use that should employ this easily accessible terminology.

In an effort to ensure that there is common and familiar terminology for Business Services, the Service Catalog subcommittee has taken ownership of that table.

It should be noted here that it is the opinion of this author that there is some confusion in terms of the necessity and degree of linkage between the Service Portfolio (codified by the highest level services in the CMDB – i.e. Business Services) and the Service Catalog. It is believed by everyone that there indeed should be a link between the Business Services and Service Catalog Items and Request Items, but the implications of that need are not clearly understood. Therefore this lack of clarity is pushing the Service Catalog subcommittee to clamor for more control. Figure 10 below demonstrates the desires of the Service Catalog subcommittee and IT Customer Communications.

Figure 10 – Customer Sees Common “IT Service” Terminology


Service-Now Current State Comparison to FrameworksService-Now and ITIL

Business

Servi

ce

Tech

nical Se

rvice

Applica

tion

CI Relati

onships

IP Servi

ce Ins

tance

Catalog I

tem

Catalog R

equest

Catalog R

equest Ite

m

Catalog T

ask

Framework Entity

ServiceBusiness Service (customer-facing)IT Service

Business Service (IT) XInfrastructure Service XTechnical Service X

Application XConfiguration Management DB XService Catalog (item) XBusiness Service Catalog (item) XTechnical Service Catalog (item) XService Request X X

ITIL

Table 2 – Service-Now and ITIL

Service – this is ITIL’s general definition of a service which provides the same purpose as CMMI-SVC’s definition of the same word. Due to the conceptual nature of the term, there is no direct use of this word in Service-Now. Business Service (customer-facing) – this is ITIL’s use of service to the broader concept of organizational services that provide value to end users and customers of a service provider regardless of whether that service relies of technical capability or automation. It could be said that IT has human services that are offered directly to students and other customers without the involvement of other business units and with limited technical reliance, therefore, this concept could be applied in that case to IT Services. But, since ITIL is drawing a distinction here, and since that distinction is only uniquely valid if you do not include these student-facing IT Services, these services will be considered Business Services (IT) below. Due to the nature of the term, there is no direct use of this word in Service-Now.

IT Service – this is ITIL’s conceptual encapsulation of all services IT has to offer regardless of whether they operate internal or external to the IT organization. Due to the nature of the term, there is no direct use of this word in Service-Now.

Business Service (IT) – this is ITIL’s concept for all of the services that are offered by IT that support a business process outside of IT. There are two types of support relationships that should be considered here. First, there is a particular department’s reliance on the uptime of a given service and the need of IT to report on that uptime. Second, there is a department’s reliance on the provisioning of a service via some request in the Service Catalog. This term has direct relevance to Service-Now and matches the Business Service table.


Infrastructure / Technical Service – this is ITIL’s concept for all of the services that support other services but are not relied on directly by a non-IT business process. While this term has relevance in Service-Now, our implementation does not necessarily match the idea proposed by ITIL. It is clear from a reading of the proposed use from ITIL that some Infrastructure Services will support some Business Services. But, it does not imply, as our service model would suggest, that all Business Services must be based on a set of Technical Services in order to be supported by Applications.Application – according to ITIL this is “software that provides Functions that are required by an IT Service.” Unlike Application Functions and Services supported under ArchiMate, ITIL does not discuss modeling of the functions provided by these applications; therefore ITIL does not do a lot to help describe whether or not the application should be decomposed into functions. Therefore, while there might be a gap conceptually, ITIL and Service-Now are completely relevant to one another.

Configuration Management DB – this is ITIL’s location for assets and the relationships between them. As an ITIL concept, this relates to all tables that inherit from cmdb_ci and the relationships expressed in the CI Relationships tables.

Service Catalog (item) – Service Catalog is ITIL’s representation of all services, both business services and technical services. Service-Now’s Service Catalog supports the same outcome as ITIL, in that there is a set of interfaces to interact with (view, request, etc.) services, but does not seem to match ITIL in that the user interface interacts with Catalog Items which are not a part of the CMDB. Liberty has added a more structured link via the sc_cat_item.u_cmdb_ci field in order to better support ITIL’s implied overlap between the CMDB and the Service Catalog, but even with this field filled, there is an opportunity for a great divergence between Catalog Items and Business Services and Technical Services.

Business Service Catalog (item) – this is ITIL’s way to represent the information concerning IT Services pertinent to customers. As such, the Business Service Catalog and the Technical Service Catalog are views of the Service Catalog, and according to ITIL should be made up of Business and Technical Services both of which are CIs. Therefore there is not really any specifically unique item according to ITIL, though it is implemented in Service-Now using Catalog Item which is not a CI.

Technical Service Catalog (item) – ironically, this is the same concept as Business Service Catalog (item). While hardly clear, this is effectively meant to tie together the CMDB – which includes Technical Services – and the Service Catalog – which only includes Business Services. The point being that the Technical Service Catalog is another view of the same items with different detail than the Business Service Catalog. There is certainly relevance to Service-Now, in the fields that exist between the Catalog Item, Catalog Request Item, and Catalog Task that permit the structured link to the CMDB, but Service-Now’s implementation of the Catalog Item as something that is not a CI does not seem to match ITIL.

Service Request – this is ITIL’s way to instantiate a Service Catalog (item) by a requestor. In Service-Now, this is perfectly mapped to Catalog Request and/or Catalog Request Item.

No ITIL Relevance IP Service Instance – the Service-Now low level services constructs do not map to anything in ITIL that is

mentioned in this paper.

Catalog Task – the Service-Now task that results from ITIL Service Request is not explicitly mentioned by ITIL and therefore does not map to any specific ITIL term.


Service-Now and IT Value Chain

Business

Servi

ce

Tech

nical Se

rvice

Applica

tion

CI Relati

onships

IP Servi

ce Ins

tance

Catalog I

tem

Catalog R

equest

Catalog R

equest Ite

m

Catalog T

ask

Framework Entity

ServiceOrdered Service XApplication X

Service OfferingOrderable Service X XHosting Service X

IT Value Chain

Table 3 – Service-Now and IT Value Chain

Service Ordered Service – in Betz’ IT Value Chain the Ordered Service appears to be most related to a completely fulfilled ITIL Service Request in that there is a unique record for each subscription to or provisioning of a service to a user. So, if there are five users that request Email as an Orderable Service, there would be five records detailing that these five users have Email service. In keeping with that relationship and borrowing from the ITIL relationship to Service-Now, it would be most logical for Ordered Service to represent the completion of a Catalog Request Item which has been associated to a Business or Technical Service in the CMDB.

Service Application – to Betz, the Application is just a Service which is has been ordered by requesting that software be hosted, as would be the case in a project. Another way to look at the Application from Betz’ perspective is to see Application as the evidence (deliverable, CI, etc.) of a request against Hosting Service for a new Orderable Service or a new Hosting Service. If this model is extended to Service-Now, Service acts a potentially arbitrary encapsulation for Application, which, to Betz, appears to be just a deconstruction of Service. In other conversations with Betz, this author is aware of the fact that Betz sees Business Services, Business Capabilities, and Business Functions as having no distinguishable differences and thus are mostly equivalent. This could suggest that ITIL’s definition of Application as “software that provides Functions that are required by an IT Service” could be changed to “software that provides services that are required by a higher level service.” This thinking could be applied to the Service-Now tables of Business Service, Technical Service, and Application to say that each is a higher level encapsulation (abstraction) of the one that comes before it, respectively. This would make the following true for Service-Now:

Business Services are made up of Technical Services are made up of Applications.OR

High-Level Services are made up of Mid-Level Services are made up of Low-Level Software Services.

The point here is that since Business Services, Technical Services, and Applications are all three logically defined rather than physical discovered, their construction mostly arbitrary – or defined at the “management level.” This means that


there is little reason to assume that, based on Betz, any organization of Services or Applications would be incorrect on principle and should be chosen based on Liberty’s desire to achieve levels of abstraction using unique tables.

Service Offering Orderable Service – this is a Service Catalog entry and corresponds to Catalog Item in Service-Now. Unlike Betz, Service-Now does not put these items in the CMDB.

Service Offering Hosting Service – this is a Service Catalog entry and corresponds potentially to ITIL’s Technical Service visible in the Technical Service Catalog as a “supporting service” where the Technical Service would be ordered by internal IT in a project to host an Application. This could map to several areas of Service-Now, but likely due to the request-able nature of this entity, it would not fit into the CMDB as a CI as Service-Now is currently being used, but would rather fit as a different type of Catalog Item which is only visible to project teams or other IT staff.

Figure 11 – Betz to Service-Now Mapping


RecommendationsSince there are several valid options, these recommendations will be presented in terms of the options they support. To follow, there a general set of recommendations that apply regardless of the chosen option. All recommendations are to be understood as applying to Service-Now; therefore unless otherwise specified, all overlapping terminology is in reference to Service-Now tables. Option 1 – Move Technical Service and Use Business Service for AbstractionThis option would allow for the continued usage of the Technical Service, but would relegate it to a different part of the service model. It would leverage Business Service for an abstraction layer between the “desired terminology” of IT Communications and the natural bottom-up definition of Business Services.

Recommendations based on this option:1. Move Technical Services below Application in the service model2. Use the CI Relationships table to model the Business Service layers rather than the parent field in Business

Service table3. Create a new relationship type called “Decomposes/Composes” or something similar to support this option4. Establish a limit to the number of layered decompositions we will model. “Typically two, at most three” seems

to be realistic.5. Define when and if it is appropriate to skip the Application when a Technical Service is being offered as a

Business Service directly (as would be the case to Media Services, for example)

Option 2 – Move Technical Service and Use Application for AbstractionThis option would allow for the continued usage of the Technical Service, but would relegate it to a different part of the service model. It would leverage Application for an abstraction layer between the “desired terminology” of IT Communications and the natural bottom-up definition of Applications. This idea is supported by application functional modeling in ArchiMate where an Application could be expressed in terms of the functions that it provides to the IT Services it supports which is also consistent with ITIL’s explanation of Application.

Recommendations based on this option:1. Move Technical Services below Application in the service model2. Use the CI Relationships table to model the Application layers or Application functions3. Create a new relationship type called “Decomposes/Composes” or something similar to support this option4. Establish a limit to the number of layered decompositions we will model. “Typically two, at most three” seems

to be realistic.5. Define when and if it is appropriate to skip the Application when a Technical Service is being offered as a


Option 3 – Embrace Services as an Interface to Support LayeringThis option would allow for the continued usage of the Technical Service, but would relegate it to a different part of the service model. It would introduce a new table into Service-Now called Application Service and essentially support the same outcome as Option 2, except that rather than functions modeled in all one table, services, would be used. This approach would create an even higher alignment with ArchiMate – where each lower layer is bounded by services to a higher layer. This would create three substrates in the CMDB: (1) a business layer which would support the Business Services and Business Process tables in the CMDB, (2) an application layer which would support Application and a new


Application Service tables, and (3) a technical layer which would support Technical Services and all infrastructure and hardware CIs. Each layered service model would be bounded by one or more services as that layer meets the one above it.

Recommendations based on this option:1. Move Technical Services below Application in the service model2. Create new table called Application Service, which will replace Technical Service’s use today3. Use Business Service as a boundary to Catalog Items4. Use Application Service as a boundary to Business Services5. Use Technical Service as a boundary to Applications6. Define when and if it is appropriate to skip the Application layer when a Technical Service is being offered as a


Option 4 – Do Away with Technical Service and Rely on IP Service InstanceThis option would revert on the usage of the Technical Service and would likely see that table deleted. If Option 2 is desired, but there is a commitment to get back to Service-Now baseline, then IP Service Instance and its subtypes could be used to model low level technical or infrastructural services.

Recommendations based on this option:1. Delete the Technical Service table and migrate to either Business Services (up) or IP Service Instance (down)2. For any lower level services, going forward, use IP Service Instance or a custom subtype3. For any ITIL Technical Services, create a new field on Business Service that can denote that a particular entry is

not directly supporting a non-IT business process

General RecommendationsThe following is a list of general recommendations regardless of the option selected:

1. Build and maintain a Catalog Request to Business Service matrix and use this as a tool to collaborate with the Service Catalog subcommittee. Without managing this information well, in a view separate of Service-Now, it is highly probable that there will be Business Services arbitrarily created simply to be used in multiple request paths that are broken out because, though not particularly obvious, the Business Service is distinct to both the customers and IT.

2. Create a section of the Knowledge Base or a new field on Business Service to keep track of Service names and alternate names. When consensus between Service Catalog and Configuration Management subcommittees cannot be reached there is a reference.

3. Service Catalog and Configuration Management subcommittees need to fully understand that there are two opportunities here that should not be confused as there is very little overlap. The first is around the ITIL Service Request concept and relates to the Catalog Item in Service-Now. There should be incredible clarity for customers around what they are requesting and how to request it, but this has little to do with the second opportunity. The second is around the ITIL Service Catalog (item) concept and relates to the Business Service in Service-Now. The relationship between the first and second should be clear to the customer, primarily because of the other uses of the Business Service – such as in reporting, but these two subcommittees should be clear the differences between these, the unique “interfaces” or points of interaction for each, and come to a consensus on the implications of these interfaces. For example, it should be clear to a customer that they are requesting (a Catalog Request Item) “Banner” (a Business Service) permissions when they complete this Banner Permissions Request form (a Catalog Item). That way, when they are looking at a department consumption


report of Banner, possibly through Nicus, when the customer sees a link to Banner (a Business Service) they can understand it to be the same item for which they requested permissions.

4. The sc_req_item.cmdb_ci should be populated automatically when a Catalog Request Item is created. It should be populated from the Catalog Item sc_cat_item.u_cmdb_ci field of the Catalog Item which created it. This will allow user subscription/provisioning information to be collected.

5. Regardless of the option show, the acceptable use and purpose of Business Service and Application, and potentially Technical Service, will all need to be defined. Even if this purpose is likely to change, it is important to baseline today’s intention to protect against tomorrow’s errors becoming next year’s norms. Drift from the intended usage, even if it’s just within this subcommittee will be subtle at first, and will be easy to miss or dismiss unless everyone is clear on what is being said today.

Document Revisions

Version Date Author Commentsv1.0 10/11/2011 Eric Hendrickson Created document and sent for feedback

to Configuration Management and Service Catalog subcommitees.

guidance for services and applications

Documents