Table of Contents
Introduction
Welcome to the Ardoq Application Ownership Process Playbook. This document describes the benefits of configuring and running the Application Ownership Process, what it does and how it works, explains how to configure and run it “out of the box”, and describes a number of possible extensions you might adopt to tailor the process to better fit your organization and its way of working.
In addition to configuring and running this process, you can use this article as inspiration to create your own workflow that reflects how you’ve modeled applications and their owners in Ardoq.
Who should use this Process Playbook
This playbook is for Enterprise Architects who want to use Ardoq to deliver business value by automating the application governance process, saving considerable time for their organization.
Whilst the focus of the playbook is specific to the application ownership process, reading this document will also give you a good idea of how to go about designing and implementing any other automated governance process you wish to deploy with Ardoq. These enable you to automate the collection and maintenance of information, spreading the work of good IT governance across the organization and giving colleagues more opportunity to engage with the enterprise architecture.
Why you should configure and run this process
Understanding the application portfolio is typically one of the foundational activities of an enterprise architecture initiative. Establishing an owner for each application, and maintaining that information on a continuous basis, is a vital part of this, not only for the benefit of knowing this information and keeping it up to date, but because it facilitates the engagement of all application owners in the process of populating the architecture with details of each application. It establishes clear accountability, which is a key element of good governance, while automating the delivery of business value. If the work were left to just a few architects, it would likely never be finished. By reaching out to the application owners directly, we go to the knowledge source, and are able to engage them all to provide and maintain their knowledge of each application, and connect their knowledge to each other, exponentially increasing its value to the organization.
Here are some of the specific reasons why you should configure and run this process:
Avoiding a reality gap
Accurate information is the key to a successful data-driven enterprise architecture. Every application should have a named owner, who can provide information about the application and act as a point of contact. It is the flow of information that results from this that generates real business value.
Improved responsiveness
Using an automated process ensures that applications without owners are immediately identified and efforts to bring them into a managed state are always pursued. Your architecture will be populated more quickly with accurate information leading to more timely value.
Saving time and money
In the past, capturing application details was a time consuming and costly process, conducted by a handful of enterprise architects. By enabling Ardoq to engage directly with application owners, there is no longer a need for these key resources to single-handedly run a slow and expensive process. Now they can focus on what they were hired to do.
Reducing risk
Increased visibility and ownership of applications are key to ensuring regulatory compliance and avoiding cyber threats.
Increasing engagement
IT is everyone’s business. This process makes it easy to engage everyone to contribute to outcome-oriented Enterprise Architecture and good governance.
The Application Ownership Process
What it is
This automated process, when configured and deployed, runs in the background looking for Application components that lack an owning Person. When it finds one, it will ask a named authority to nominate an owner, who will either accept ownership or propose a more suitable owner. A technical expert may optionally be named. On acceptance, the owner will be asked to provide information needed to satisfy governance and quality policies and will be prompted to review and, if necessary, update that information every six months. A similar request for information will go to the technical expert, if there is one. If there isn’t, that request will go to the owner instead. If the application becomes orphaned, the system will detect this and the process will begin again. The Application Portfolio dashboard allows management to review the state of all applications, showing trends and allowing exploration of exceptions with drill-down functionality from charts.
Figure 1 below shows the process that is provided with Ardoq Foundation. Details of how this can be configured, adapted and extended, are provided later in this Playbook.
Figure 1: The Application Ownership Process
At any point in time, an application will be in one of four possible states which are described in general terms below. The state is recorded for each application in a calculated field named Application Ownership State, and recalculated hourly to ensure that it accurately reflects the current situation. How it does this is explained in detail later in this document.
Unowned - the application does not have a named owner. A central authority will be asked to nominate an owner, but until this has happened, the state will remain “Unowned”. This situation might come about because a new application has been created, but no owner has been identified yet, or because an existing application no longer has an owner (they might have left the organization, thus losing the connection between the owner and the application).
Nominated - an owner has been nominated but they have yet to accept ownership responsibility. They will be invited to either accept ownership of the application or provide the name of a more suitable candidate for ownership of the application. For as long as there remains a nominated owner who has not yet accepted ownership, the state will remain “Nominated”. This state can be bypassed if the central authority indicates that their nomination has already accepted ownership. In this situation, the state will jump straight from “Unowned” to “Owned”.
Owned - the application has an owner who has accepted the responsibility associated with the role. If there is no value for the application’s Strategic Rating, the state will be “Owned”. Given the dependencies of Strategic Rating, it will remain “Owned” until both the Review Application business details and the Review Application technical details surveys have been completed, at which time Strategic Rating will be calculated and the state will move to “Managed”. It will revert back to “Owned” if Review Application business details was last submitted more than seven months ago.
Managed - the application has an owner, the application has a value for Strategic Rating and the Review Application business details survey was last submitted less than seven months ago. The application will remain in this state until either the survey review date becomes older than seven months ago (in which case it reverts to an “Owned” state), or the application loses its owner (and it becomes “Unowned”).
Figure 2: A user’s view of the Accept Application ownership survey
Figure 3: A user’s view of the Review Application business details survey
Figure 4: A user’s view of the Review Application technical details survey
Figure 5: Dashboard widgets showing current ownership state and trend
How it works
Four types asset in Ardoq combine to form the process and bring it to life:
Calculated Fields - these are fields associated with an asset whose values are calculated (and, when appropriate, re-calculated) automatically based on dedicated Gremlin code. For processes, we use a calculated field to determine and record the current state of the process for that particular asset. In this case, a calculated field determines the current ownership state of each Application.
Surveys - forms that gather information from people in different steps of the process. Their answers are used to add information to the model. These may take the form of references (such as creating an Owns link between a Person and the Application they are responsible for), or fields that add detailed information to a particular asset (such as the service level and hosting arrangements for an Application).
Broadcasts - highly configurable messages that can watch for specific situations and, when they occur, trigger a message to a person, for example asking them to complete a survey about a particular asset. For example, a newly appointed owner may be asked to complete a survey providing detailed information that describes an application and its use in the enterprise.
Dashboards - allow the user to track the progress of the process, displaying metrics that demonstrate the value derived from deployment of the process and identifying where further action may be needed (e.g. to encourage application owners to complete outstanding surveys).
Figure 6 below shows how the Application Ownership Process of Figure 1 has been implemented with 4 Surveys, 4 Broadcasts and a Calculated Field.
Figure 6: The process in terms of Ardoq assets
Calculated Fields - Application Ownership State
The calculated field Application Ownership State determines and records the current state of the process, as described above. It is referenced in the first two Broadcasts that progress the process, and in the Application Portfolio Dashboard that presents an overview of the state of application ownership across the entire estate. Appendix I shows the gremlin code for the calculated field Application Ownership State.
Surveys
Four surveys are used to support the Application Ownership Process:
Nominate Application owner: this survey is used to nominate an owner of an application that has been discovered without an Owned reference from a Person. It asks the responder to identify the owner and indicate whether that owner has confirmed ownership. An Owns reference is automatically created from the nominated Person to the Application when the survey is submitted. The confirmation question is used to determine whether the state moves directly from Unowned to Owned, or from Unowned to Nominated. If the responder indicates that the owner has confirmed their ownership, the responder is also invited to name a technical expert.
Accept Application ownership: this survey asks a nominated owner whether they accept ownership. If they say Yes, they will be invited to name a technical expert and the state will progress to Owned. If No, they have to nominate a more suitable Owner. The state will remain Nominated and the Owns reference will move to the newly nominated owner who will then receive the same survey.
Review Application business details: this survey is to be completed by the application owner, providing detailed management information about the application.
Review Application technical details: this survey is to be completed by the technical expert, if there is one. Otherwise, it is completed by the application owner. It provides technical information about the application.
Broadcasts
Four broadcasts are used to send the surveys for completion:
Unowned Applications: this survey broadcast will trigger for any Application component that has Application Ownership State equal to Unowned, sending the Nominate Application owner survey to the named central authority for completion. It is set, by default, to run daily. Beware that if the authority fails to respond within that period, repeated survey invitations will be sent. If this is a problem, the broadcast can be updated to run less frequently (e.g. weekly).
Nominated Owner: this survey broadcast sends the Accept Application ownership survey to the current (nominated) owner of the application when the application’s state is Nominated. The survey is set to run daily. As with the previous survey, if the owner does not take action in time, the broadcast will send a further invitation every 24 hours.
Application business details: this survey broadcast sends the Review Application business details survey to the owner when the survey has never been submitted, or when it was last submitted more than 6 months ago. It is set to run daily.
Application technical details: this survey broadcast sends the Review Application technical details survey to the application’s expert when the survey has never been submitted, or when it was last submitted more than 6 months ago. If there is no application expert, it is sent to the application’s owner. It is set to run daily.
Dashboard Widgets
The Dashboard Widgets that are part of the Application Portfolio Dashboard enable you to view the effectiveness of the Application Ownership Process and its progress over time. One shows the ownership status of all applications as a pie chart. The other shows the trend over time, allowing you to track progress towards a well managed applications portfolio.
How to configure and run it
To configure the assets for the Application Ownership Process:
Edit each of the four surveys (Nominate Application owner, Accept Application ownership, Review Application business details, Review Application technical details), update the Contact email address in the General information section, publish them and save them.
Edit the Unowned Applications Broadcast. In Section 2. Select audience click on the existing Email audience and change it to contain the details of the person who will be the recipient of the Nominate Application owner survey. This needs to be a central authority who is able to make a nomination based on limited information (you may only have the name and description of the application at this stage). Save then Launch the Broadcast.
Select and Launch the Nominated owner, Application business details and Application technical details Broadcasts.
That’s it! Your process is now running. Any applications that lack an owner will automatically be detected and begin their journey on the Application Ownership Process. You can track progress and investigate individual cases from the Application Portfolio Dashboard.
Changing the “out of the box” process
You may want to adapt the Application Ownership Process to better fit your organization. Three optional extensions / variants are explored below to help you out.
Review frequency
By default, application owners and technical experts are asked to review, update and confirm the application details every six months. This can be changed to suit the rhythm of your organization, to 1 month, 3 months, 6 months or a year.
To make this change, you must edit the Application business details and/or the Application technical details broadcasts. In section 1 of the Broadcast builder, you will see that the filter rule Survey has not been updated for 6 months has been applied. You can change 6 months to 1 month, 3 months or 1 year in the drop down for each of the two broadcasts.
If you change this for the Application business details broadcast, you should consider updating the gremlin calculation for the field Application Ownership State. By default, the state will revert back to “Owned” if the field Review Date is more than 7 months ago. As this field gets set automatically when the Review Application business details survey is submitted, there is a connection between when the owner is invited to complete the survey and when the state field loses its “Managed” state.
Out of the box, the owner has one month to submit the survey after receiving the invitation before the state drops from “Managed” to “Owned”. A change to the broadcast frequency should be matched with a change to the ageThreshold variable in the gremlin code (see Appendix 1 for details).
Allocated ownership
By default, the Nominate Application owner survey asks the respondee whether the nominated owner has confirmed their ownership of the application. If the respondee answers No, the state becomes Nominated, and the nominated owner will receive the Accept Application ownership survey, inviting them to either accept ownership or nominate a more suitable owner. Whilst answering Yes will cause the system to skip this Nominated state, and jump straight to Owned, it may be desirable for that to happen in every case, to remove the confirmation question and simplify the process to that shown in Figure 7 below.
Figure 7: The Application Ownership Process with Allocated Ownership
This can be achieved with a simple change to the Nominate Application owner survey. We will replace the confirmation question with a hidden field that will automatically set the field Ownership Accepted to Yes. And we’ll move the expert reference question from being a conditional sub-question to a main survey question so that it is always asked. As a consequence, the state will always jump from Unowned to Owned after the survey has been submitted.
Select and Edit Nominate Application owner survey and navigate to the Questions Section.
Scroll to the bottom and under Add question or section select Reference question.
Give the new question the title “Application Expert(s)”.
Add the following help text (or similar):
You may, optionally, select one or more experts in the Application, other than the Owner. If you do so, they will be asked to provide some technical information about the application periodically. If you do not, this technical survey will go to the Owner instead.
Choose Incoming for the Reference direction, select the People workspace and the Person component type. Scroll down to Select reference type and choose Is Expert In.
The question above this new one (number 4) is entitled Has your nominated owner accepted the responsibility? This is the one we want to delete and replace with a hidden field question. Hit the “X” to the right of the question and confirm deletion of the question and its dependent question.
In Add question or section beneath the last question, choose Hidden Field. Under Field Name select Ownership Accepted and select the value Yes.
Save your changes, ensuring that the survey is Live.
Crowdsourcing applications
The Application Ownership Process kicks in when an unowned application is spotted in Ardoq. How the application components are created is not considered. They may be manually created by an architect using Ardoq, or imported via a spreadsheet or an integration with a specialist application such as ServiceNow. Or you may choose to crowdsource your application repository by inviting any colleague to complete a survey, naming and describing the applications they use. This might be the quickest way to capture the reality of applications in use across the organization. But there needs to be some check on the quality of what gets created: duplicates might be created with different names, and not everyone will interpret your definition of an Application correctly.
Fortunately, the first step in the Application Ownership Process routes all unowned applications to a central authority to nominate an owner. A simple change to the Nominate Application owner survey can give the nominated authority the power to reject the proposed Application and delete the component, neatly adding a quality control step to a crowdsourcing approach. In the Data selection section of the Survey Builder, select Allow respondents to delete existing components. The authority will now be able to choose between submitting a completed survey or deleting the new application component.
As your unowned applications will now contain all sorts of proposed, but not yet approved applications, you may also wish to filter these out of some of the visualizations you have of your applications estate to ensure that they only show an authorized view.
Appendix I - Calculated Field Application Ownership State
// Assign ageThreshold to seven months ago (today minus 213 days) ageThreshold = (new Date() - 213).format('yyyy-MM-dd')
g.V(ids). project('id', 'name', 'value'). by(id). by('name'). by( choose( __.in('Owns').hasLabel ('Person'), // Application has an owner choose( has('ownership_accepted', 'Yes'), // Owner has accepted ownership choose( and(__.has('review_date', gt(ageThreshold)),__.has('strategic_rating')), // Application Details Survey was last reviewed within the past seven // months, so data is current, and we have a strategic rating value constant('Managed'), // Data is more than seven months old - revert to Owned state constant('Owned') ), // Ownership not yet accepted constant('Nominated') ), // Application does not have an owner constant('Unowned') ) ) |