Contents
Introduction
Ardoq Foundation is a Solution that is pre-installed with Ardoq. It is a core platform that all Enterprise Architecture (EA) initiatives are likely to need. When populated and put to use, it can address a number of valuable business questions that demonstrate the value of an Enterprise Architecture to key EA stakeholders, but its primary purpose is to provide a solid foundation on which to deploy even more valuable enterprise architecture solutions. Whatever direction you plan to take your EA practice in, from business strategy and architecture to technology optimization, from business and technology transformation to governance and risk management, the core solution and its metamodel introduced here is the ideal starting point.
We strongly advise that you invest sufficient time and effort to put this Solution into practice and adopt ways of working that will make it self-sustaining before you move beyond it. In this way, Ardoq Foundation will truly serve as a durable and sustainable foundation layer for all your Enterprise Architecture initiatives.
For a broader introduction to Ardoq Foundation, beyond just its metamodel, please see Ardoq Foundation: Purpose, Scope and Rationale.
Purpose
The primary purpose of this solution is to provide solid foundations for all future Enterprise Architecture initiatives. It represents a core foundation layer, providing the jumping-off point for further initiatives in a number of different directions by establishing the following:
Describing the organizational structure and relating it to people
Defining, identifying and describing the applications used by the organization
Understanding what the organization does, and how the application portfolio contributes to it
Whilst these are often just the first necessary steps towards deeper analysis of specific business problems involving a more extensive knowledge graph facilitated by additional Ardoq Solutions, Ardoq Foundation can already address a number of valuable business questions:
Describe the organizational structure and relate it to people |
Who owns and manages each organizational unit? |
Define, identify and describe applications |
Which organizational units use each application? |
Who owns each application in the organization? |
Who owns the organization's most important applications? |
How will my application portfolio look at a future date? |
What is the current state of our applications (Implementing, Live, Phasing Out or Retired) |
Which of my applications lack sufficient expertise? |
Understand the applications estate and its contribution to the organization |
Which capabilities are differentiating to my organization? |
Which capabilities are the most/least mature in my organization? |
How is each capability realized in my organization (in terms of applications and organizational units)? |
Which business capabilities are our most interconnected and complex? |
Who are the experts in my organization in each capability? |
Which business capabilities could benefit from investment (e.g. those that have poor maturity and/or rely on apps that provide poor business value)? |
Which capabilities depend on applications that have low service levels? |
Which organizational units realize our most differentiating capabilities? |
Where are the key people (owners and experts) located within the organization? |
How well do our applications satisfy business requirements? |
How well do our applications satisfy technical requirements? |
How well do our applications support the realization of our business capabilities? |
Where is there a gap between IT and business understanding of the importance of an application? |
An automated process is provided to manage the ownership of applications. It will automatically detect unowned applications and prompt a central authority, such as the enterprise architect, to nominate an owner. The process then ensures that applications are owned, and that their owners and technical experts keep the information about their applications up to date.
Ardoq Foundation Metamodel
Component Types
Organization
The Organization Workspace is used to contain a representation of the organization that is the primary subject of the Enterprise Architecture. For most Ardoq users, this means there will be a single component of type Organization that represents the business or enterprise as a whole. There are no fields beyond Name and Description, and an Organization component is typically the parent of one or more Organizational Unit components that represent the top level of its organizational structure. In some cases, an organization will be the parent of other organizations, for example where an organization is made up of discrete organizations that themselves have a degree of autonomy that goes beyond what might be expected of an organizational unit. A large multinational corporation may be divided into several organizations by geography. A conglomerate business might have separate organizations serving different industries. These child organizations will, in turn, contain their own organizational structures composed of Organizational Unit components.
Organizational Unit
An Organizational Unit component represents an internal subdivision of an organization. Organizational units decompose into business units, departments, sub-organizations, committees, teams and groups, forming organizational hierarchies. These are most commonly represented in Ardoq using the parent-child relationship, with an Organization component at the root of the hierarchy. However, some organizational structures are not hierarchical, and in this situation the relationship between organizational units, and between organizational units and organizations, can be represented using the Belongs To reference type (escaping the constraints of a hierarchy inherent in the parent-child relationship).
Person
A Person component represents a named individual in the organization. In enterprise modeling, a person is usually represented when they have a defined relationship with one or more other components. For example, the CFO owns the Finance Department and reports to the CEO.
Person Fields
The Person component type has one field in addition to the default Name and Description fields: Contact Email. This field should be populated for all people represented in the knowledge graph so that they can be recipients of Survey, Message and Report alert Broadcasts.
Field | Description |
Name | The Person’s name |
Description |
|
Contact Email | The Person’s email address |
Application
Ardoq defines an Application as follows:
“A deployed and running software solution that provides specific business or technology capability, performs a defined task or analyzes specific information. It has meaning for, and its name will be recognized by, its business users.”
Similar definitions can be found in standards like TOGAF and ArchiMate.
Even with those definitions, it can be hard when looking at your long list of candidate software to decide exactly what is and what isn’t an application. For detailed guidance, please read our What is an Application? article.
Application Fields
As with all component types, the Application component type has Name and Description fields.
Field | Description |
Name | A unique name for the application |
Description | A concise description of the nature of what the application does |
Application Lifecycle Fields
Field | Field Type | Description | Definition |
Live | Date Range | A date range from when an application “went live” to its discontinue date |
|
Lifecycle Phase | List | A field used to classify where an application is in its lifecycle |
|
Application Governance Fields
Field | Field Type | Description | Definition |
Approved | Checkbox | Used to indicate whether a component has been reviewed and acknowledged as being accurate and complete |
|
Review Date | Date | Used to indicate the date at which a component was reviewed and acknowledged as being accurate and complete |
|
Ownership Accepted | List | Used to indicate whether a nominated owner has accepted the responsibility of being the application owner |
|
Application Ownership State | Calculated List | Determines the ownership state of the Application by examining whether there is an application owner, whether they have accepted responsibility, and whether application details have been provided and are up to date |
|
The Ownership Accepted and Application Ownership State fields are used in the application ownership process. Application Ownership State’s value is determined with the following rules:
Unowned: the application has no owner;
Nominated: an owner has been nominated, but they have not yet accepted ownership responsibility;
Owned: there is no value for Strategic Rating or the Review Application business details survey was last completed seven or more months ago;
Managed: there is a value for the application’s Strategic Rating and the Review Application business details survey was last completed within the last seven months.
Note that Strategic Rating is a calculated field that ultimately depends on answers provided in both the Review Application business details survey and the Review Application technical details survey. An application will only achieve the state of Managed after both surveys have been completed, with values provided for all the fields that make up Business Value and Technical Fit.
For more details of how this automated process works, and how to deploy it, see the article Process Playbook: How to Automate Application Ownership (Foundation).
Application Descriptive Fields
Field | Field Type | Description | Definition |
Application Type | List | Classification of how an application was developed and delivered to the organization |
|
Service Level | List | Classification of the service level assigned to the application by the IT Service Management team (its fix-on-fail priority) |
|
TIME Rating and Dimension Fields
The Gartner TIME model places applications in a 2x2 quadrant (the assigned quadrant being recorded in the Strategic Rating field), based on two dimensions: Business Value and Technical Fit. Both dimensions are expressed as a number on the scale of 1.0 to 5.0, and are derived from a number of questions provided by the owner and/or technical expert of each application via the Application Owner and Application Expert surveys respectively.
The Strategic Rating and its associated business and technical dimensions provide a valuable high level guide to investment prioritization and opportunities to improve the efficiency and effectiveness of the application portfolio and its overall contribution to the organization.
Field | Field Type | Description | Definition |
Strategic Rating | Calculated List | Application model from Gartner to classify applications from a strategic perspective |
|
Business Value | Calculated Number | Assesses how well the application supports the current needs and the future plans and value to its users | A number in the range 1.0 to 5.0, calculated as a weighted average of Business Strategic Fit, Functional Fit, Features and Usability and Criticality |
Technical Fit | Calculated Number | Assesses how well the application supports the current technical needs and the future plans of the support organization | A number in the range 1.0 to 5.0, calculated as a weighted average of Maintainability and Agility, Technical Integrity and Technical Strategic Fit |
Business Value Fields
Field | Field Type | Description | Definition |
Business Strategic Fit | List | A measure of the application’s ability to support business strategy or the ambitions of its users | 5 = It supports all known future requirements without modification
4 = It requires minor modification to support known future requirements
3 = It may require significant modification to support known future requirements
2 = It can't support known future requirements without major rework
1 = It is incapable of supporting known future requirements |
Functional Fit | List | A measure of how well the application provides all the functionality required to realize the relevant capability/value stream | 5 = It has no missing function
4 = It has minor missing function
3 = It has moderate missing function and requires occasional workaround
2 = It has significant missing function and requires regular workaround
1 = It is not possible to use the application at all without workarounds |
Features and Usability | List | A measure of how easy the application is to use without unreasonable training or extensive experience | 5 = It is easy-to-use / reliable / trusted
4 = It is mostly easy-to-use / usually reliable / mostly trusted
3 = It is averagely usable / moderately reliable / moderately trusted
2 = It can be hard to use / unreliable / untrustworthy
1 = It is very hard to use / highly unreliable / highly untrustworthy |
Criticality | List | A measure of the criticality of the application in supporting the business and/or customers | 5 = Mission Critical: Breaks in service are intolerable and immediately significantly damaging. Availability required at almost any price.
4 = Business Critical: A business-critical service requires continuous availability, short breaks in service are not catastrophic.
3 = Business Operational: Contributing to efficient business operation but out of direct line of service to customer.
2 = Administrative Service: Failures are undesirable but do not affect customers and can be tolerated a little more.
1 = Not Applicable: Failures do not have any adverse impact on the day to day operations or customer services. |
Technical Fit Fields
Field | Field Type | Description | Definition |
Maintainability and Agility | List | A measure of the application’s ease of upkeep and ability to adapt within the technology landscape | 5 = It is easy to maintain, recover and change whenever required
4 = It is fairly easy to maintain, recover and can be changed with minimum lead-time
3 = It is averagely easy to maintain and recover, and can be changed with moderate lead-time
2 = It is hard to maintain, slow to recover and requires significant lead-time to change
1 = Maintenance or changes are avoided from fear of unknown impacts, and recovery is questionable |
Technical Integrity | List | A measure of how well the application adheres to technical standards | 5 = It complies to all technical and interoperability standards
4 = It mostly complies to all technical and interoperability standards
3 = It has moderate deviations from technical and interoperability standards
2 = It has significant deviations from technical and interoperability standards
1 = It is highly non-compliant with technical and interoperability standards |
Technical Strategic Fit | List | A measure of how well the application is able to address future requirements in line with technical strategy | 5 = It supports all known future technical requirements
4 = It can support known future technical requirements with minor modification
3 = It can support known future technical requirements with moderate investment
2 = It will require significant investment to support known future technical requirements
1 = It is incapable of supporting known future technical requirements |
Business Capability
The Business Capability component type is used to build a model that represents what an organization does. It is typically modeled as a hierarchy of multiple layers, using the parent-child relationship to break capabilities down into more detailed sub-capabilities. For more information about Business Capabilities and their value to Enterprise Architects, see the article What Are Business Capabilities?.
Business Capability Fields
As with all component types, the Business Capability component type has Name and Description fields.
Field | Description |
Name | A unique name for the business capability |
Description | A concise description of the business capability |
Business Capability Lifecycle and Governance Fields
Field | Field Type | Description | Definition |
Lifecycle Phase | List | A field used to classify where a business capability is in its lifecycle |
|
Approved | Checkbox | Used to indicate whether a component has been reviewed and acknowledged as being accurate and complete |
|
Review Date | Date | Used to indicate the date at which a component was reviewed and acknowledged as being accurate and complete |
|
Business Capability Descriptive Fields
Field | Field Type | Description | Definition |
Component Level | Calculated Number | Indicates where, in the capability hierarchy, this capability sits (useful for filtering) |
|
Complexity | Calculated Number | A measure of the complexity of a business capability, expressed numerically by summing the total number of realization references to applications or organizational units from this capability or any of its descendants |
|
Market Differentiation | Number | A measure of the extent to which the capability provides a competitive advantage in one or more markets, expressed on a scale of 1.0 to 5.0 | 1 = Commodity: The capability provides no competitive or market advantage and can be provided or consumed as a standardized service (i.e. “everybody does this the same - there’s no advantage in reinventing the wheel”)
2 = Market-adapted: The capability may be adapted to provide a marginal market advantage (i.e. “we can adapt to market requirements but the difference to our performance is small.”).
3 = Market-competitive: The capability is tailored to meet the upper norms or expectations of a market (i.e. “investing in this capability makes us a credible player.”).
4 = Market-leading: The capability is optimized to provide a competitive advantage against competitors with similar capabilities (i.e. “if we do this better than our competitors we outperform them.”).
5 = Market-disruptive: The capability provides a decisive competitive advantage through being unique, innovative, or unable to be reproduced by competitors (i.e. “if we can do this and our competitors can’t we change the game.”).
|
Maturity | Number | A numeric measure of the maturity of the business capability, expressed on a scale of 1.0 to 5.0 (following the US DoC ACM Model from TOGAF) | 1 = Initial
2 = Under Development
3 = Defined
4 = Managed
5 = Measured |
Reference Types
Altogether, Ardoq Foundation metamodel includes twelve triples (component type - reference type > component type combinations) not counting parent-child relationships. Some of these are only used in particular circumstances (e.g. to model non-hierarchical organization structures), while others will be used in all Ardoq knowledge graphs. Seven different reference types are used, as described below.
Belongs To
The Belongs To reference type represents that a component is a part of, or a member of, another component. In the context of Ardoq Foundation, it is used in the following three triples:
Person - Belongs To > Organizational Unit
Organizational Unit - Belongs To > Organizational Unit
Organizational Unit - Belongs To > Organization
As discussed previously, those that originate with Organizational Unit are only used to represent organizational structures that are not hierarchical. When they are hierarchical, the parent-child relationship will be used.
Consumes
The Consumes reference type is used to show where a component consumes or potentially consumes or gains value from another component. In the Ardoq Foundation metamodel, it is used in one triple:
Organizational Unit - Consumes > Application
Reports To
The Reports To reference type represents that a person reports to, or is accountable to, another person.
Person - Reports To > Person
Owns
The Owns reference type indicates that one component has overall responsibility for another. It is often useful to show an ownership relationship between people and other components so that actions and notifications that relate to a component may be sent automatically to that component’s owner via a Broadcast. In the Ardoq Foundation metamodel, two such ownership relationships are represented:
Person - Owns > Organizational Unit
Person - Owns > Application
Is Expert In
The Is Expert In reference type indicates that a Person has a high level of knowledge of another component. Like the Owns reference, it is often used to identify the recipient of a survey where details of a component are being sought.
Person - Is Expert In > Business Capability
Person - Is Expert In > Application
In the case of Applications, in the application ownership process, the owner of an application is invited to name a technical expert. If they do so, the expert will be the recipient of a survey seeking technical details of the application (the Application Expert survey). If no expert is provided, the survey will be sent to the owner instead.
Is Realized By
The Is Realized By reference type indicates how a conceptual component’s requirements, behaviors or characteristics are implemented, in full or in part, by another component. In the Ardoq Foundation metamodel, two component types can realize, or contribute to the realization of, a Business Capability:
Business Capability - Is Realized By > Organizational Unit
Business Capability - Is Realized By > Application
Has Successor
Has Successor represents that a component is succeeded by, replaced by, or has a time-based dependency on another component. In the Ardoq Foundation metamodel, it is used to indicate that one application component is the successor to another:
Application - Has Successor > Application
Calculated Fields - Gremlin
Application Fields
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') ) ) |
Strategic Rating
//@author Nikolai Hegelstad def calculateTIMEScore(it) { a=it.get().values('technical_fit')[0] b=it.get().values('business_value')[0] if (a<3 && b<3) {return 'Eliminate'} if (a<3 && b>=3) {return 'Migrate'} if (a>=3 && b<3) {return 'Tolerate'} if (a>=3 && b>=3) {return 'Invest'} return; } g.V(ids). has('technical_fit'). has('business_value'). project('id', 'name', 'value'). by(id). by('name'). by(map{calculateTIMEScore(it)}) |
Business Value
// @author Nikolai Hegelstad // @revision Sean Gibson functionalFitKey = 'functional_fit' functionalFitWeighting = 0.20 featuresAndUsabilityKey = 'features_and_usability' featuresAndUsabilityWeighting = 0.20 businessStrategicFitKey = 'business_strategic_fit' businessStrategicFitWeighting = 0.25 criticalityKey = 'criticality' criticalityWeighting = 0.35
def calculateBusinessValue(it) { a=it.get().values(functionalFitKey)[0] as Double b=it.get().values(featuresAndUsabilityKey)[0] as Double c=it.get().values(businessStrategicFitKey)[0] as Double d=it.get().values(criticalityKey)[0] as Double return (a*functionalFitWeighting + b*featuresAndUsabilityWeighting + c*businessStrategicFitWeighting + d*criticalityWeighting).round(2) }
g.V(ids) .and( has(functionalFitKey), has(featuresAndUsabilityKey), has(businessStrategicFitKey), has(criticalityKey)) .project('id', 'name', 'value'). by(id). by('name'). by(map{calculateBusinessValue(it)}) |
Technical Fit
// @author Nikolai Hegelstad technicalIntegrityKey = 'technical_integrity' technicalIntegrityWeighting = 0.43 maintainabilityAndAgilityKey = 'maintainability_and_agility' maintainabilityAndAgilityWeighting = 0.27 technicalStrategicFitKey = 'technical_strategic_fit' technicalStrategicFitWeighting = 0.3
def calculateTechnicalFit(it) { a=it.get().values(technicalIntegrityKey)[0] as Double b=it.get().values(maintainabilityAndAgilityKey)[0] as Double c=it.get().values(technicalStrategicFitKey)[0] as Double return (a*technicalIntegrityWeighting + b*maintainabilityAndAgilityWeighting + c*technicalStrategicFitWeighting).round(2) }
g.V(ids) .and( has(technicalIntegrityKey), has(maintainabilityAndAgilityKey), has(technicalStrategicFitKey)) .project('id', 'name', 'value'). by(id). by('name'). by(map{calculateTechnicalFit(it)}) |
Business Capability Fields
Component Level
g.V(ids).project('id', 'name', 'value'). by(id). by('name'). by( emit().repeat( out('ardoq_parent')). count()) |
Complexity
calculate = __.out('Is Realized By').hasLabel('Application', 'Organizational Unit').count() g.withSack(0).V(ids). project('id', 'name', 'value'). by(id). by('name'). by(emit().repeat(__.in('ardoq_parent')). sack(sum).by(calculate.sum()). sack().sum()) |