Introduction
In an increasingly complex technological landscape, organizations are seeking ways to bring consistency and efficiency to their IT initiatives. Reference architectures can operate as invaluable blueprints, providing a structured and reusable foundation for designing and implementing solutions. Across industries, practices range from high-level conceptual models that outline principles and patterns to highly detailed prescriptive guides that dictate specific technologies and configurations, all aiming to reduce rework and accelerate delivery while ensuring strategic alignment.
This article will cover four approaches for establishing reference architectures and describe how Ardoq supports.
The Value of Reference Architectures
Reference architectures can support the delivery of value in the following ways:
Accelerated Delivery and Time-to-Market: By providing pre-defined, validated solutions and patterns, reference architectures allow teams to start with a strong foundation, reducing design and development time for new initiatives. They provide reusable “LEGO® blocks" for common solutions akin to the Architecture Building Blocks and Solution Building Blocks described within TOGAF.
Increased Consistency and Standardization: They establish a common language, principles, patterns, and building blocks across the organization. This ensures that different teams and departments design and implement solutions consistently, reducing divergence and fostering alignment.
Improved Interoperability: By defining standardized interfaces, protocols, and data formats, reference architectures can facilitate seamless communication and integration between different systems and applications, both within the
organization and with external partners.Reduced Costs and Optimized Investments: By promoting reuse of components, designs, and best practices, reference architectures help avoid redundant effort, reduce technical debt, and optimize IT spending. They help rationalize application portfolios and prevent the proliferation of similar, yet different,
solutions.Enhanced Quality and Reliability: Leveraging proven designs and best practices embedded in reference architectures leads to more robust, secure, and reliable solutions. They incorporate lessons learned from previous implementations, reducing the risk of design flaws.
Better Governance and Compliance: Reference architectures provide a clear basis for architectural governance, ensuring that new projects align with organizational standards, policies, and regulatory requirements. They offer a benchmark against which proposed solutions can be evaluated.
Facilitated Mergers, Acquisitions, and Outsourcing: A common architectural language and standardized approaches significantly simplify the integration of systems and processes during M&A activities, streamlining the management of outsourced services.
Improved Communication and Collaboration: They act as a common blueprint and vocabulary, fostering better understanding and collaboration among diverse stakeholders, from business leaders to technical teams, across different regions and functions.
Effective Knowledge Management and Training: Reference architectures codify organizational knowledge and best practices, serving as a valuable resource for onboarding new staff, training existing teams, and preserving institutional memory.
Strategic Alignment with Business Goals: By abstracting complex technical details, reference architectures help connect IT solutions directly to business capabilities and strategic objectives. This ensures that technology investments actively support and enable the overall business strategy.
Reference Architecture Stakeholders
Reference architectures may have a range of stakeholders and consumers, including:
Solution Architects are the primary consumers, having starting points and guidelines for designing specific solutions for projects. They instantiate the abstract principles and patterns into concrete designs.
Development Teams/Engineers can understand the prescribed technical stacks, coding standards, integration patterns, and deployment models, ensuring their implementations are consistent and compliant.
Project Managers leverage reference architectures for project planning, estimation, risk assessment, and ensuring that project deliverables align with organizational standards and strategic direction.
Business Stakeholders/Leaders, while not diving into technical details, benefit from the clarity and consistency provided, as they ensure that IT solutions are aligned with business capabilities and support strategic objectives. They gain confidence in predictable outcomes and faster delivery.
IT Management/CIO acquire an aid for strategic planning, technology roadmap development, investment decisions, and ensuring consistency and efficiency across the IT landscape.
Enterprise Architects (You!) are both the creator and a consumer. You maintain a holistic view of the organization's technology landscape, identify opportunities for standardization, and guide future architectural initiatives.
Security Teams can embed security principles and patterns, ensuring that solutions are designed with security in mind from the outset, aiding security reviews and compliance.
Operations and Infrastructure Teams can understand the intended deployment environments, infrastructure requirements, and operational best practices for new systems.
Compliance and Audit Teams acquire a basis for auditing adherence to internal policies and external regulatory requirements.
External Partners/Vendors can be provided clear expectations and guidelines, ensuring that external contributions align with the organization's architectural standards.
Types of Reference Architecture in Ardoq
Across the industry, reference architectures are used in different ways. The most common of these, and how they are supported within Ardoq, are described below.
Reference Architecture as… Industry Standard Models
Industry-standard models can help accelerate the development of custom frameworks or even shortcut the need for them altogether. They can act as a useful point of shared context when working across organizational boundaries or provide assurance when seeking different levels of regulatory compliance.
Ardoq provides a range of industry-standard resources and frameworks that can be imported and applied as needed. For a full list of all the resources available and how to download these using the Frameworks and Resources Importer, please see: How to use the Frameworks & Resources Importer | Ardoq Help
Reference Architecture as… Technology Reference Models
Technology Reference Models generally focus on the standardized classification and categorization of technology components. They provide a common, abstract framework that guides technology choices, promotes interoperability, and ensures consistency in the underlying technical infrastructure across an organization.
This can be achieved in Ardoq in two ways:
Firstly, through the creation of a Technology Product Catalog and the identification of approved standards within that catalog. Further details on the mechanism for achieving this can be found in the Technology Portfolio Management Solution. Ref: Technology Portfolio Management: Purpose, Scope, and Rationale | Ardoq Help
Secondly, through the extension of your technology product catalogue to incorporate references from your Technical Capability model. For further information on this topic, see: Creating Technology Reference Models and Standards in Ardoq
Reference Architecture as… Policies, Principles, Decisions, Standards, and Frameworks
Occasionally, reference architectures might be realized as a collection of architecture records and artefacts that help set constraints and provide context for solution design and architectural governance.
The creation and management of effective architectural records can provide several benefits, including:
Socializing decisions by capturing and communicating the rationale for key architectural decisions
Supporting audit and regulatory requirements
Tracking decisions by using automation to keep information up to date
Tracking the progress of implementing an adopted standard, policy, or framework
Identifying assets that do, or don’t, comply with, or are impacted by, given requirements
Bringing rigor and consistency to the adopted approaches, e.g., quality models
Ardoq’s approach to managing these can be found in the existing Solutions and help articles below:
Architecture Records: Solution Configuration Guide | Ardoq Help for guidance around decisions, standards, and compliance
Solution Health Check: Purpose, Scope, and Rationale | Ardoq Help for guidance around the use of quality models
How to represent Policies, Principles, Standards, and Frameworks in Ardoq for guidance around the use of policies, principles, and other artefacts
Reference Architecture as… Patterns
The most common manifestation of reference architecture is that of a software pattern. Such architectures are regularly published by technology providers to guide implementations or are defined and shared within organisations to streamline design and governance processes.
For this reason, Ardoq created the Pattern component type as part of the Architecture Records Solution (REC). This presents a flexible and extensible approach to managing architecture records. The approach described here builds on that Solution to support the use of reference architecture patterns.
The REC Solution provides a Pattern Library that can be created from available standard libraries, such as the Green Software Patterns, shown below, or existing in-house patterns.
Fig.1 The Green Software Patterns pattern library
Fig.2 An example of a Green Software Pattern
The Ardoq pattern library can also be used to reference both internally and externally defined reference architectures, such as those provided by public cloud providers (examples below) or those identified by the enterprise architecture team.
Fig.3 Public cloud provider-defined reference architectures
To access the visual representation of the reference architecture, the Document URL field* can be used to link to the relevant diagram in any 3rd party system or external website e.g. VIsio, Confluence, SharePoint, AWS
*included in later versions of the Architecture Records Solution. You may need to add this if you are on a previous version of the Solution.
An alternative is to use the native LucidChart integration to link to the appropriate diagram within Lucid, which can then be accessed without leaving Ardoq.
Fig.4 An example reference architecture natively linked to LucidChart
Fig.5 A Lucid-hosted reference architecture displayed in Ardoq
Providing a searchable set of reference architectures can be a valuable starting point for solution design as well as an aid to architectural governance. The existing patterns metamodel can be further extended to make this even more useful.
The metamodel below represents the existing Patterns metamodel, and also recommends the addition of an Owns reference from the Person component.
Fig.6 Metamodel for implementation of reference architecture patterns
The model above can provide several benefits:
By referencing the Applications that are subject to, or that incorporate, this pattern, you can provide a set of design constraints for the development of the application. This can help identify points of escalation in the design, should the implementation diverge from the pattern. This, in turn, can act as a point of governance for solution delivery and for the identification of technical debt within existing applications.
By linking to the Technology Products that realise the pattern, you can provide design constraints around the selection of standard technologies without needing to participate in detailed design. This can also serve as a point of governance for ongoing technology choices or in the identification of technical debt.
The inclusion of an owner for the pattern allows accountability for reference architectures to be shared amongst the expert community. For example, secure-by-design architectures may be owned by the cybersecurity team lead. This owner can also act as a key stakeholder in escalations and exceptions.
Note: You may update the existing surveys supporting design patterns to incorporate the collection of this new information.
The example below shows a software pattern for an AWS Web Application, which includes the link to the documented pattern, whilst also referencing the owner of the pattern (from an organizational perspective), an application that is intended to realize the pattern, and the technology products included within the pattern.
As with similar abstract component types (e.g., Business Capabilities, Value Streams), the ‘Is Realized By’ reference is used to show how this Pattern is, or is intended to be, implemented by, or within, specific Applications. The ‘Includes’ reference is used to capture any particular technology choices contained within the Pattern by referencing the relevant Technology Products.
Note: Linking Technology Products at the level of the pattern does not show the linkage from the Product to the individual elements of the Pattern. This can be seen by following the link (Document URL) to where the Pattern is fully documented. For the example below, see: Web Application Architecture on AWS
Fig.7 Reference architecture pattern with owner, subject, and included technology products
By completing the circuit from the Application implementing the Pattern through its supporting Technology Services to the deployed technology Products, you can then compare the implemented technologies to those specified within the Pattern. The example below shows the Technology Products used by the realizing Application and identifies a divergence from the pattern, the use of Aurora instead of RDS. This may then be the subject of an Exception, a Decision, or even a technical Debt Item.
Fig.8 Reference architecture pattern with realizing the application