How to Improve IoT Architecture Using Zachman Framework in 30 Days Cycle- Part 1
Updated: Dec 11, 2020
I found this perfect punch line on the net about IoT; it says “Connecting Anything to Internet ≠ IoT.”
IoT is a well-integrated, large system which contains multiple enterprises/systems/ applications, and thus, IoT Enterprise Model is a bundle of multiple Enterprise Model, and we need to emphasize on Network Model to connect effectively and have success. Enterprise Information Technology Architecture (EITA) advocates flexible architecture because rigid architecture and old data model based architecture is prone to becoming obsolete quickly.
Why we need Enterprise Architecture Framework to do IoT Modeling:
Here, Enterprise Architecture (EA) is required as IoT is a big project which spreads over many departments, projects, and disparate stakeholders. So we need an EA framework to understand what is supposed to be the model, how to classify these models and how to keep these models in a manner that all the stakeholders can get access quickly. Once the framework has been identified, the next question is how to use it.
I will be referring to Zachman’s Enterprise Architecture Framework in this blog and will use the term ‘framework’ to signify the same.
How to use Enterprise Architecture Framework to develop IoT Architecture effectively?
Identifying the anatomy of IoT enterprise architecture becomes simple as this can be guided by the framework easily. So we only need to identify the most important anatomy so that starting could be easy, but again this should be derived by the framework.
The framework guides us to maintain a relationship within the model to manage complexity. The framework has separate perspectives for architecture and engineering to handle the model and its complexity accordingly.
The framework directs us towards what is to be developed and in which perspective with how many details. The framework also guides us towards the relationship we must have for the models to connect to each other. The framework makes it easy to maintain Complexity Management by keeping complexity away from Architecture Elements or Building Blocks.
The framework drives the mapping of the model by classification of model.
The classification depends on the perspective and model (element) type. These models should be single variable type so as to map it inside the framework. All composite models and/or diagrams cannot be mapped within the framework.
In my opinion, the network model is fundamental to IoT implementation success as IoT project needs hundreds of smart devices connected to the system to achieve a defined goal.
The framework provides different perspectives for different stakeholders and ensures that every stakeholder is on the same page. This way the framework ensures coordinating and cooperating between all the stakeholders.
The framework provides traceability and alignment between models, this feature of the framework is useful to identify the dependent model or the most important model and impact on the system when modifying any particular model.
Through framework, change management will be effective and easy as IoT system is very complex and stakeholders should know that due to these particular changes which areas (i.e. service, data, device, etc) will be impacted.
Other Model vs EA Framework
For example, I will discuss ComVantage model for IoT architecture. At first glance, the diagrams seem to be complete, but the moment we decompose this composite diagram and put the entire architectural elements in the framework, then we can easily identify the missing parts of the diagrams. The Figure 1 depicts the same.
What is ComVantage methodology for IoT Architecture
ComVantage method is one of the domain specific enterprise modeling methods and it provides conceptual level modeling which may be addressed to an architect, engineer and some extent business stakeholders. It means this method is not completely enterprise architecture and only provides models for second, third and fourth rows.
Figure 1: ComVantage Architecture
In the figure 2, we can see that some of the perspectives are not addressed it means that corresponding stakeholders cannot communicate effectively, and so the problem of those areas cannot be solved by these models. Similarly, some elements are missing, so at the time of implementation concerned stakeholder needs to make an assumption, and they may or may not be the right person to take the assumption. It means architecture is not complete. Let see at a glance which models are missing.
Figure 2: ComVantage diagram decomposed put model in the framework
Figure 3: What is missing (i.e. explicit reference) in the ComVantange Architecture in comparison to Zachman Framework
The red marked cells in the above diagram depict missing model in corresponding cells.
The ComVantage methodology emphasizes on Function Model, Data Model and Network Model of corresponding perspectives only, which means they do not complete either (six) Perspective wise or (six) Element-wise. This methodology emphasizes on Business Process decomposition but does not say anything about where to place the decomposed components or how many types of variables should be used. This methodology emphasizes on Agile Modeling Method Engineering (AMME) approach which is not actually enterprise model.
I am not saying other architectures or models are wrong, but I strongly feel that we need Enterprise Architecture on top of IoT application architecture to make complete, robust enterprise architecture.
IoT : Key Elements of Enterprise Models
All the elements of architecture are basically key elements which you can’t ignore. However, they should be prioritized based on resource availability, stakeholder’s demand, ease of start, etc. As far as the framework is concerned, all the 36 cells (6 Variables and 6 Perspectives) are equally important and mandatory to make a successful IoT Product Architecture or Enterprise architecture. So all the variable types and perspectives are important but in my opinion (obviously in IoT context) these may be prioritized as follow:
– Variable Type (Column) – What, Where, How, Who, When and then Why
– Perspective (Row) – Contextual, Business, Logical, Physical, Technician,
Enterprise Perspective should not be prioritized otherwise we will not get the benefit of transformation (you need to write the script for custom transformation).
The relationship is significant across the column for the perspective. However across the row relationship is required but should be only immediate above and immediately below row, which required to identify dependency and identify impact due to any change. In other words relationship across the row is useful for matrix while across the column provides association type.
It means all the element types are important, so all the corresponding models are important too, and those models are as following:
• Data Architecture
• Function/API/Process/ Model
• Network Architecture
• UI/UX/Security Model
• Time/Event Model
• Business Rule Model
IoT Model – How to address QoS
IoT Architecture must consider Function related Quality of Services (QoS), i.e. Extensibility, Scalability, Modularity, Interoperability amongst mixed devices. So all the QoS parameters should be modeled as Non-Functional Requirement (NFR) and the associated/linked with the respective models, which will be responsible for implementation. Network Model of IoT is complex and the network related QoS is very important, especially if the number of IoT devices is very high. So Network related QoS and SLA are essential, and must be part of the model so that they can be tracked for implementation and can be checked as the impacted area for any modification. Designing and modeling of Sensor should be separate from Network designing but should be classified in “Where” column only.
Challenges
The physical Network model is more challenging due to numerous types of networks through various communication technologies and these technologies get changed very frequently, which reduces the lifespan of IoT implementation. So “Physical Model” must be separated to achieve “Time to Market” for subsequent release of IoT products. We should have Interface Model and Gateway Model part of Network Model so that Network Architecture Diagram can be generated on the fly for the problem area.
Reference:
https://www.researchgate.net/figure/ComVantage-high-level-architecture-of-the-collaboration-network-prototypes_fig1_237019378
http://www.comvantage.eu/results/simplified-machine-interface-for-remote-access-to-manufacturing-machinery-by-non-experts-or-automated-agents/
9 views0 comments