This Playbook offers step-by-step guidance on how to simplify, improve and automate the Application Ownership Process. We explain how to configure and run it “out of the box”, and describe a number of extensions that you may use to tailor the process to better fit your organization and its way of working.
You can add this process to your deployment of the Application Lifecycle Management Use Case, or use this process as inspiration to create your own workflow that reflects how you’ve modeled applications and their owners in Ardoq.
Table of contents
Who should use this 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.
While the focus of the playbook is specific to the application ownership process, reading this document will also give you a good idea of how design and implement any other automated governance process with Ardoq.
These processes 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
Many enterprise architecture initiatives start with understanding the application portfolio.
To do this effectively, it is important to establish an owner for each application, and maintain information about ownership and other application details on a continuous basis.
Not only is this information necessary from a governance viewpoint, it also enables application owners to quickly and effectively populate the architecture. If the work of maintaining application data was 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 are some of the specific reasons why you should configure and run this process:
More accurate information
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.
Share knowledge
By reaching out to the application owners directly, we go to the knowledge source, and encourage them to share their knowledge of each application, and connect that knowledge to each other. This flow of knowledge is what generates real business value.
Establish accountability
This processes establishes clear accountability, which is a key element of good governance.
Improve 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.
Save 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.
Reduce risk
Increased visibility and ownership of applications are key to ensuring regulatory compliance and avoiding cyber threats.
Increase engagement
IT is everyone’s business. This process makes it easy for application owners to contribute to outcome-oriented Enterprise Architecture and good governance.
What is the Application Ownership Process?
The application ownership process is a series of automated steps, which, when configured and deployed, will do the following:
Look for Application components that lack an owning Person.
When it finds a component that meets the criteria, it will ask a named authority to nominate an owner, who will either accept ownership or propose a more suitable owner.
On acceptance, the owner will be asked to provide mandatory and optional information needed to satisfy governance and IT quality policies.
The owner will be prompted to review and, if necessary, update that information every six months.
If the application becomes orphaned, the system will detect this and the process will begin again.
A 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: 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 may arise when a new application has been created, but no owner has been identified yet, or because an existing application no longer has an owner (they may 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. 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 from “Unowned” to “Owned”.
Owned - The application has an owner who has accepted the responsibility associated with the role. If the Application Details Survey hasn't been completed for this application, or it was last reviewed more than six months ago, the state will be “Owned”. The application state will remain “Owned” until the owner has completed the Application Details Survey, at which point it becomes "Managed."
Managed - The application has an owner and the Application Details Survey was last completed less than six months ago. The application will remain in this state until either the survey review date becomes older than six 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 Ownership Acceptance Task in Ardoq Discover
Figure 3: A user’s view of the Application Details Task in Ardoq Discover
Figure 4: Dashboard showing current ownership state and trend
How does it work?
Four Ardoq features work together to automate the application ownership 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 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 5 below shows how the Application Ownership Process of Figure 1 has been implemented with 3 Surveys, 3 Broadcasts and a Calculated Field.
Figure 5: How the process is automated using Ardoq features
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 Broadcasts that progress the process, and in the 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
Three surveys are used to support the Application Ownership Process:
ALM - Unowned Application Survey - 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.
ALM - Ownership Acceptance Survey - This survey asks a nominated owner whether they accept ownership. If they say Yes 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.
ALM - Application Details Survey - This survey is to be completed by the application owner, providing detailed management information about the application.
Broadcasts
Three broadcasts are used to send the surveys for completion:
ALM - Unowned Applications: This survey broadcast will trigger for any Application component that has Application Ownership State equal to Unowned, sending the ALM - Unowned Application 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 weekly.
ALM - Nominated Owner: This survey broadcast sends the ALM - Ownership Acceptance Survey to the current 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.
ALM - Managed Application Details: This survey broadcast sends the ALM - Application Details survey to the owner when the status is Owned. It will also be triggered when the survey was last reviewed more than 6 months ago, as the state will have changed from Managed back to Owned. It is set to run daily.
Track the process with dashboard widgets
The Dashboard Widgets enables you to view the effectiveness of the Application Ownership Process and its progress over time.
Ownership Status shows the ownership status of all applications as a pie chart. The other shows Ownership Status Trend, allowing you to track progress towards a well managed applications portfolio. These metrics can be added to any of your governance dashboards alongside other application metrics.
How to configure and run it
This section assumes that you have a new deployment of the Application Lifecycle Management Use Case that contains the assets for the Application Ownership Process. It describes the steps needed to configure those assets and activate the process.
If you are seeking to add the Application Ownership Process to an existing deployment, please read Appendix II of this document which provides a step by step guide to creating and configuring the necessary assets manually.
To configure the assets for the Application Ownership Process:
Edit each of the three surveys (ALM - Unowned Application Survey, ALM - Ownership Acceptance Survey, ALM - Application Details Survey), update the Contact email address in the Survey Details section, and save them.
Edit the ALM - Unowned Applications Broadcast. In Section 2. Select Audience choose Add Audience and enter the details of the person who will be the recipient of the ALM - Unowned Application 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 ALM - Nominated Owner and ALM - Managed Application 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 any Dashboard you create that includes the Dashboard Widgets.
How to change the “out of the box” process
You may want to adapt the Application Ownership Process to better fit your organization. These are seven options:
Review frequency
By default, application owners 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 update the calculation for the field Application Ownership State in the component type Application. Open the workspace that contains the Application component type, and from the sidebar menu select Workspace…Edit Metamodel…Close the popup window and select Manage field types in the right side menu.
Select Edit for the field Application Ownership State and scroll down to click on the Edit button under Calculated fields.
An editor opens, containing the gremlin code that determines the value of the field. You will see the definition of a local variable, ageThreshold, which is set to today’s date minus 183 days (i.e. six months ago). Replace the 183 with whatever period you have chosen in days and hit Apply Calculation to save your new calculation.
That’s it. The review part of the process will now run at your preferred frequency.
Allocated Ownership
By default, the ALM - Unowned Application Survey asks the responder whether the nominated owner has confirmed their ownership of the application. If the responder answers No, the state becomes Nominated, and the nominated owner will receive the ALM - Ownership Acceptance Survey, inviting them to either accept ownership or nominate a more suitable owner. 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 6 below.
Figure 6: The Application Ownership Process with Allocated Ownership
This can be achieved with a simple change to the ALM - Unowned Application Survey. We will replace the confirmation question with a hidden field that will automatically set the field Ownership Accepted to Yes. As a consequence, the state will always jump from Unowned to Owned after the survey has been submitted.
Select and Edit ALM - Unowned Application Survey and navigate to the Survey Sections.
Item 4 is the confirmation question. On the right-hand side of the question title, hit X to remove the question from the survey.
Select Add section beneath the last question, and choose Hidden Field. Under Field Name select Ownership Accepted and select the value Yes.
Save your changes, ensuring that the survey is Live.
Use Survey Submission Date instead of Review Date
The ALM Application Details Survey contains an input field asking the user to indicate when the application was reviewed. It is this date that is used by the process to determine when the survey needs to be reviewed and re-submitted by the application owner. The purpose of using this input date is that it forces the user to enter a date, thereby confirming that they have, indeed, reviewed the application.
An alternative approach would be to use the date when the submit button is hit. Here’s the steps you need to take to do this:
Create a new field of type Date time and apply it to your Application component type. You could call it Application Details Survey Date.
Edit the ALM Application Details Survey and choose Add section under Survey Sections. Choose Hidden field and select Application Details Survey Date from the dropdown list. You will see that its value is set to Automatic, which will cause the date field to be automatically populated with the current date/time when the survey is submitted. Save your updated survey.
Edit the Gremlin calculation code for Application Ownership State and update it so that it compares your new Application Details Survey Date in place of Review Date.
Notifications
In addition to using Broadcasts to send a survey to a person for completion, you can also use them to send notifications to interested parties. For example, once the application owner has completed the application details survey, we have a lot more information about the application which may be of interest to colleagues. Here we show you how to create a Broadcast that will notify colleagues when the application ownership state becomes Managed. This might invite them to view the application and its details and connections that have been completed by the owner, from their particular perspective.
From the main Ardoq menu select Create New Broadcast. This will open a form that will walk you through the process to configure your new broadcast.
In Section 1, Under Content type, select Message, then select the Workspace that contains your Application components, and choose the Application component type.
You want to pick up only those applications that have been reviewed since the last time this Broadcast was run. You can choose to have it run at a frequency of your choice, but your filter rules have to match your chosen frequency. Let us assume that you want to run the Broadcast weekly. Click on Add filter rule, choose Component fields rules and enter Review Date in the search field of the rule editor. Select Review Date, and in the dropdown that defaults to is, choose between. This allows you to enter a relative date range. In the first Select… dropdown, choose Select relative date… then scroll down to select A week ago. In the next Select… dropdown, again choose Select relative date… then scroll down to select Today.
Section 2 is where we select the audience who will receive the message. You can choose between a targeted audience, which defines a query that selects the audience depending on some criteria using information contained in Ardoq, or a general audience, which will be one or more named individuals. Your choice depends on the message you want to deliver, and whether you need to direct that message using information in Ardoq. If, for example, you want to notify the Service Desk manager that application information is now available, you can select that person directly. If, however, you want to direct the message to the security expert who works in the same organizational unit as the application owner, then you can create a Gremlin query that targets precisely that individual for each application that passes the filter rules.
Once you have selected your audience, write your message in Section 3, bearing in mind that the message will contain a list (as an individual may be the targeted recipient for more than one application).
Section 4 invites you to include in the message a link to the application details page in Discover. This is a great option if you want to give the recipient an easy way to explore the application data that has just been added to Ardoq.
Finally, in Section 5, choose a repeated broadcast that will run at the frequency you adopted when setting up your filter rules.
That’s it! Save and launch your broadcast, and you’ve successfully added automated notifications to your Application Ownership Process.
Approvals
Sometimes there is a need to have information that has been provided by one person reviewed and signed-off by another. The reviewer can either approve the information and move the process forward, or return the survey to the original recipient to make further changes before submitting it again for review. You can add this sub-process to your Application Ownership Process, or indeed to any other process you might implement with Ardoq.
Figure 7: The Application Approval Process with added approval step
Item 2 of the Broadcasts Patterns Workflow article explains in detail how to add an approval workflow to a survey. The instructions below tell you which steps in the article to follow to change your Application Ownership Process:
Insert a reviewer section to the ALM - Application Details Survey as described in Steps 1 and 2 of the article.
Create a review survey, copying and amending the ALM - Application Details Survey as described in Step 3.
Follow Steps 5 to 8 of the article, to create a First Review Broadcast, Approval Message Broadcast, Not Approved Survey Broadcast and Review Again Survey Broadcast.
Lastly, you need to change the Application Ownership State calculated field so that the state only becomes Managed when the details survey has been reviewed and approved. Figure 8 below highlights the changes you need to make to the calculated field’s gremlin code.
// Assign ageThreshold to six months ago (today minus 183 days)
ageThreshold = (new Date() - 183).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(
has('approved', 'Yes'),
// Application has been approved
choose(
has('review_date', gt(ageThreshold)),
// Application Details Survey was last reviewed within the past
// six months, so data is current
constant('Managed'),
// Data is more than six months old - revert to Owned
constant('Owned')
),
// Application has not been approved
constant('Owned')
),
// Ownership not yet accepted
constant('Nominated')
),
// Application does not have an owner
constant('Unowned')
)
)
Figure 8: Application Ownership State - changes to calculated field Gremlin code
Make sure your Surveys are Live and all the Broadcasts have been Launched. You’ve now added an approval step to your Application Ownership Process.
Currently, our team is working on building functionality that will simplify the approval process by allowing admins to decide whether they want to isolate changes made by survey respondents before making these changes 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 applications in use across the organization, but there needs to be a quality check on 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 ALM - Unowned Application 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 Workspace and Components section of the Survey Builder, select Allow respondents to delete component.
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.
Agile domain teams
A common form for application ownership is that semi-autonomous teams manage the applications estate. Rather than have a central authority nominate the application owner, the task is distributed to the architectural leader of the relevant domain team.
The job of the central authority is simply to nominate the owning organizational unit that represents the domain team, and their lead architect will then become the application owner. With this approach, there will not be a direct Owns reference from a Person to an Application. Instead, the Owns reference will come from an Organizational Unit, but Ardoq can send the Application Details Survey to the team’s Lead Architect just as if that person did have a direct connection to the application. Ardoq can also look out for the situation where the team doesn’t have a Lead Architect, and take action if that occurs.
This variant introduces the Organizational Unit component type to represent the domain team to which Person components belong. The Belongs To reference, in this example, contains a reference field called Role, that can contain a text field describing the role the person carries out when a member of that organizational unit. Figure 9 below illustrates the metamodel, and Figure 10 shows the corresponding revised application ownership process we’re seeking to implement.
Figure 9: Agile domain teams metamodel
Figure 10: Agile domain teams application ownership process
You need to set up the surveys, broadcasts and Application Ownership State calculated field to implement the above process. We’ll assume you’ve adopted the metamodel shown in Figure 9, but you can adapt the steps below to suit any differences in reference or component type names.
Start by updating the Application Ownership State calculated field to reflect the Ownership State shown in Figure 10 above. You will need to change the Option for this calculated list field so that they match the four possible ownership states shown. Then you need to update the gremlin calculation so that it reflects the process. Figure 11 below contains example gremlin code for this.
Apply the calculation to save it against the field, and remember to save the field definition so that the new list values and Gremlin code are saved.
// Assign ageThreshold to six months ago (today minus 183 days)
ageThreshold = (new Date() - 183).format('YYYY-MM-dd')
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
choose(
__.in('Owns').hasLabel ('Organizational Unit'),
// App belongs to an Organizational Unit
choose(
__.in('Owns').hasLabel ('Organizational Unit').
inE('Belongs To').has('role', 'Lead Architect'),
// Owning org unit has a Lead Architect
choose(
has('review_date', gt(ageThreshold)),
// data is current
constant('Managed'),
// data is out of date - more than 6 months old or not yet supplied
constant('Owned')
),
// has a domain which does not have a Lead Architect
constant('Domain Owned')
),
// has no domain
constant('Unowned')
)
)Figure 11: Application Ownership State calculated field for agile domain teams
Edit the original ALM - Unowned Application Survey. Change the Application Owner question so that it asks the respondent to select an owning Organizational Unit rather than a Person. You will need to select the workspace where your organization is represented, and select the Organizational Unit component type. Save your changes.
Now we need to change the broadcast that asks the owner to complete the ALM - Application Details Survey so that it is sent to the lead architect of the owning domain team. Edit the broadcast ALM - Managed Application Details and go to Section 1. Select content. Change the Filter rules so that they select Applications whose ownership state is equal to Owned.
It should look like this:
Figure 12: Broadcast filter conditions
Now go to section 2: Select audience. Remove the current selection, and click on Add audience, choosing By Gremlin people query. Add the following Gremlin line which selects the path to the lead architect of the owning organizational unit:
// Find the lead architect of the owning org unit
g.V().hasId(ids).in('Owns').hasLabel('Organizational Unit').
inE('Belongs To').has('role', 'Lead Architect').outV().path()Figure 11: Gremlin graph query to find the owning organizational unit’s lead architect
Set this broadcast to run every day, then save and launch it.
Finally, you need to consider the situation where there is no Lead Architect in an owning Organizational Unit. If this situation can occur, the Application Ownership State will become stuck at Domain Owned. You may choose to address these situations manually, as they are easily identified from the dashboard. But you could alternatively set up an automated process similar to the Application Ownership Process to ensure that all relevant Organizational Units have a member with the role of Lead Architect.
Appendix I - Calculated Field Application Ownership State
// Assign ageThreshold to six months ago (today minus 183 days)
ageThreshold = (new Date() - 183).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(
has('review_date', gt(ageThreshold)),
// Application Details Survey was last reviewed within the past six
// months, so data is current
constant('Managed'),
// Data is more than six months old - revert to Owned or not yet
// supplied
constant('Owned')
),
// Ownership not yet accepted
constant('Nominated')
),
// Application does not have an owner
constant('Unowned')
)
)
Appendix II - How to implement the Application Ownership Process to an Existing Application Workspace
These instructions walk you through the step by step process of implementing the “out of the box” Application Ownership Process described in this document.
Add two new fields to your Application component type
We need to define and add two new fields to the Application component type, Ownership Accepted and Application Ownership State.
With your Application workspace open, from the sidebar menu, choose Edit metamodel…Manage field types.
Hit the Add field button at the bottom, and in the resulting Select… field, type the name of the first new field, Ownership Accepted and hit Enter.
3. In the Create field form, select the type List, and under Options, add the following list options, hitting Enter or selecting the Create popup button between each item: Yes, No.
4. Add a suitable description in the Description field (such as “has responsibility been accepted by the application’s owner?”), and in the Applies to…Component types dropdown, select Application. Hit the Create button to create the new field, which will now appear in the list of fields in the sidebar.
5. Hit the Add field button at the bottom again to add our second field, and in the resulting Select… field, type its name, Application Ownership State and hit Enter.
6. In the Create field form, select the type Calculated List, and under Options, add the following list options, hitting Enter or selecting the Create popup button between each item: Unowned, Nominated, Owned and Managed.
7. Add a suitable field description, and in Applies to…Component types, choose Application from the dropdown list of component types, then hit the Create & edit query button.
8. A Gremlin editor window opens. Copy the Gremlin code in Appendix I above. Select all the code in the editor window, except for line 0 (which starts “ids =”), and paste in your copied code, overwriting the Gremlin code that you highlighted.
9. Hit the Test calculation button, and the code will be applied to all the Applications in your workspace, with the resulting values displayed below. You can hit the Apply Calculation button to apply this, and choose Return to workspace at the top of the screen to close the Gremlin editor.
We have successfully added two fields, Ownership Accepted and Application Ownership State to all the Application components in the Workspace, with the latter field automatically recalculating its value for each Application component on a regular basis.
Add two new Surveys
Now we’ll add two surveys: one to ask a central authority to nominate an owner when an unowned application is discovered (ALM - Unowned Application Survey), and one to ask that nominated owner to accept ownership (ALM - Ownership Acceptance Survey), or alternatively to nominate the right owner.
From the main menu on the left-hand side, select Surveys to bring up the Survey overview in the main body. Click on New survey at the top right. The Survey builder will open.
In the Survey Details section, under Survey Name, enter ALM - Unowned Application Survey.
In the Workspace and Components section, select your Application workspace and your Application component type. Unless you want your respondent to be able to add new people to your Ardoq model, you can uncheck permission to create components. They will be linking people who are already defined in the system to applications as nominated owners.
In Survey Sections, change the Question title of the first default question to Application Name, and add the help text “What is the name of the application?”.
Click on Add section and select Field Question to add the second question. Select the field Description, give the title Application Description, and add the help text “Describe the application in a sentence or two”.
Click on Add section again, this time selecting Reference Question. Give the title Owner, and add the help text “Please nominate an owner for this application”. Under Components to be referenced: choose Incoming for the Reference direction:, select your People workspace and the component type Person and Select reference type Owns. Scroll down to the Number of references that can be created, and choose 1 for both Min and Max. We do not need to Add section to reference question. This requires the respondent to pick one, and only one, Person as the nominated owner for the Application, creating an Owns reference between the Person and the Application.
Click on Add section one more time to add the last question, this time a Field Question. Select the field Ownership Accepted giving the title “Has your nominated owner accepted the responsibility?”. Mark this as a required field.
We recommend that you also add the survey to Ardoq Discover in the Ardoq Discover section.
Save the survey and make it live.
Return to the Survey overview page and click on the New survey button again so that we can add the second survey:
Name this survey ALM - Ownership Acceptance Survey and give it a description, such as “Asks nominated owner to either accept ownership or nominate a more suitable owner for the application”.
In the Workspace and Components section, select your Applications workspace, and the Application component type. As with the above survey, it should not be necessary for respondents to create or delete components, so uncheck both boxes.
In the Survey Sections update the name of the first question to Application Name, then click on Add section to add a new question, and select Field Question. Select the field Ownership Accepted, and enter the Question title: Please confirm that you are the owner of this application. Add help text, such as “If you confirm your ownership of this application, you will be responsible for maintaining information about the application. If this information is absent, or is out of date, you will be asked to confirm what we currently know and fill in any gaps. If you say ‘No’, you must nominate the right owner.”
Check the box Is this field required? And click on Add conditional section. We’re going to ask the respondent to nominate the right owner if they have answered “No” to the previous question. Choose Conditional reference question (as their response will switch the Owns reference from themselves to their nomination).
Select No as the answer that will cause the question to appear, and give this conditional reference question the title Who should be the owner of this application? Add suitable help text, for example “Please nominate the right owner for this application. They will be invited to accept ownership.”.
In the Components to be referenced section, indicate that the Reference is Incoming. Choose your People workspace, select the component type Person and the Owns reference type. As previously, set the Min and Max number of references both to 1.
We recommend that you also add the survey to Ardoq Discover in the Ardoq Discover section.
Save the survey and make it live.
We’ve now added the two new surveys needed to run the Application Ownership Process.
Add three new Broadcasts
Now we need to add the three Broadcasts that animate our process, starting with the first one that detects unowned applications:
Choose Create New Broadcast from the main menu on the left. Give the Broadcast a meaningful name, such as ALM - Unowned Applications in the text field at the top (containing Untitled Broadcast). Then in Section 1. Select content select a Content type of Survey, and select the Survey name ALM - Unowned Application Survey.
2. Tick the Add filter rules checkbox and choose Filter based on: Component fields. We need one simple rule that will select all unowned applications. In Select what to search for… start typing then select Application Ownership State, and set it to equal to Unowned (selecting Unowned from the Select… dropdown list). If you click on Preview included components it will apply this rule to your current application components and list those that are unowned.
3. In Section 2. Select audience, you need to identify the authority who will consider each unowned application and nominate an owner (by completing the ALM - Unowned Application Survey). This is likely to be simply a named individual, as you do not yet know enough about the Application to be able to route it to a targeted Person. Click on Add audience and choose your preferred way to identify them. If you just want to type in their email address, select From group or individual email, enter the address into the popup window and click Add to audience list. Alternatively, if they are represented in Ardoq, you can select them from a list of Person components by choosing From people workspace in Ardoq, selecting your People workspace then finding and adding the individual to the audience list.
4. Section 3. Compose message is where you tailor your message. Enter a meaningful Subject line, like Unowned Applications detected. Edit the body of the message to explain the task in hand. You might choose something like this:
5. This will be a repeating broadcast so that unowned applications are continuously caught. Remember that applications in the Managed state may return to being Unowned in the event that they lose their owner. In Section 5. Select schedule and reminder, we recommend running this Broadcast daily, but you could alternatively choose weekly if you think your authority would prefer to receive a weekly digest (however, bear in mind that means unowned applications will remain in that state for a bit longer). You may also set a Reminder if you wish.
6. Click on the Save button at the top right to save your new Broadcast, then click on Launch Broadcast to set it running. You will be presented with a Review broadcast popup dialog that offers a summary and asks you to confirm it by hitting Launch now. Note that it may contain warnings indicating that components or audiences have not been found. This is not necessarily an error - it is simply a warning that there are currently no Applications in the state that is targeted for the Broadcast to fire.
Now we’ll repeat the process for the second and third Broadcasts. As these two Broadcasts are almost identical, both sending a survey to the Application owner when the Application Ownership State has a particular value, we’ll include instructions for both surveys in this one set of instructions. Just follow them from beginning to end twice, choosing the first or second input values accordingly. You can also copy the second broadcast and edit it to create the third one.
Before you start creating the Broadcasts, you must first make sure that your current model has at least one Application component that has an Owns reference from a Person component. If this is not the case, please temporarily add one such link so that you can set up the Broadcasts. It does not have to be the right person - it is the existence of the reference that is important, and you can delete the reference once you have set up both Broadcasts.
Choose Create New Broadcast from the main menu on the left. Give the Broadcast a meaningful name, such as ALM - Nominated Owner | ALM - Managed Application Details in the text field at the top (containing Untitled Broadcast). Then in Section 1. Select content select a Content type of Survey, and select the Survey name ALM - Ownership Acceptance Survey | ALM - Application Details Survey.
Tick the Add filter rules checkbox and choose Filter based on: Component fields. We need one simple rule that will select all unowned applications. In Select what to search for… start typing then select Application Ownership State, and set it to equal to Nominated | Owned (selecting Nominated | Owned from the Select… dropdown list).
In Section 2. Select audience, we will direct the survey to the Person who has an Owns reference connection to the Application - the nominated or confirmed Owner. Click on Add audience and choose By predefined people query. Check the Owns checkbox at the top of the popup window, and hit the Add to audience list button.
Section 3. Compose message is where you tailor your message. Enter a meaningful Subject line, like You’ve been nominated | Please provide application details . Edit the body of the message to explain the task in hand. You might choose something like these:
5. In Section 5. Select schedule and reminder, we recommend running this Broadcast daily, but you could alternatively choose weekly if you wish to avoid recipients receiving daily requests (however, bear in mind that this will slow considerably the pace of the workflow). You may also set a Reminder if you wish.
6. Click on the Save button at the top right to save your new Broadcast, then click on Launch Broadcast to set it running. You will be presented with a Review broadcast popup dialog that offers a summary and asks you to confirm it by hitting Launch now. Note that it may contain warnings indicating that components or audiences have not been found. This is not necessarily an error - it is simply a warning that there are currently no Applications in the state that is targeted for the Broadcast to fire.
Create a Dashboard with two Dashboard widgets
To facilitate the measurement and monitoring of your Application Ownership Process, we’ll create a Dashboard with two widgets: one to show the current ownership state of your application portfolio, and the other to show its trend over time (see Figure 4 above for an example screenshot).
Before we create the Dashboards, it is a good idea to add the field we’re interested in to a report. Select Reports Overview from the main menu and find the report called APM - All Applications. Select it, and choose Edit to enter the Report Builder. Click on the list of report columns and you will be presented with a multi-selection list offering you all the Reference Types, Custom Fields and Default Fields. Among the Custom Fields will be Application Ownership State which you can select and place where you wish in the arrangement of columns. Save the Report.
Now we’ll create a new Dashboard that will contain two charts. Select Dashboards Overview in the main menu. If you already have an existing Dashboard you’d like to add these charts to instead, you can open and edit that Dashboard instead of following the rest of the instructions in this step. To create a new Dashboard, select Create new at the top right of the screen. The Dashboard Builder opens. Give your new Dashboard a name: Application Governance Process Dashboard by clicking on the pen icon at the right-hand end of the Dashboard name panel. Optionally, add a description, such as “Tracking the ownership status of our applications”.
Select Add new chart and in the right-hand panel select the APM - All Applications report. In Select fields choose Application Ownership State, and give your Chart a title: Applications Under Management. In Select chart type, choose Pie chart. Further down the panel, you can configure the appearance of the chart, showing the total count and choosing preferred colors.
Select Add new chart again to add a second chart that will this time display the ownership trend over time. Choose the same report and field (APM - All Applications, Application Ownership State) and call this one Application Management Trend. For the chart type, choose Stacked bar chart. Again, there are configuration options below that allow you to adjust the chart appearance. You can change the timeline and the colors (but note that changing the colors here will also change the color scheme of the pie chart to ensure consistency, as both charts use the same data label).
Save your Dashboard, and you will see that it has now been added to the list of Dashboards in your Dashboard overview, which you can view directly, or open in Discover.
6. Sharing the dashboard.
6.1 Share access to this dashboard with the right stakeholders. Click on the three dots menu to give other roles access to this dashboard.
You can also share this dashboard through "Copy Discover dashboard URL". Keep in mind, that the person you're sharing it with must have access to Ardoq Discover.
6.2 If this dashboard is relevant to your entire organization, consider bookmarking it on your enterprise architecture portal, Ardoq Discover:
Navigate to the Ardoq Discover search page ({organizationname}.ardoq.com/discover/) and in the bottom right corner of the banner, click Configure Discover.
Go to Page content > Add Ardoq asset and search for "Application Governance Process Dashboard"
The new dashboard will appear on the Ardoq Discover home page and will be accessible to all stakeholders who use this portal:
You might consider adding this dashboard to an Ardoq presentation.