Best practices in designing a blockchain-based enterprise architecture
In this article, guidelines are provided on how to design enterprise architecture, in this case involving blockchain and other technologies.
Enterprise architecture is a framework or model that describes the structure and function of an enterprise. It helps us analyse, design, plan, implement and maintain architecture components. What we define is a logical architecture not a physical architecture. That is the architecture describes what the components do, not how they are implemented in practice.
Architectures can include different types of components, such as business processes, organization units, people, devices, systems and IT infrastructure. Typically they focus on systems and supporting infrastructure, mapped onto a background of that shows business units or logical layers.
As an example, below is the OEL Foundation Enterprise Architecture. The OEL Foundation is a non-profit organization providing governance and resources for the development of the Open Enterprise Logistics blockchain ecosystem. The architecture shows the components used in delivery of logistics products and services to, or by, ecosystem participants.
How do we go about designing an enterprise architecture that includes blockchain technology?
There is no fundamental difference with designing any architecture — a blockchain is just another technical component. However, there are some aspects of blockchain technology, such as smart contracts, that should appear in the architecture as components.
So, how do we go about designing enterprise architecture in general?
There are no “right” or “wrong” answers, although some approaches are more useful than others. Remember that enterprise architecture is also a living thing that will change and evolve over time.
There are a few general guidelines that are useful in architecture design:
1. Keep it simple
2. Refer to industry examples and best practice
3. Understand relevant industry developments
4. Define an architecture boundary
5. Decide on an organizing principle(s) to use
6. Populate the architecture with relevant components
7. Cross-reference your final architecture with industry examples
8. Review and baseline the architecture
Keep it simple
In general, if something is not simple it is usually because the complexity reflects one or more factors such as: incomplete analysis and design, working at too low a level of detail, or trying to include too many things in the model.
Trying to fully use a comprehensive architecture standard such as The Open Group Architecture Framework (TOGAF) may also be inappropriate, other than for very large organizations.
Enterprise architecture can be designed using different degrees of complexity. Some enterprise architectures are very complicated and hard to understand, even by the people that are supposed to use them. It is better to keep the architecture as simple as we can, without losing key information. This helps people to understand and use the architecture and its components.
A block diagram is a good basis for a simple architecture. This allows us to see the main components and their broad relationship to each other, without describing in detail their function or connections.
Refer to industry examples and best practice
There are many examples of architectures, with varying complexity, different approaches and organizing principles, and with a large number of different types of components.
There is often no standard architecture framework or model that can be used as a reference. In the absence of this, we should look for architecture examples from leading industry participants or from academics. These can show us how others have approached architecture analysis and design, and can serve as the basis for our own architecture.
It is sometimes easy to find widely different approaches, which can be confusing.
One useful technique is to search for images using appropriate keywords and get a feel for which models appeal to you visually. Review these at a high level, without getting lost in the detail. Select four to five of them that seem particularly relevant for you for further review and reference.
See what they have in common and what differences there are. What is included in the architecture and what is not? Try to think about the organizing principle(s) used in their construction. What components are listed? Do not worry if you do not fully understand them or if they contain elements that seem irrelevant to you. Remember, there is no “right” or “wrong” answer.
For the OEL Foundation Enterprise Architecture we used architecture models from Ethereum, Ontology, CSCC/IBM, Tibco and selected industry participants as references.
Understand relevant industry developments
We are at any time working within the context of an industry and a set of technologies that are all continuously changing. This can make approaches that were used even relatively recently seem irrelevant and out-dated.
We have to try and understand current state of this context and also try to look ahead and identify likely future developments in the industry, the economy, and technologies. This is very difficult to do. The best approach is to try to identify broad developments that are going to be relevant.
For a blockchain-based architecture we are at more of a disadvantage here than usual, given the relative immaturity of the technology and the rapid pace of change.
For the OEL Foundation Enterprise Architecture we identified four categories of development in the market and technology that we feel are particularly relevant for the OEL Foundation ecosystem:
1. Digital Business Models
2. Blockchain technology developments (especially emerging ecosystem support)
3. The convergence of blockchain and messaging technologies
4. The increasing use and importance of Cloud-based services, such as Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS).
Define an architecture boundary
Like any system, we need to define the system boundary for our architecture, separating what is inside the system and what is outside the system.
Sometimes the boundary is not drawn in the right place. We may see a lot of external actors and 3rd party components (that are not used to implement the architecture directly) in an architecture. This does not help us to identify the essential internal components that will be used for the architecture.
If it is useful to look at the relationship of the architecture to its environment, this should be done using a graphical deliverable such as a context diagram. This is at a higher level of abstraction than the architecture itself.
For the OEL Foundation Enterprise Architecture we use 3rd party technology and standards in the architecture, and also connect to external parties and systems using architecture components such as APIs, messaging middleware and inter-chain integration components. We can regard all of these things as being inside the architecture boundary.
Ecosystem participants, external systems or devices, or the means used to integrate these with the architecture are outside the architecture boundary.
Decide on an organizing principle(s) to use
The organizing principle(s) helps us to structure the architecture and forms a basis for the assignment of architecture components to different parts of the architecture.
There are a number of approaches that we can take here, including one or more of the following:
1. End-to-end business process flow
2. Enterprise internal organization structure (with or without external relationships)
3. A standard reference model
We can try to use an end-to-end business process flow to organize components, such as going from a supplier to a customer. Architecture components are then organized along the implied process flow between these parties.
Often the architecture reflects the internal organization structure, which is composed of organization functions (or Organization Units) such as marketing, sales, operations, finance, etc. This may or may not also include connections with external systems or parties.
For the OEL Foundation Enterprise Architecture we use a variation of the ISO Open Systems Interconnection model (OSI model) as the organizing principle. The OSI model is a conceptual model that describes the communication functions of a telecommunication or computing system.
The OSI model uses seven layers, but a number of blockchain-based architectures use a three-layer model. These are sometimes variously named, but usually comprise a Platform (or Application) layer, a Protocol layer, and a Network layer. The term “protocol” can itself be confusing, ambiguous and open to interpretation. It may be useful to agree on what such terms mean, which helps to identify components that are relevant in that context.
Populate the architecture with relevant components
When we have the overall architecture structure we can then decide what components the architecture should contain and assign these to the relevant part of the architecture.
We can use components that we identified in reference architectures as well as components that we intend to incorporate that reflect known or assumed technological developments or requirements from ecosystem participants.
This is very industry and even organization specific so it is hard to give general advice.
Two general principles should apply though:
1. Components should broadly be at the same level of resolution
2. Limit the number of components
We do not want components to be significantly different from others in terms of size. This is often apparent where a component is called something like “core” which implies that it may be at a higher level of resolution than other components, and may need to be decomposed into logical parts.
It is useful to use a rule of thumb about the number of components that appear in the architecture. For a large, complex multi-national organization this can potentially be difficult as there may be hundreds of separate applications involved. These can though still be logically grouped into application categories. A common approach is to use seven plus or minus two components per layer, and to not have more than twenty components in the entire architecture.
Cross-reference your final architecture with industry examples
Finally you can review the architecture against the reference models that you identified initially, using these to cross-check your architecture for completeness and consistency.
Review each of the reference models against your architecture and see if the reference model components are present in your own. If they are not, ask why that is and if they need to be included. If your architecture has additional components, ask if these are needed and try to understand why they are not present in the reference model. They may not be relevant to that model’s context.
This is a good sanity check that your architecture bears some relationship to other models that you can see being used in practice.
Review and baseline the architecture
At this point you have a working model of your architecture. You can now circulate it for review by colleagues and other stakeholders, and try to use it in practice. You will probably find that some changes are necessary, which is normal. Do not be afraid to move components around if you think that they are not in the right place, or to remove or insert new components.
Don’t forget that Enterprise architecture is a living thing that will change over time reflecting changing needs of the organization or external changes in the industry or technology.
The enterprise architecture model can now be placed under version control and responsibility for its on-going maintenance assigned to a relevant function or party. In a large organization this may be a formal architecture function or an individual architect. In smaller organizations the function may be assumed by one or more individuals who are typically business analysts or system designers.
We hope that this article is useful in giving you some pointers on how to approach analysis and design work for your own enterprise architecture, and wish you good luck with this.
Mark Nelson is the CTO of the OEL Foundation. If you want to learn more about the OEL Foundation, please go to https://oel.foundation or contact the author directly at mark.nelson@oel.foundation
You can also join the Foundation on Telegram.
