+358 40 5928 921
With IT4IT recently trending in the various feeds I follow, not least because of my colleague Aki Lähteenmäki contributing to those feeds, I thought I should chip in with my two cents. Being the techie that I am, I am looking at the phenomenon from tooling perspective.
“And please keep it short!” I hear you say.
The Open Group IT4IT Reference Architecture (the “Reference Architecture” from now on) is a reference architecture and a value chain-based operating model for managing the business of IT. The Reference Architecture is intended to be industry, product, and vendor independent.
The Reference Architecture is based on the idea of IT Value Chain containing four Value Streams (and five Supporting Activities which are not covered in the standard as those are deemed to be outside the control of IT).
Each Value Stream provides a prescription for the essential elements that IT must control to manage a service through its life-cycle, and each Value Stream is intended to add value to the business or IT service. Essential elements being the abilities (Functional Components) of the organization, Information managed (Data Objects) and the Relationships between Data Objects, and Data Flows between Functional Components.
The Reference Architecture describes three different Abstraction Levels, and reserves additional two levels for vendors to introduce product and/or solution level architecture.
Because the Reference Architecture is decoupled from vendors and products, you could probably use pen and paper and make a successful claim that you run your IT according to the Reference Architecture. In this part of the multiverse though, your organization will have a tool or multiple tools in place to support your organization’s work to deliver the services.
With that background in place, in the following blog series I intend to investigate how well ServiceNow’s (the company) ServiceNow (the product) covers different Value Streams of the IT4IT Reference Architecture. In this blog series I will stay firmly in the Abstraction Levels 1 and 2 when mapping against ServiceNow’s functionalities and datamodel.
The Reference Architecture describes Functional Components as “…the smallest unit of technology that can stand on its own and be useful as a whole to an IT practitioner (or IT service provider). It must have defined input(s) and output(s) that are data objects…”
In the context of ServiceNow, the Functional Components easily map to zero or more Applications (or Menu Applications) with the table(s) acting as the system(s) of record for the data object(s) and ServiceNow’s UI providing the System of Engagement integration between the Functional Components and various ServiceNow’s internal functionalities weaving the “system of record fabric” between different internal parts.
As the Reference Architecture is vendor agnostic, I do not look for one to one name matching between the Applications and Functional components, but rather I am looking at the purpose of the Application and the purpose of the Functional Component. The suitability against the Level 2 description will be further assessed in later posts. I will mostly look at the core functionality and most obvious ServiceNow’s own extensions but I am leaving out the myriad of apps available for fee/free from the Store. Your organization can also extend the platform by creating your own apps to fill the gaps.
|Value Stream||Functional Component||ServiceNow Application/Functionality|
|Strategy to Portfolio||Enterprise Architecture||no direct match|
|Policy||Governance Risk and Compliance|
|Proposal||Agile / SDLC Strories
|Porfolio Demand||Demand Management|
Service Portfolio Management
|IT Investment Portfolio||Financial management|
|Requirement to Deploy||Project||Project Management
Agile Development / SDLC
Agile Development’s Enhancements
|Service Design||no direct match|
|Source Control||no direct match|
|Build||no direct match|
|Build Package||no direct match|
|Release Composition||no direct match|
Agile Development’s Testing Tasks
|Defect||Agile Development’s Defect
Demand Management’s Demand of type Defect
|Request to Fulfill||Engagement Experience Portal||ServiceNow UI, either the CMS/Service Portal or the normal UI|
|Offer Consumption||CMS/Service Portal providing Service Catalog content and Usage content for the end user|
|Offer Management||Service Catalog|
|Catalog Composition||Service Portfolio Management
|Request Rationalization||Request Fulfillment
Service Portfolio Management
|Fulfillment Execution||Request Fulfillment (and Orchestration and/or integrations if you automate or broker)
Service portfolio mgmt
|Usage||Depending on the type of Service provided, the Usage is amount of Tasks, used/owned Licenses, Subscriptions to CIs, number of CIs, worked hours collected via Time Cards, other Expence Lines, etc etc|
|Chargeback / Showback||Cost Management
|Knowledge & Collaboration Supporting Function||Knowledge
|Detect to Correct||Service Monitoring||ServiceWatch and Discovery to some extent|
|Incident||Incident and Incident alert management|
|Diagnostics and Remediation||Orchestration for automated Run Books
Knowledge for manual Run Books
|Service Level||Service Level Management, Metrics, Contract Management, Service Portfolio Management – SLA Commitments|
With the list in place, two key things start to emerge
So here is the first installment of the series. Hopefully this is of use to you and if you are interested in discussing IT4IT or supporting tooling or architectural concerns do not hesitate to contact us via our pages or engaging with us via LinkedIn, Twitter or just plain old skype/phone call.
If you disagree with my assessment or otherwise want to discuss the topic, or if you would like to engage with me about doing similar mapping to other tools, please ping me via email or LinkedIn and I would be happy to continue the discussion.