diff --git a/docs/Architecture.org b/docs/Architecture.org
new file mode 100644
index 0000000..2aa9bcc
--- /dev/null
+++ b/docs/Architecture.org
@@ -0,0 +1,123 @@
+#+TITLE: Arquitectura de graphPaname
+#+SUBTITLE:
+#+AUTHOR: Amin Kasrou Aouam, Alejandro Calle González-Valdés
+#+DATE: 2020-04-11
+#+PANDOC_OPTIONS: template:~/.pandoc/templates/eisvogel.latex
+#+PANDOC_OPTIONS: listings:t
+#+PANDOC_OPTIONS: toc:t
+#+PANDOC_METADATA: titlepage:t
+#+PANDOC_METADATA: listings-no-page-break:t
+#+PANDOC_METADATA: toc-own-page:t
+#+PANDOC_METADATA: table-use-row-colors:t
+#+PANDOC_METADATA: logo:/home/coolneng/Photos/Logos/UGR.png
+#+PANDOC_METADATA: lang:es-ES
+* Introducción
+
+El patrón arquitectónico es una solución general a un problema de ingeniería de software.
+Es esencial elegir un diseño adecuado, dado que esto nos facilita la
+implementación, además de evitar antipatrones de diseño.
+
+* Descripción del sistema
+
+El objetivo de este proyecto es crear un sistema de información que permite
+visualizar datos de una Smart City. Nos centraremos en la ciudad de París, dado
+que ofrece una gran cantidad de recursos públicos y actualizados.
+
+Es un sistema de procesamiento de datos, que podría enmarcarse en la disciplina
+de ciencia de datos. El funcionamiento de éste es lineal, a partir de una
+entrada (fuentes de datos), pasamos por distintas etapas de procesamiento, hasta
+llegar a la salida deseada.
+
+#+CAPTION: Diseño del sistema
+[[./diagrams/D1.png]]
+
+* Requisistos del sistema
+** Requisitos funcionales
+
+1. *RF1*: Obtención de datos
+
+   El sistema debe recolectar los datos necesarios, para su posterior
+   procesamiento, desde fuentes externas de información.
+
+2. *RF2*: Preprocesamiento de datos
+
+   El sistema debe adaptar la información procedente de distintas fuentes a su
+   representación interna de datos.
+
+3. *RF3*: Procesamiento de datos
+
+   El sistema debe clasificar los datos, según los parámetros que decida el
+   usuario, para obtener información relevante.
+
+4. *RF4*: Creación de gráficas
+
+   El sistema debe facilitar la información de forma visual, con distintos tipos
+   de gráficas.
+
+** Requisitos no funcionales
+
+1. *RNF1*: Seguridad
+
+   La página web de consulta será accesible únicamente mediante HTTPS
+
+2. *RNF2*: Escalabilidad
+
+   Se podrá aumentar el rendimiento de sistema, con escalbilidad horizontal y/o vertical
+
+3. *RNF3*: Disponibilidad
+
+   El sistema estará disponible 24/7, dado que usaremos un clúster de alta disponibilidad
+
+4. *RNF4*: Tolerancia a fallos
+
+   Se usará un clúster para permitir que siempre funcione el sistema, aunque
+   falle una parte.
+
+5. *RNF5*: Copias de seguridad
+
+   Se harán copias de seguridad diarias del sistema, además de enviarlas a otro
+   servidor en caso de que se pierdan los datos locales de backup
+
+6. *RNF6*: Rotación de logs
+
+   Se eliminarán los logs del sistema antiguos, cada semana
+* Elección del patrón arquitectónico
+
+A partir de la descripción del sistema, y de los requisitos de éste, procedemos
+a elegir (especificando las razones que nos llevan a nuestra decisión) el patrón
+arquitectónico adecuado.
+
+Como ya establecimos, nuestro sistema funciona de forma lineal, es decir que
+tenemos distintos módulos agrupados, a partir de una entrada pasa por distintas
+etapas hasta llegar a la salida deseada.
+
+Nuestro primer instinto fue elegir un patrón de diseño por capas, dado que nos
+permite separar la presentación de la lógica interna. Esta abstracción permite
+desacoplar la parte de procesamiento con la parte gráfica, un paradigma muy
+interesante que permite reemplazar un módulo sin reemplazar todo el sistema.
+
+Tras analizar que cada salida de un módulo, era la entrada del módulo siguiente,
+nos dimos cuenta que estábamos ante una /pipeline/, y decidimos adoptar el
+patrón aquitectónico de *flujos de datos*.
+
+#+CAPTION: Pipeline del sistema
+[[./diagrams/D2.png]]
+
+\clearpage
+* Descripción de los módulos
+
+Nuestro objetivo es establecer un diseño modular, no monolítico, con el fin de
+poder reemplazar los componentes individuales, según las necesidades.
+
+Para ello, dividimos nuestro sistema en 5 módulos:
+
+1. Interfaz gráfica (GUI)
+2. Controlador
+3. Procesamiento de datos
+4. Preprocesamiento
+5. Fuentes de datos
+
+Procedemos a desglosar las funcionalidades de cada uno de ellos en la siguiente figura.
+
+#+CAPTION: Descripción de los componentes
+[[./diagrams/D3.png]]
diff --git a/docs/Architecture.pdf b/docs/Architecture.pdf
new file mode 100644
index 0000000..9544d0f
Binary files /dev/null and b/docs/Architecture.pdf differ
diff --git a/docs/diagrams/D1.png b/docs/diagrams/D1.png
new file mode 100644
index 0000000..79608d4
Binary files /dev/null and b/docs/diagrams/D1.png differ
diff --git a/docs/diagrams/D2.png b/docs/diagrams/D2.png
new file mode 100644
index 0000000..dd03789
Binary files /dev/null and b/docs/diagrams/D2.png differ
diff --git a/docs/diagrams/D3.png b/docs/diagrams/D3.png
new file mode 100644
index 0000000..63caa4a
Binary files /dev/null and b/docs/diagrams/D3.png differ