This document introduces Ardoq Foundation, a solution that comprises four key elements that make up the foundational core of any Enterprise Architecture repository:

The second half, from Establishing an Architecture Repository, provides guidance for those getting started on their initial Enterprise Architecture journey. It contains useful tips on:

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 further 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 introduced here is the ideal starting point.

We strongly advise that you invest sufficient time and effort to put this platform 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.

This article provides a broad overall introduction to the Solution, how it has been designed, and the rationale that lies behind its design. For a detailed exploration of its metamodel, please see Ardoq Foundation: Metamodel.

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 facilitating the following:

Whilst these are often just the first necessary steps towards deeper analysis of specific business problems, Ardoq Foundation can already address a number of valuable business questions:

An automated process is provided to manage the ownership of applications. It will automatically detect unowned applications and prompt a central authority, someone with a good understanding of the organization and its use of applications, 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. For details of the application ownership process, see Process Playbook - Application Ownership (Foundation).

The foundational platform is laid on four core elements:

It contains four workspaces, dedicated to these four elements. But why these four?

The way a business is organized, the arrangements of its organizational units, lies at the core of how the vast majority of organizations manage themselves. Their budgets, plans and operational activities are managed through their organizational structures and the management of their organizational units.

Enterprise architecture involves analysis of how an organization works, and how it might change to meet challenges and objectives, threats and opportunities, from many different perspectives. Whilst it is useful to conduct such analysis from abstract perspectives, it is also vital for enterprise architects to present outcomes in language and from perspectives well understood by all their stakeholders. The organization, and its constituent organizational units, provide one of those vital perspectives.

Enterprise Architecture relies on people to achieve business outcomes. It needs the input of people across the organization to capture the right information and to keep it up to date. And its value is only realized when it is used to inform decisions, which means putting its outcomes in front of people. Ardoq provides powerful capabilities to reach people in both situations, but this can only be realized if it knows about people, their roles and responsibilities. With its automated broadcasts, Ardoq can alert people to provide information via its surveys, or to inform them of situations of particular interest in relation to their roles and responsibilities. To alert them, the Contact Email field must be populated, and their roles and responsibilities are represented with references to other components in the knowledge graph.

TOGAF defines a business capability as:

“A particular ability that a business may possess or exchange to achieve a specific purpose”

Many organizations value the ability to describe what an organization does using a business capability map. This is typically represented as a tiered hierarchy of capabilities, each successive tier representing a decomposition of its parents. Capabilities provide an abstract view, independent of how a business is organized or managed. This gives the architect a “pure” view of the organization’s capabilities, and when linked to the components that are involved in realizing those capabilities, it allows architects to take a more objective view of what the organization does, and how it does it.

There are alternative approaches: some organizations represent their business in terms of value streams, others focus on more tangible processes, while others are happy to view their business solely through their organizational structure. All of these perspectives are available with Ardoq, using the Business Value Streams, Business Process Management and Foundation Solutions respectively, but we recommend that enterprise architects get their initial view of what the organization does using business capabilities. This can often be achieved with a lightweight high level model that might only need one or two levels and may consist of fewer than 20 capabilities. A more detailed view capabilities under investigation can always be added later. Other perspectives can be introduced, alongside or in place of business capabilities, once the foundations have been established. For more information about different approaches to describing a business, see What is the difference between Business Capabilities, Processes and Value Streams?

Applications, and the organizational units that use them, are key to the realization of business capabilities. Any desire to change or improve the business capabilities of an organization must involve an appreciation of how applications contribute to those capabilities. So it is vital that an enterprise architecture represents the application portfolio and facilitates an understanding of the state of that portfolio and the contribution it makes to the execution of the organization’s business capabilities.

The real power of Ardoq’s knowledge graph comes, not from its Components, but from the connections between them: the References. The Ardoq Foundation Metamodel contains seven reference types that are used to represent key relationships between components. Although there are only five component types in Foundation (Organization, Organizational Unit, Person, Business Capability, Application), more component types are introduced in later Solutions. The seven reference types describe concepts that will recur between different component types across Ardoq’s many Solutions, being common relationships between different things:

The concept of one component having overall responsibility for another.

The concept of one component being part of, or a member of, another.

The concept of one component consuming, potentially consuming, or gaining value from, another.

The concept of a component’s logical requirements, behaviors or characteristics being defined by another.

The concept of a component having a high level of knowledge of another.

The concept of a time-based dependency, succession or replacement between components.

The concept of one component being accountable to another.

Other Ardoq Solutions will add new reference types, broadening the concepts that can be represented in your Ardoq knowledge graph.

Component Types contain Fields that are used to give individual components descriptive characteristics. One such field, Contact Email, belonging to the component type Person has already been mentioned. All component types have a Name and Description. In Foundation, the component type Business Capability contains seven additional fields, and Application contains eighteen. Reference Types can also contain Fields. Whilst there are no instances of this in Foundation, Reference Fields play an important role in many of the Ardoq Solutions you may choose to subsequently deploy. For a general introduction to Fields, see the article What is a Field?.

For a detailed description of the Foundation metamodel, including all its component types, fields and reference types, see Ardoq Foundation: Metamodel.

Ardoq offers a range of ways to create and maintain information in its repository. For the foundation, information about the organization’s structure, its people and its applications, is likely to exist already in other systems. Importing data from third party systems, either using a direct integration or via excel, may be the most efficient way to create and maintain the corresponding components and references in Ardoq.

Ardoq Foundation also contains pre-configured Surveys that can be sent to stakeholders to create and maintain Organizational Unit, Person and Application components. You can also create your own surveys automatically from the component definitions, or manually. See How to Automatically Create a Survey and How to Manually Create a Survey for details.

Components and references, and their fields, can also be created and maintained directly in the tool (see How to Create Components and How to Create References for details).

The following sections of this article describe how to get your architecture repository up and running and deliver value to your stakeholders using the assets provided with Ardoq Foundation.

Before you start populating your model, we recommend that you take a step back and consider what you are here for, and who will benefit from your work.

Some EA teams have a formal charter that establishes their purpose, their resources, their powers, and some metrics to measure their success. Even if you don’t create such a formal document, you should be very clear about:

The creation and population of your repository are just means to achieving business outcomes. It is only when you put that repository to work, addressing important business questions and having the answers inform business decisions, that you begin to deliver value. So don’t rush to import data until you can articulate your mandate, goals and objectives, and can trace a clear line from the data you plan to populate your repository with to the business outcomes you want to achieve.

So always try to start from a question you want to answer and the people who will value the answer you can provide, and use that to inform what information you need and how it should be organized.

Most EA teams are accountable to a senior or executive manager. But their outcomes as enterprise architects are likely to be of value beyond that primary stakeholder. We recommend creating a stakeholder map for your enterprise architecture initiative. This can help you:

The stakeholder map can help you prioritize your work. Don’t try to address everybody’s needs at the outset. Look for outcomes that will be highly valued by influential stakeholders who can become your strongest advocates. Ideally outcomes that depend on information that is both obtainable and reliable.

You are almost ready to start populating your repository and creating some tangible, valuable outcomes. Consider the scope of your initial effort to populate Ardoq. Whilst your instinct might be to capture the structure and people of the whole organization and define all its business capabilities and applications, you may be able to deliver some outcomes of real value by starting with just a slice of the organization. This might be just one part of what it does. Or one geographical region. Or one particular change initiative. You can think of this as a vertical slice through the “cake” that is Ardoq Foundation. Capturing all the “layers” of that one slice (Organization, People, Capabilities, Applications) might allow you to answer some key questions more quickly than if you were to attempt first to populate each “layer” for the entire organization. And once you have completed one “cake slice” you can make a decision either to repeat the process for more slices, or to further develop your model for your initial slice by deploying additional Solutions to answer some new valuable business questions.

We’ll return to these options later. Now it is time to get started.

Here’s the portion of the Ardoq Foundation metamodel that relates to just the Organization and People workspaces and connects the two.

Starting with the Organization and People workspaces might seem counterintuitive - why not start with Applications, which many architects think of as the centrepiece of their repository? The reason is simple: by putting the organization and people in place first, it becomes easier to import the applications and link them to the people who own them and the org units that consume them in one single subsequent import operation.

Most organizational structures follow a traditional hierarchy. If yours does, you will have one Organization component at the top, with a number of child Organizational Unit components as its children. These may, in turn, contain further Organizational Unit children, representing departments, division, teams etc. There is no limit to the depth of the organizational hierarchy you can model in Ardoq, but remember to limit the complexity of what you model to just that which is required to address valuable business questions. Start with a simple model, and only extend it when you know you have to.

Whilst the Belongs To reference type allows you to connect Organizational Units to each other, or to Organization components, there is no need to make use of the Belongs To reference if you are able to satisfactorily represent your organization and its structure using parent-child relationships. The Belongs To reference type comes in handy when representing non-hierarchical organizational structures. For a more detailed discussion of how to model different types of organizational structure, see the article Organizational Modeling Patterns.

As mentioned previously, each Person component you create should also have a Contact Email field so that the person can engage with your enterprise architecture. You can indicate a person’s membership of an Organizational Unit using the Belongs To reference, and management or ownership of an Organizational Unit using the Owns reference. The Owns reference is particularly useful in enabling you to trigger automatic notifications to the leaders of business units in the organization, either because you are seeking information from them (e.g. you want them to complete a survey), or because you have discovered something that would be of interest to them (e.g. you may send them an automated notification via a Broadcast).

You may also choose to use the Reports To reference to record who reports to whom. Whilst this reference type and the Belongs To reference type enable you to model an organization at the level of people, you should only consider doing so if you can find a way to keep it up to date and if you can see how this information will help you address valuable business questions with Ardoq. If it doesn’t add value, you would be wiser to avoid including it in your model.

Having set up your people and organization structure, you can visualize this information with a block diagram or a dependency map in Ardoq. The Org Structure and Ownership presentation contains one each of these that you can view to answer the business questions:

Eighteen fields describe the different characteristics of applications in the Ardoq Foundation metamodel. Full details of these can be found in Ardoq Foundation: Metamodel. Information to populate many of these may be found in your service management tools, such as ServiceNow. Indeed, this is often the source of the applications themselves. But before you rush to populate Ardoq with everything you have in ServiceNow using Ardoq’s ServiceNow integration, you should take some time to define what you mean by Application for your Ardoq repository. Your definition of an application from an EA perspective may be different from that of your service management team. It is a good idea for the EA team to agree and write down what constitutes an Application component before creating any. The article What is an Application? How to Model Complex Business Systems in Ardoq contains some useful guidance on this.

The following diagram shows the metamodel for applications and how people and organizational units relate to them.

It is worth highlighting the Has Successor reference type, which connects applications to their successor applications. This introduces a time dimension, and brings together the fields Lifecycle Phase, the date range Live and the Has Successor reference. It enables you to show how you expect the portfolio to evolve in the future, identifying when applications are expected to retire and what, if anything, they will be replaced with. If multiple applications have the same successor, you are able to show planned consolidation and rationalisation of your application portfolio, with a planned timeline. This information can be visualized using the Timeline view style. Grouping components using the Has Successor reference type keeps the applications and their successors connected in the resulting visualization. An example of such a timeline visualization is included in the Application Portfolio: Usage, Value and Timeline presentation.

It can be difficult to keep so much information about applications up to date, especially given the large number of applications deployed in most organizations. We recommend that maintenance of this information should be a responsibility that is distributed among those who best know about the applications: their owners and technical experts. An automated process is included with Ardoq Foundation to ensure that every application is owned and its data is regularly maintained. It will automatically identify unowned applications and invite a central authority (e.g. someone in the EA team) to nominate an owner. Two surveys, one relating to the application’s business information (Review Application business details), the other to its technical information (Review Application technical details), are used to collect and maintain the fields and references for each application. Full details of the process and how to set it up can be found in Process Playbook - Application Ownership (Foundation).

The Review Application business details survey can also be used to create new Application components.

Ten of the fields on the Application component relate to Gartner’s TIME model. This uses two dimensions to place applications in a matrix. One dimension relates to the business value of the application, while the other relates to its technical fit. Each dimension is derived using a weighted average of the answers given in the Review Application business details and Review Application technical details surveys respectively.

The calculated field Business Value is composed of Functional Fit (20%), Features and Usability (20%), Business Strategic Fit (25%) and Criticality (35%).

The calculated field Technical Fit is composed of Technical Integrity (43%), Maintainability and Agility (27%) and Technical Strategic Fit (30%).

These weightings can be amended to suit your preferences by updating the corresponding calculated field Gremlin queries. Details of all the fields, including the Gremlin code, can be found in Ardoq Foundation: Metamodel.

By plotting the two dimensions in a two-by-two matrix, the Gartner TIME model provides a high level view of the strategic position of an application. An application with high technical fit but low business value may be tolerated, one with high technical fit and business value is worthy of investment, one with low technical fit but high business value is a candidate for migration to more strategic technology, while an application with poor technical fit and business value is a possible candidate for elimination from the estate. The calculated field Strategic Rating contains the name of the quadrant in which the application sits, and a bubble chart showing the portfolio is included in the Application Portfolio: Usage, Value and Timeline presentation.

The Gartner TIME model

Once you have captured descriptive information about the applications and linked them to people and organizational units, you are able to conduct valuable analysis of your application portfolio and address some interesting business questions:

The presentation Application Portfolio: Usage, Value and Timeline contains a set of views that address all these questions.

We’ve seen how we can address some valuable questions by analysing the application portfolio. Now we’ll add a business dimension to that analysis, by exploring what the organization does and how it does it, using a combination of people (working together in organizational units) and technology (your application portfolio). A business capability model is one way to describe what an organization does, and references are used to connect the model to the people and technologies that realize the capabilities.

The following diagram shows the Ardoq Foundation metamodel as it relates to the business capabilities workspace.

See Ardoq Foundation: Metamodel for a definition of each field and reference type.

A capability model is modeled as a hierarchy of capabilities, with child capabilities representing a decomposition of their parent. See Getting Started with Business Capability Modeling for a more detailed overview of the subject.

The capability model provides an abstracted view of what an organization does, and it can be used as a lens through which to view how each capability is realized in practice. Business capabilities are realized by a combination of organizational units and applications, modeled using the Is Realized By reference type. Dependency maps are an excellent way to view information about organizational units and applications from the perspective of the capabilities they help to realize. For example, a dependency map visualization can show you which capabilities are realized by applications that offer poor business value or are a poor technical fit. Linking business capabilities to the components that realize them, along with their descriptive characteristics, opens up the ability to address a long list of valuable business questions, including the following:

The presentation Business Capabilities and the Value of IT contains visualizations that address these questions.

Having populated your architecture repository, it is important to make sure that it can be sustained. If data is mastered elsewhere, you should set up processes to synchronize the data, aiming for as much automation as possible. Information should be regularly reviewed and updated where necessary to ensure that your Ardoq knowledge graph remains an accurate digital twin of the organization, its people, capabilities and applications it represents. As previously mentioned, deploying the Application Ownership Process is a good way of ensuring that all applications have an owner, and that data about applications are regularly reviewed.

Two dashboards are provided to support you in your effort to populate your Ardoq Foundation repository consistently and keep it up to date:

The Data Quality dashboard provides key quality metrics for the components in each of the four workspaces: Applications, Business Capabilities, Organizations and People. It summarizes the amount of data you have in your repository and highlights anomalies and components that are missing essential field values.

The EA Progress dashboard highlights three measures of success that we believe you should strive to achieve:

These measures are shown at the top of the dashboard as three percentage scores, with a target of 100% in each case. The percentage scores are calculated with Gremlin code in the Metrics report, which can easily be changed if you wish to set different measures of success. Next to each score is a widget showing its trendline, and a further widget that summarizes the applications that fail their corresponding target. Selecting the report for that last widget will show the full list of those applications.

Report broadcasts have also been created to alert a selected audience when each measure has passed the 75% mark, and again when they achieve the target 100%. There is therefore a pair of broadcasts for each measure - six in total. To configure and deploy them, just edit each one in the Broadcast builder and change the email address of the broadcast’s audience in section 2 Select audience to the most appropriate recipient or recipients in your organization. Then save your changes and click on the Launch broadcast button.

These broadcasts will be triggered when their target thresholds are crossed or reached (75% or 100% depending on the broadcast). They are triggered by success. You might also wish to create a set of broadcasts that warn the recipient that the trend is in the opposite direction - for example, when a downward trend passes below 90%. This could be a useful call to action. You can make a copy of a broadcast, and can easily change the conditions of a renamed copy so that it triggers when the percentage value passes below 90.

Once you have a populated, sustainable foundation that is able to demonstrate value to some of your stakeholders, you may wish to move on to delivering further value to more stakeholders, addressing additional business questions. Whilst this might be achievable by adding more components to your existing model (i.e. addressing another “cake slice” with the Foundation metamodel), it is quite likely that you will need to extend your metamodel by deploying more Solutions.

Before you deploy your next Solution, we recommend that you revisit the mandate you established at the outset, review your goals and objectives, and consider which stakeholders you wish to help next. It is wise to build on your foundation step by step, tackling a Solution at a time so that your metamodel and its graph of data grow incrementally. There is no need for a “big bang” approach, and you should always keep in mind the following two golden rules:

Ardoq’s Solutions build on the Foundation metamodel in different directions. The Strategy to Execution Solution brings corporate strategy and objectives into the Ardoq model, allowing you to link them to initiatives and the parts of the organization that are impacted and transformed by them. Some Solutions extend Applications into their supporting services and underlying technologies, some explore how data is exchanged between applications, helping you understand the interconnected nature of your applications estate and its reliance on business critical data. Others expand your understanding of how the business operates, what its processes are and the people, data and technologies that those processes rely upon. You can explore the cost of your IT estate, relating it to the organizational units and business capabilities that make use of it, and analyse risks, regulatory compliance and controls, and apply a layer of architectural governance and quality management across your architecture repository.

All of these build on the solid platform of Ardoq Foundation. Whichever direction takes you to the greatest value for your organization, we wish you a successful onward journey!