To clarify, there is no agreed-upon and practiced cross-sector definition of reference architecture. Perhaps I am being overly ambitious here; even within a single sector, practitioners, standards, and companies have their own tailored definitions and practices that may conflict with each other in terms of the attributes and qualifications of Reference Architectures as an Enterprise Architecture Artefact. However, in this note, I will look into the Reference Architecture (RA) definition, drivers, and attributes, and I have no intention of making this long.
The Concept
While the concept of Reference Architecture (RA) is not novel in the business world anymore, many expert architects do not share the same understanding of the constitution of RA, its value, the best approach to visualizing reference architecture, the right abstraction level, or how RA should be used in an architect's day-to-day job.
RA can be defined from different perspectives, including software engineering, software architecture, enterprise, and system engineering.
In this scope, I try to keep it as much as possible aligned with enterprise architecture and system engineering perspectives.
For instance, according to RUP Reference Architecture
in essence, a predefined architectural pattern, or set of patterns, possible partially or completely instantiated, designed, and proven for use in particular business and technical contexts, together with supporting artefacts to enable their use. Often, these artefacts are harvested from previous projects…
which clearly comes from a software engineering perspective and does not represent the system as a whole.
Definition
Let's get some terminologies and definitions reviewed before establishing a definition for RA.
- Architect The person, team, or organization responsible for systems architecture [IEEE 1471, 2000].
- Architecture The fundamental organization of a system is embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [IEEE 1471, 2000].
- Architecture Framework An architecture framework provides guidance and rules for structuring, classifying, and organizing architectures [DoDAF, 2007].
- Perspective The posture from which an observer may be analyzing a problem. For instance, a system may be analyzed from a developer’s perspective, a systems engineer’s perspective, or even a lifecycle perspective.
- View A representation of a whole system from the perspective of a related set of concerns [IEEE 1471, 2000].
- Viewpoint A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis [IEEE 1471, 2000].
It is no harm also to review the definition of a System (I like below definition):
A system is a construct or collection of different elements that together produce results not attainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents—all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior, and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected [Maier and Rechtin, 2000, mit.edu].
There are more software architecture/engineering terms which is been used in the architecture context which is good to distinguish while it is not the concern of this note:
- Architectural Style An architectural style tells us, in very broad strokes, how to organize our code. It’s the highest level of granularity, and it specifies layers, high-level modules of the application, and how those modules and layers interact with each other, the relationships between them.
- Architectural Pattern A pattern is a recurring solution to a recurring problem. In the case of architecture (architectural pattern), it solves problems related to architectural style, which has a large impact on the "code level" in application context, if you will. For example, an architectural patterns will answers to questions such as "What high-level modules will be in our Service-Oriented Architecture" or "How will they communicate, or how many tiers will our client-server architecture have?".
While I dislike going into further depth and like to keep things at the level of an architect in an enterprise, I will acknowledge that such terminology is used interchangeably in many - less technical - discussions to establish an argument only! As a result, consider another term:
- Design Pattern A Design Pattern, not to be confused with an Architectural Pattern, is more localized in a limited context within an Architectural Pattern and refers to a specific context of "Code" for example "How to instantiate an object when one engineer knows only what type to be instantiated at run time? (Factory Class?)
Note 1
I consciously chose to omit mentioning TOGAF's definition of the Architecture Framework as the most popular framework for enterprise architecture in order to provide a broader perspective and be framework agnostic at this stage (However, I will later add a TOGAF theme to this note as well).
Note 2
The definitions seem very software (or application) specific, but you can also understand their applicability in other bounded contexts, such as the Internet of Things or networks, once you try to place them there.
Current View of a Reference Architecture
As previously stated, there are several instances in technical literature and documentation where the term "Reference Architecture" is used with no clear explanation. As a result, the term "RA" has come to mean different things to different groups. I am borrowing a couple of definitions in different enterprises:
A:
Reference Architectures have been designed, tested, tuned, and documented, so you can reduce complexity, costs, and risks of deploying new technology in your enterprise. Before choosing to implement a Reference Architecture.
B:
a proprietary knowledge built on B's Group research and real-world experience from hundreds of global enterprise consulting engagements.
C:
A worked design of an enterprise-wide service-oriented architecture (SOA) implementation, with detailed architecture diagrams, design patterns, options about standards, patterns on regulation compliance, standard templates, and potential code assets from members
From the given descriptions, you may see how varied the definitions are. A is focusing on technology and implementation, while B is more about business objectives, and on the other side, C is focusing on "detailed" requirements and "detailed" architecture!
Today's practitioners can see those viewpoints of a reference architecture with a visible gap. Some major players in the IT world use the terminology Reference Architecture to describe infrastructure concepts such as layering, communication, and persistence.
Here is another example; let's label it as D:
A Reference Architecture" is discussed that provides guidelines for function allocation over products based on technology, life cycle, safety, and information characteristics.
In which you see D as an enterprise that established a Reference Architecture with a certain scope in mind, such as the domain of a set of applications that adhered to necessary baselines, legislation, domain constraints, and obligatory frameworks.
Note 3
The alphabetically labeled enterprises are actually referring to real corporates, which I decided to remove the brands and names from the context to avoid bias and subconsciously leaning to a certain definition, as I am not evaluating which is more correct in this note.
Influencing Factors
From what has been said thus far, it is evident that RA is well used, but in diverse contexts.
RA shall build a complete mental model, and based on that, RA shall capture the essence of AS-IS architecture as well as the vision for future demands by offering advice for constructing new architecture. Now is the time to see what TOGAF has to say about RA:
RA is a generic architecture that provides guidelines and options for making decisions in the development of more specific architectures and the implementation of solutions.
TOGAF expects RA to be an artifact in the "Architecture Repository" under "Reference Library", and even there, the issue has been addressed as a note:
The terms reference architecture and reference model are not used carefully in most literature. Reference architecture and reference model have the same relationship as architecture and model. Either can exist as either a generic or an organization-specific state. Typically, a generic reference architecture provides the architecture team with an outline of their organization-specific reference architecture that will be customized for a specific organization.
Multi-Factorial Impact
If you are designing a RA, you can usually spot two main rising trends that apply to all domains:
- Complexity, scope, and size of the systems
- Dynamic and unified features like time to marker, interoperability, flexibility, and adaptability
These two levers are to blame for the shift from "simple" to "highly complex" systems. In other words, from closed to disseminated. And by "disseminated," I don't just mean distributed (which is correct because the majority of today's systems are designed and, in fact, are distributed), but also multi-organizational, multi-domain, multi-tenant, multi-cultural, and so on.
Because the "multi" factors have reached a crucial level of chaos, here is where RA begins to take shape in organizations. The necessity to simplify product life-cycles in this "multiplicity" environment is the catalyst for RA, which will provide taxonomy and vision as well as a modular framework.
Effective Portfolio
Another reason to design and maintain a RA is to improve portfolio management effectiveness. At this point that I'm writing my notes down, I am convinced that an extremely important purpose of RA, if not its primary objective, is to cooperate or enable coordination from a portfolio management standpoint.
Speaking of objectives, RA can be considered a reflection of experience via architectural principles and practices. Let's name it an Architectural Know-How artefact in a specific context. Though I would have preferred to refer to it as a "specific context" or "domain" or "bounded context," I fear that in actual use, RA will provide more than one or a small number of domains or contexts.
The more solid an architect's Know-How(s), the closer she is to introducing Architectural Patterns; thus, RA can serve as an Architectural Pattern for future solution architectures. (In layman terms, a well-designed RA shall prevent reinvention of the wheel and instead revalidate the solutions for old and/or repetitive problems.)
Interoperability
Yes, I am referring to it as an independent and crucial aspect in the domain of system-of-systems. The usefulness and trustworthiness of apps are defined by a world with that level of integration and being operational as a component in a larger integrated environment. RA can allow interoperability by realizing concepts and defining functional attributes, compatibility, and domain expression. To put it plainly, RA will work to lower integration costs and improve integration reusability.
Ties with the Enterprise's Strategies
A RA is inextricably linked with organizations and, in a broader sense, an enterprise's strategy. Indeed, higher-level strategies will define the scope and context of a RA, as well as which of the aforementioned factors will be considered and what that entails in the RA context.
RA's overarching principle is to enable a common understanding of vision and future state architecture among various organizations, effectively serving as an elaboration stage for a specific strategy.
Historical Perspective
RA should be forward-thinking in general, as it is for future products by applying new strategies to new developments, and it serves as a foundation for future endeavors. If one's reference architecture design is entirely based on the past or current state, that state will become her future state, resulting in no new development or strategy alignment.
Change is the law of life. And those who look only to the past or present are certain to miss the future.! -John F. Kennedy
But it does not mean an architect shall ignore the past wisdom in new designs.
Reference Architecture's Architectonics
From what I've seen at various organizations, reference architecture is often used to describe documents that include technical architecture or technical design. I believe the architectonics of an RA artifact shall be a factor or consequence of the adopted (or bespoke) Enterprise Architecture Framework. If the enterprise uses TOGAF as its EA framework, one architect cannot develop a RA in isolation from BDAT. Yes, there will be situations where, at the discretion or domain of the organization, or even the organization structure, stepping into some area is not politically correct and requires the removal of one pillar. Consequently, I believe that the least a RA can do is tackle Business Architecture in addition to Technical Architecture. Moreover, Domain and Customer lenses must be incorporated in order to render the context meaningful and the artifact easy to navigate for the user. If these supplementary considerations are overlooked during RA design, RA will be used to drive solutions to problems whose nature and context are unknown.
RA shall not address features or functions, as they will be addressed independently during product development, but high-level requirements shall be indicated across the Customer Context and Technical Architecture boundaries.
Technical Architecture provides taxonomy for technology solutions in a variety of ways (most notably design patterns), whereas Business Architecture guides decisions by taking the business model and life cycle into account. This will be true for the customer context, which will facilitate decisions through consumer consideration built into the RA design. and there are specific and limited domains that constrain all of these.
Feedback Loop
RAs live in a feedback loop, and I will not use the term "evergreen" for RA because it does not adequately describe its complex life-cycle. RA's Design and Evolution are heavily reliant on feedback. While the implementation and engineering worlds impose architectural constraints, they are also sources of opportunities for RA evolution cycles.
In reality, the RA development cycle primarily starts with a set of activities that extract existing solutions and architectures, either directly or indirectly.
Architectural Patterns vs. Reference Architecture
Just think of architectural patterns as another piece of data you feed into RA.
It is true that many architects today have no relevant background or education; instead, they have gained some expertise and understanding in order to be called architects. Furthermore, there is a lot of unwritten knowledge in each organization that is only stored in leaders' minds. Given that, I believe that RA is one of the best artifacts for filling both gaps.
A RA's agenda includes capturing undocumented information in order to assist with new solutions or product designs. Patterns are one method for RA documentation because they are popular for their ability to translate undocumented information into documented knowledge for addressing the abovementioned knowledge gaps.
The Big Question: What Else Is There?
Prior to this, I mentioned the "Feeback loop." In addition to the feedback loop, other inputs to a RA include research, market trends, industry-proven practices, standards, and appetite. Specific models, protocols, and benchmarks must support a RA, among other things. This, I believe, will create another challenge in terms of simplicity and, as a result, the legibility of the RA.
Adoption and Management
I'd like to briefly skim the surface of reference architecture adoption and management before I wrap up and summarize the note.
RAs must be continuously and actively managed by artifact owners or architects to ensure that they are always up-to-date based on standards, emerging technologies, stakeholder dynamics, business models, and requirements, as well as external factors that have been discussed in this note.
Often, once a RA has been designed and developed, it will enter a maturity life cycle in which the RA is expected to evolve repeatedly, be maintained, and perhaps be refactored. To me, the Architecture Governance body is responsible for making the RAs discoverable, navigable, and understandable for stakeholders and consumers. I don't want to go into the area of the relationship between enterprise architects and other organizations because it is already contentious, but some factors make RA governance and adoption more difficult:
- In what kinds of situations should businesses adopt an RA?
- Should RA follow and adopt the organization's directives? What about business strategies, if yes?
- How much can one architect jeopardize the RA's integrity in the name of organizational alignment?
- Who shall be involved in the design and development of RA?
- How can architecture governance embed the RA in enterprises?
- What sort of tools and processes shall be in place for governing and managing RAs?
Let's Summarize
Now that we've established what RA is and what it typically entails, perhaps I can round out this lengthy note about RA by outlining some value propositions and suggestions.
What value does a RA propose, given all the resource-intensive tasks it undertakes, such as design, development, governance, and adoption? This is the main question that needs to be addressed.
There is no hard evidence to support the claim that a RA is beneficial to an enterprise or an organization in terms of, say, the money it saves or anything else of the sort. Therefore, the initial suggestion is to have metrics for sanity of RA, such as speeding up technology bidding, protecting the investment, providing transparency, and avoiding silo activities.
In general, by leveraging previously mentioned architecture, patterns, industry standards, and so forth, RA will offer a certain degree of risk mitigation for new solution design designs. Furthermore, RA is expected to regulate the complexity of a solution design for an identical reason. As it clearly provides context around the domain, business, and technical things, RA will unify comprehension about the components and elements of a solution design. Additionally, it is clearly an architectural artifact that aids knowledge management at the enterprise level and retains it for the purpose of further use.
..and Some References
I'm not sure if the references are still available because this write-up was written a long time ago and I only recently got the chance to publish it, so I haven't validated it against those sources at the time of publication (please email me if I'm missing any references). Thank you to everyone who helped shape this thought, including but not limited to:
http://www.architectingforum.org/
http://www.merriam-webster.com/dictionary/architecture
Systems Engineering Wiley Periodicals, Inc.
http://www.sun.com/service/refarch/
http://www.burtongroup.com/research_consulting/ref_architecture.asp
http://dev2dev.bea.com/2006/09/SOAPGPart2.pdf
http://www.artima.com/weblogs/viewpost.jsp?thread=17799
Zachman, A framework for information systems architecture
DoDAF, Department of Defense Architecture Framework, Version 1.5
http://www-128.ibm.com/developerworks/rational/library/2774.html
The Concept of Reference Architectures School of Systems and Enterprises, Stevens Institute of Technology
https://www.baesystems.com/en-us/definition/what-is-reference-architecture
The most recent source cited for this note's revision:
https://www.leanix.net/en/wiki/ea/reference-architecture
https://www.linkedin.com/pulse/what-reference-architecture-sunil-rananavare/
https://www.hpe.com/us/en/what-is/reference-architecture.html
https://itconnect.uw.edu/guides-by-topic/it-sourcing-standards/enterprise-architecture/resources/reference-architectures/
https://www.digital.nsw.gov.au/delivery/digital-service-toolkit/resources/technology-and-tools/reference-architecture
Cheers,
Mohammad Malekmakan
Disclaimer:
All opinions and content published in my blog and my social networks are solely my own, not those of my employer(s) and the communities I am contributing in.