What is a Reference Architecture?
A reference architecture is a generic type of architecture that identifies the normal outlines of a system. It does this by including generic elements, inside relationships, principles, and architectural guidelines that provide a core foundation on which we can build individual architectures. Technically, reference architecture is considered a form of enterprise architecture. In terms of the TOGAF 10 Enterprise continuum, a reference architecture is a Foundational Architecture, Common Systems Architecture, or Industry Architecture. The best reference architectures provide confidence that the problem, and that every important part is exposed.
Basically, a reference architecture is a document, or series of documents, that recommends how to integrate business elements and IT services and products into a solution. The reference architecture represents widely acknowledged industry best practices and often recommends the optimum delivery strategy for particular technology. An easy-to-understand reference architecture provides best practices and directs the adoption of sophisticated technological solutions.
Reference Architecture is usually broken up into purpose, principles, technical positions, patterns, and vocabulary to make information easier to understand:
- Purpose - Why do you employ Reference Architecture? At this point, you should be defining your goals, objectives, particular purposes, and challenges that need to be solved.
- Principles - Describe what has to be done in the form of high-level basic assertions of organizational tenets, culture, and values that are durable and seldom changed.
- Technical Positions - Decide what you'll do in terms of principles-based technical guidance, regulations, policies, agreements, protocols, and standards. Solutions are applied via technical positions, which assist limit and encourage compliance.
- Patterns - Examine a variety of representations of architecture, including tabular, structural, textual, behavioral, and graphical models. This should be carried out at a degree of generality, free from implementation-specific restrictions.
- Vocabulary - Create a glossary with definitions and phrases related to solutions.
The Basics of Reference Architecture
A reference architecture usually consists of a set of functions and some indication of how those functions interact with one another, with functions beyond the scope of the reference architecture, and with other functions.
Reference architectures may be developed at various abstraction levels. One that is quite abstract may display several pieces of communications network equipment, each of which performs a particular purpose. At a more basic level, one may show how several techniques (or approaches) work together in a computer program that is designed to carry out a certain specific purpose.
An example is provided by a reference architecture, which frequently relies on the generalization of a number of solutions. These solutions could have been organized and generalized to represent one or more architecture structures using a collection of patterns that have been seen in several effective implementations. It also demonstrates how to put these components together to create a solution. Reference Architectures will be created specifically for a given domain or set of initiatives.
The Main Components of Reference Architecture Frameworks
The use of Reference Architecture is encouraged by a number of factors. The Reference Architecture framework requirements must be met for it to be successful.
Setting a Reference
Reference architectures offer a framework for understanding a domain while serving as a jumping off point for your own business architecture endeavors. To save you from having to create the wheel, they provide you the fundamental structures. Enterprise Reference Architectures are particularly beneficial for those areas and components of your business where you do not have any direct competitors.
Benchmarking
Benchmarking within your sector is facilitated by the use of reference architectures. The distinctions between businesses are frequently not in how they designed, example, their business procedures, but in how they carried them out. Comparing those execution outcomes is made considerably simpler by using reference designs.
Compliance
Regulators frequently impose (or at least strongly suggest) reference designs. For instance, accounting techniques, procedures, and concepts are becoming more standardized and required. This results in company reporting standards all the way down to exchange standards like XBRL.
Interoperability
Organizations must interact and collaborate with a wide range of different parties in our increasingly networked environment. These linkages are made possible by the standards and building blocks offered by reference architectures. Another advantage of employing standards is that they increase flexibility since building blocks with standardized interfaces are simpler to interchange and simpler to construct standards if they are already standardized.
Acquisitions and Outsourcing
It will be considerably simpler to recombine two parties' materials in novel ways if they have a same language, adhere to the same standards, and recognize the same boundaries between functions, processes, and/or systems.
Why (and Why Not) Use Reference Architecture?
Reference architectures facilitate successful collaboration and communication between project managers, software developers, enterprise architects, and IT managers about implementation projects. A reference architecture anticipates and responds to the most frequent inquiries. As a result, they assist teams in avoiding mistakes and delays that may happen in the absence of a tried-and-true collection of best practices and problem-solving techniques.
Just as well, by reusing an efficient solution, adopting a reference architecture inside an organization speeds up delivery. It also offers a foundation for governance, ensuring the consistency and applicability of technology use within an organization. Many empirical studies in the field of software architecture have identified the following common advantages and disadvantages of using a software reference design in organizations:
- Enhancement of the software systems' interoperability by the adoption of a uniform approach and common information-exchange protocols.
- The utilization of shared resources to cut down on the development expenses of software projects.
- Since all parties involved have the same architectural approach, internal communication will be improved.
- Because of the requirement to understand its functionalities, developers' learning curves are influenced.
Would Reference Architecture Be Considered a Solution?
No, actually. Reference architectures would not technically be considered solutions or potential solutions. Reference architectures outline the requirements for achieving organizational goals and objectives. Solutions outline clear and detailed details of the procedures and resources (human and technology) required to deliver missions, capabilities, systems, and services in order to fulfill those company goals and objectives. The underlying structure of a system, as shown in its constituent parts, as well as the interactions between those parts and their surroundings, as well as the guiding principles guiding its creation and growth, are all described as solution architectures by the DoD IEA.
What Industries Use Reference Architecture?
Reference architectures are used by all qualified technology developers to specify required development procedures, minimize obstacles, maintain team focus, prevent cost overruns, and validate final products with customers. Additionally, the businesses that hire software and hardware engineers employ them for the aforementioned objectives.
There are a variety of reference architectures, including those for software, financial institutions, automobiles, boats, and more. For every new technology created on behalf of the United States, the U.S. Department of Defense (DoD), one of the largest organizations in the world that procures development of cutting-edge technologies through private developers in the defense community, publishes thorough, in-depth Technical Reference Architectures (TRA).
Good Reference Model Attributes
- It is consortia built, with more industry eyes. We recommend you use a consortium built Reference Architecture, like APQC or SCOR, before home-built or vendor built alternatives.
- It can frame the problem space.
- It can identify key elements.
- It can identify key relationships.
- It can tell you how to assess the system.
How do You Use a Reference Architecture?
There are three ways to use a good reference architecture.
First, it should provide a starting point for the basics. SCOR describes supply chain processes and three manufacturing models. Rather than start with a blank piece of paper. You have the essential core information already available. This way, you don’t spend time re-inventing the wheel when you don’t need to. Instead, one can work on the unique aspects of the wheel in their specific use case. Aircraft wheels need to accelerate from 0 to 140 MPH instantly. The Lunar rover wheels had to be very light, and not throw dust. Both are round, removable, and used to steer. It all comes down to use case.
Second, it should provide an understanding of how a system works. You don’t need to figure out the parts of a system and how they interact. Instead, one should look for how architecture optimizes the parts and interactions for one’s use case. Seven Levers of Digital Transformation is an excellent example.
Third, one should be able to use reference architecture in architecture governance. The reference architecture is used to assess a design to make sure the design considered all the expected needs of a system. For example, in GSRM, all revokable permits need a process for assessing whether the permit holder still gets to keep a permit and an appeals process. It doesn’t matter whether it is a driving license, medical license, or transporting nuclear waste permit all the processes need to be there.
At Conexiam, we have a paper on the Use of Reference Architectures for Digital Transformation available to read for more examples.
Examples of Reference Architecture
There are many examples out there of reference architecture:
- IT4IT is an information reference architecture for Information Technology functions.
- AUTOSAR is a type of component-focused reference architecture for vehicle software.
- BIAN is a reference architecture for the Banking Industry.
- SCOR is a reference architecture for supply chain.
- APQC provides cross-industry, or industry-specific, business process reference architectures. APQC is often used as a foundation for business process models or capability models.
- Eulynx can be used for traffic signaling systems.
- GSRM (a.k.a. Government Services Reference Model) provides a generic model of government services.
- EA Capability Reference Architecture is used to speed up the implementation of an EA team.
- JAVA EE is a type of layered reference architecture that is used for systems created through Java.
What is a TOGAF Standard Reference Architecture?
The TOGAF Standard, 10th edition (TOGAF 10) includes two reference architectures: the Technical Reference Architecture, and the Integrated Information Infrastructure Reference Model. Common understanding may be achieved with the aid of standardized terminology. In instance, reference architectural standards can provide a shared language. Reference architectures are useful because they provide as documentation of acknowledged common practice. The TOGAF Standard takes advantage of this and implemented reference architecture into its framework and methodologies.
Reference Architecture vs Reference Model vs Architecture Frameworks
Most people use Reference Architecture and Reference Model as synonyms. Technically, they are distinct, but the difference is irrelevant for most enterprise architects.
From a purist perspective, a reference model explains part of a system, and a reference architecture explains the entire system. In practice, the distinction tends to be tied to ‘the system.’ However, almost everyone uses the terms interchangeably. One would find it more useful to deliver useful architecture that guides change than spend time on semantic discussions.
A system's architecture is described as being represented by an architectural framework, which is an encapsulation of a minimal set of practices and criteria. Frameworks for architecture, like the TOGAF Framework, offer methods for describing and identifying the inputs required for a certain architecture as well as ways to characterize that architecture.
Therefore, without requiring any particular architectural type, architecture frameworks provide business architects with the tools they need to accurately express and gather requirements. Architecture frameworks give guidance for choosing which architectural "views" to construct as well as an example taxonomy of the many types of perspectives an architect may take into consideration.
Reference architecture goes a step further by expediting the process for a specific architecture type, assisting in the determination of which architectural approaches will satisfy specific requirements, and determining the minimally necessary set of architectural artifacts required to satisfy the "best practices" requirements for a specific architecture. Reference architectures place a strong emphasis on the "template" portion of the concept.
While it may be claimed that Reference Architectures offer more of a methodology than a framework does, Reference Architectures are still not truly distinguished by their methodology component. Both frameworks and Reference Architectures give best practices. However, the majority may be identified by their template element.
How was our guide to reference architecture? Tell us your thoughts on this form of architecture in the comments below.