diff --git a/src/sa/model/index.md b/src/sa/model/index.md
index 62d4000..bf20958 100644
--- a/src/sa/model/index.md
+++ b/src/sa/model/index.md
@@ -1945,7 +1945,10 @@ Exceed: 1-5.
 
 }
 
-1. As a user case scenario, I choose to require supporting the Amazon Alexa voice assistant to allow its users to alter smart device states by voice command. To achieve this functionality, I define new logical, process and deployment view to show how the Alexa API is integrated in the architecture.
+1. As a user case scenario, I choose to require supporting the Amazon Alexa voice assistant to allow its users to alter smart device states by voice      
+  command. To achieve this functionality, I define new logical, process and deployment view to show how the Alexa API is integrated in the architecture. 
+  In short, I plan to implement this functionality by defining a Skill with the built-in specification language using Javascript. This skill will then
+  call (through the Skill API) the Users and Devices component to execute the REST translation of the given voice command in SmartHut.
 
 ## Logical View
 
@@ -2167,6 +2170,10 @@ node "Device" {
   [Web Based User Interface] as UI
 }
 
+node "Smart Assistant" {
+  [Amazon Echo] as ECHO
+}
+
 cloud "User owned smart devices" {
   [Homekit Smart Device] as HD
   [Homekit Smart Sensor] as HS
@@ -2183,6 +2190,8 @@ cloud "Alexa" {
   [Alexa Smart Home Skill API] as AL
 }
 
+ECHO -- AS: HTTPS
+
 UW -- HD: Homekit protocol
 UW -- HS: Homekit protocol
 UW -- MD: MQTT
@@ -2201,3 +2210,132 @@ skinparam shadowing false
 skinparam defaultFontName Courier
 @enduml
 ```
+
+3. I now consider the hypotetical scenario where the current HomeKit API is deprecated. I consider the scenario where Apple would introduce a new API version with breaking changes, requiring a whole new client library. By adopting the design chosen in **Adapters and Coupling**, specifically the two adapter design (one for the SmartHut interface and data structures, one for the protocol) for Smart Home protocol integrations, I would need to simply replace these two adapters (i.e. find a new client for this HomeKit V2 API and design a new adapter between the interface of this client and the one of SmartHut). The updated logical view (with the new components in grey) would be the following:
+
+```puml
+@startuml
+skinparam componentStyle rectangle
+
+!include <tupadr3/font-awesome/database>
+
+title Smarthut.sm Logical View
+
+interface " " as DIF
+interface " " as TF
+interface " " as SCF
+interface " " as SHAF
+interface " " as SZAF
+
+component "Homekit V2 Device Wrapper" as IOTHK {
+  interface " " as HDF
+  interface " " as HSF
+  interface " " as HAPF
+
+  [HomeKit V2 smart device] as HD <<user provided>>
+  [HomeKit V2 smart sensor] as HS <<user provided>>
+  [HomeKit V2 Client] as HAP <<external>> #CCCCCC
+  [SmartHut to HomeKit V2 Client adapter] as SHA #CCCCCC
+  
+  HAP--HAPF
+  HD--HDF
+  HS--HSF
+  HAPF)--SHA
+  SHA--SHAF
+}
+
+component "MQTT Device Wrapper" as IOTMQ {
+  interface " " as ZDF
+  interface " " as ZSF
+  interface " " as ZIGF
+
+  [MQTT smart device] as ZD <<user provided>>
+  [MQTT smart sensor] as ZS <<user provided>>
+  [paho.mqtt.java] as ZIG <<external>>
+  [SmartHut to paho.mqtt.java adapter] as SZA
+
+  ZD--ZDF
+  ZS--ZSF
+  ZIG--ZIGF
+  SZA--SZAF
+  ZIGF)--SZA
+}
+
+component "User Interface" as UIC {
+  interface " " as WSCF
+
+  [User Interface] as UI
+  [WebSockets API (JavaScript)] <<external>> as WSC 
+
+  WSCF)--UI
+  WSC--WSCF
+}
+
+component "Users and Devices" as DEV {
+  interface " " as DIDBF
+
+  interface " " as WSSF
+
+  [Device Engine] as DI
+
+  note left of DI: Already implemented using Spring Boot
+
+  [javax.websocket API] as WSS <<external>>
+  [User and Device DB <$database{scale=0.33}> (PostgreSQL)] <<external>> as DIDB
+
+  HDF )-- HAP
+  HSF )-- HAP
+  ZDF )-- ZIG
+  ZSF )-- ZIG
+
+  DI--(WSSF
+  WSSF--WSS
+  SHAF )-- DI
+  SZAF )-- DI
+  DIDBF-DIDB
+  DI -( DIDBF
+}
+
+component "Triggers and Automations" as TRIG {
+  interface " " as TDBF
+
+  [Trigger and Automation Engine] as T
+  [Trigger and Automation DB <$database{scale=0.33}> (PostgreSQL)] <<external>> as TDB
+
+  TDBF-TDB
+  T -( TDBF
+}
+
+component "Scenes" as SCENE {
+  interface " " as SCDBF
+
+  [Scene Engine] as SC
+  [Scene DB <$database{scale=0.33}> (PostgreSQL)] <<external>> as SCDB
+
+  SCDBF-SCDB
+  SC -( SCDBF
+}
+
+DI--DIF
+TF--T
+SCF--SC
+WSS <..> WSC: WebSocket protocol (RFC 6455)
+DI --( TF
+T --( SCF
+DIF )-- SC
+DIF )-- UI
+UI --( SCF
+UI --( TF
+
+skinparam monochrome true
+skinparam shadowing false
+skinparam defaultFontName Courier
+@enduml
+```
+
+5. As mentioned in the previous sections of the architecture document, SmartHut is designed to be deployed by choosing a monolith or "polilith" 
+  (microservice) configuration. Assuming a hobbyish user whose has previously chosen the "monolith" deployment wishes to migrate to the microservice 
+  configuration, the user would simply need to back up the monolith database, split the backup into three separate RDBMS instances, and install the three
+  engine components on separate hosts.
+  Given a monolith deployment simply combines all engine nodes into a single node and all databases into a single database, the "polilith" (microservice)
+  deployment view is the one presented so far in this model. The logical and process views do not change between deployment options.
\ No newline at end of file