Alejandro Bianchi, Presidente y Marcelo Luna, Gerente de Proyectos de Liveware IS S.A. 12º Congreso Internacional de Tecnología para el Negocio Financiero.

1. Alejandro
Bianchi
-­‐
Marcelo
Luna
GESTION
IT
CENTRADA
EN
ARQUITECTURAS

2. La
Visión
Arquitectónica
Cúpula
Galerías
Pacífico
–
Buenos
Aires
-­‐
Argen8na

3. El
Contexto
• Complejidad
de
las
soluciones
• Integración
• So@ware
abierto
–
So@ware
propietario
• Orientación
al
cliente
• Cloud
CompuEng
y
SOA
• Nuevas
oportunidades
y
formas
de
hacer
negocios
con
el
so@ware

4. Las
preocupaciones
del
CIO
• El
alineamiento
con
el
negocio
• La
jusEficación
y
los
beneficios
del
cambio
tecnológico
• El
impacto
de
un
cambio
tecnológico
• La
hoja
de
ruta
para
el
cambio
• Lograr
agilidad
gesEonando
la
Deuda
Técnica

5. Los
problemas
de
IT
• Diferentes
respuestas
a
la
misma
pregunta
• Nuevas
regulaciones
• Falta
de
agilidad
• IT
como
cuello
de
botella
• AcEvidades
repeEdas
y
esfuerzo
duplicado
• Decisiones
sin
información
consistente
• No
visualización
del
valor
agregado
de
IT

6. Qué
entendemos
por
Arquitectura?
La
Arquitectura
de
un
sistema
es
un
“puente”
entre
las
“La
Arquitectura
los
utakeholders
y
lsistema
es
da
necesidades
de
de
sn
programa
o os
grupos
l e
estructura
o
las
estructuras
del
distema
que
con8enen
producción
de
so?ware,
en
sonde
el
arquitecto
a
los
componentes,
las
decisiones
técnicas,
rde
esos
refleja
las
soluciones
y
propiedades
visibles
esuelve
conflictos
y
busca
consensos
entre
todos
los
componentes
y
las
relaciones
entre
ellos”
interesados/afectados
para
lograr
un
diseño
adecuado
a
los
obje8vos
de
negocios
[Bass,
Clements
&
Kazman
,
“So?ware
Architecture
in
Prac8ce”,
1998]
[…desde
1998]

7. Siempre
hay
una
Arquitectura…
•
Las
Arquitecturas
pueden
ser:
– Intencionales
– Accidentales
• Una
Arquitectura
intencional
puede/debería
reflejar
los
objeEvos
del
negocio
• Una
Arquitectura
accidental
deriva
en
una
estrategia
de
negocios
diWcil
de
Adaptado
de
Grady
Booch,
administrar
Handbook
of
So@ware
Architecture

8. Importancia
de
la
Arquitectura
Provee
un
vehículo
para
la
comunicación
•
entre
diferentes
stakeholders
• Es
la
manifestación
temprana
de
decisiones
de
diseño
• Es
una
abstracción
reusable
y
transferible
de
un
sistema.

9. Entrando
en
calor…
Glaciar
Perito
Moreno
–
Patagonia
-­‐
Argen8na

10. Contexto
técnico
• 5000
ATM´s
• 14
Millones
de
usuarios
• Operación
en
todo
el
mundo
• Más
de
55
soluciones
de
so@ware
Millones
de
transacciones
al
año

11. ESAS
preguntas
• “¿Qué
tan
adecuada
es
la
Arquitectura
actual
para
el
Negocio?”
• “¿Cual
seria
la
Arquitectura
apropiada
para
las
expectaEvas
del
Negocio?”
• “¿Qué
deberíamos
cambiar
en
nuestra
Arquitectura?”
• “¿Cómo
podríamos
construir
la
nueva
Arquitectura?”

13. Sistemas
complejos…estrategias
simples
Definir
el
Modelo
de
Calidad
Capturar
Drivers
de
Arquitectura
Capturar
findings
Priorizar
problemas
Trabajo
futuro…
Diseñar
Entender
Evaluar
Arquitectura
Evolucionar
Referencia
Entender
la
moEvación
del
Definir
la
Arquitectura
de
Negocio
Referencia
Entender
la
Arquitectura
actual
Definir
el
ciclo
de
vida
Capturar
los
ObjeEvos
de
Establecer
un
roadmap
Negocio

14. Explorando…
Cataratas
del
Iguazú
–
Misiones-­‐
Argen8na

15. Modelo
de
MoEvación
del
Negocio

16. Documentación
arquitectural…

17. …documentación
“arqueologizada”

18. Cruzando
puentes…
Puente
de
la
Mujer
–
Buenos
Aires
-­‐
Argen8na

19. Workshop
Atributos
de
Calidad
(QAW)
Análisis
de
MoEvación
Modelo
de
Calidad

20. Análisis
Cobertura
MoEvación
Análisis
de
Mo1vación
del
Negocio
con
Escenarios
Scenarios
by
Goal
TacEcs
by
Goal
Strategies
by
Goal
Can1dad
de
Escenarios
G02
-­‐
Strategic
Business
Goal
G01
-­‐
Strategic
Business
Goal
G04
-­‐Strategic
Business
Goal
G03
-­‐
Strategic
Business
Goal

21. Modelo
de
Calidad
Auditability
25
Time
to
Market
Reliability
20
15
Projected
Life1me
Diagnosability
10
5
Security
0
Availability
Reusability
Correctness
Performance
Conceptual
Integrity
Modifiability

22. Análisis
detallado

23. Evaluación
-­‐
ATAM

24. Escalando
la
montaña…
Cerro
Aconcagua
–
Mendoza
-­‐
Argen8na

25. Diseño
Dirigido
por
Atributos
(ADD)
Servicios)de) Servicios)de)
Arquitectura
de
Referencia
Servicios)Core
Front6End Back6End
Backup)&)Recovery
Monitoreo
Seguridad
Plataforma)de)Integración
Servicios)de)
Servicios)de)Ruteo Servicios)Legacy
Información
Servicios)de)Infraestructura

26. Roadmap
hacia
SOA
–
Estructura
Front0End* Core* Back0End
Services Services Services
Backup*&*Recovery
Monitoring
Security
Integra(on*Pla-orm
Informa(on* Rou(ng Legacy*
Services *Services Services
Infrastructure*Services

27. Roadmap
hacia
SOA
–
Ciclo
de
Vida
Modelos
Gobierno
de
la
Arquitectura
Materialización
de
la
Arquitectura
Conceptual
Análisis
Concepción
Modelado
Build
Ensamble
Deploy
Integración
Negocio
Diseño
Lógico
Arq.
SoPware
Principios
SOA
Standardized
Contracts
Loose
Coupling
Abstrac1on
Reusability
Autonomy
Stateletssess
Discoverability
Composability

28. AlternaEvas
Arquitecturales
Alimentación(de(Información
Espacio((Contenedor(Manejado(por(SLA)
Unidad(de( Unidad(de( Unidad(de(
procesamiento(A procesamiento(A procesamiento(A
Datos Mensajería Datos Mensajería Datos Mensajería
Master
Instancia(de(
Porción(de( función(map(1
Base(de(datos( datos(0
Porción(de(
externa datos(1 Instancia(de(
Porción(de( función(map(2
datos(2 Instancia(de(
Datos(de(salida
función(reduce
Instancia(de(
Porción(de( función(map(n
datos(n
Datos(
Datos(de(Entrada Fase)map intermedios Fase)reduce Datos(de(salida

29. Reconversión
de
Apps
a
SOA
Arquitectura
de
Referencia
Catálogo
de
Servicios
de
Negocio
Generalización
Expansión
Apps
Contracción
Especialización

30. Y
por
úlEmo…
Faro
del
Fin
del
Mundo
–
Ushuaia-­‐
Argen8na

31. QAW
ATAM
Current
ADD
Architecture
BMM
Reference
Architecture

32. Lecciones
aprendidas
• Los
métodos
y
las
técnicas
ayudan
a
mantener
el
foco
en
los
objeEvos.
• Los
stakeholders
del
Negocio
se
introducen
en
acEvidades
de
Arquitectura
sin
dificultades.
• La
Arquitectura
resultante
cuenta
con
sólidos
argumentos
y
jusEficaciones.
• Conceptos
y
principios
fundamentales
son
introducidos
tempranamente
en
la
organización.

33. Los
“extras”…
• Implantación
del
Area
de
Arquitectura
• EsEmaciones
• Integración
al
ciclo
de
vida
• Alcance
del
diseño
• Calidad
de
una
arquitectura

34. Conclusiones
Integrar
métodos
y
prác8cas
dproveer
rác8cas
a
e
El
proceso
de
+
esarrollo
debe
e
Arquitectura
ed
Conocimiento
d Ambiente
de
Trabajo
+
P a
toda
l s
una
debe
ser
áe
ffoco
en
los
Ocambio,
de
Negocios
organización
dgil,
ISION,
Raproceso
de
desarrollo
IT
manera
con
acilitar
un
l
bje8vos
eficiente
y
Ingeniería
d e
Vabierta
ITMO,
COOPERACION,
ú8l
para
sus
clientes
ANTICIPACION
y
SIMPLICIDAD
superior
deben
proveer
Valor
Agregado
a
la
organización

35. alejandro.bianchi@liveware.com.ar
marcelo.luna@liveware.com.ar
www.linkedin.com/in/mhluna
@marcelunalw