> For the complete documentation index, see [llms.txt](https://documentation.ardoq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.ardoq.com/ardoq-fundamentals/introduction.md).
# Introduction
An overview of broader Ardoq concepts to ground your organization's architecture documentation.
Ardoq models your organization in the form of a graph database. Graph databases are optimal for creating relationships between things and quickly discovering how they're interconnected.
Graphs are represented by nodes and edges — or, in Ardoq terms, components and references.
A simple Ardoq view showing technical ownership and expertise in an application.
## Components
Components is an Ardoq abstraction that can be used to represent and model any part of your organization. Components can be anything including people, business capabilities, virtual machines, physical office spaces, and so on.
### Component Types
All components have a component type that determines what they represent. A component of type Person represents a person — and will have fields associated with people like name and email address. A component of type Application will represent some sort of application and will have relevant fields like cost, technical fit, and lifecycle phase.
## References
The relationship between two components is called a reference. In Ardoq, a reference goes in a single direction between two components. Some common references include expressions like Person **owns** Application or Office **located in** Country.
When we talk about references in Ardoq, we not only talk about references between specific components — such as John **is an expert in** Ardoq — but also more generally about how component types are related to other component types. For instance, we can generalize "John is an expert in Ardoq" to "Person component types can be experts in Application component types".
While references tend to be simply expressed by a label, they can also have fields, in case the relationship itself needs additional details.
While you can create any sort of reference between two components in Ardoq, we recommend following the references defined in our Solutions.
## Metamodel
A metamodel is a representation of how different types of components are related to each other. The grand total of all relationships is a model of your organization and its constituent parts — including hierarchy, ownership, expertise, interfaces, business units, locations, and so on.
By default, Ardoq is flexible and does not prescribe a way for you to model your organization. You are free to build Ardoq around your own enterprise architecture practice. That said, in our experience, total freedom opens a lot of doors and pitfalls for enterprise architects seeking to get value as fast as possible.
### Ardoq Use Cases and Solutions
Ardoq's internal team of enterprise architects has created numerous best practice solutions for common problems in enterprise architecture. The goal is to set an appropriate scope for modeling your organization and focus on small incremental expansion into larger parts of the organization.
For example, below is the Ardoq recommended metamodel for the Application Rationalization (AR) use case. With just 10 component types and the relationships between them — along with the relevant data from your organization — you can begin to answer questions like:
* Which applications can be removed from my organization with minimal impact and what are my potential savings?
* Are we effectively realizing the capabilities in our organization?
* How well do applications satisfy technical and business requirements?
* What areas of my organization have the highest application function overlap?
We dive into more details about Ardoq's enterprise architecture use cases and solutions in the Ardoq Solutions section.
## Workspaces
Workspaces are containers for grouping components and references of related types.
A simple example would be a workspace for storing **People** components. Another example would be a workspace that stores organizations and organizational units.
Generally, workspaces can have unlimited amounts of component and references types inside them; however, we recommend keeping a ratio of one component type to one workspace.
References also exist in a single workspace, but unlike components they can point outside of their workspace. For example, using the examples above, we can say that **Person** components in the Person workspace have a reference to Organizational Units in their respective workspace.
In practice, this would be a reference like **Person** → Belongs to → **Organizational Unit** — or in a specific instance, **John Smith** → Belongs to → **Information Technology**.
