Arquitectura y Diseo de

Software
ESTRUCTURA DEL CURSO

Sesiones

Introduccin Arquitecturas de Informacin Arquitectura Empresarial Proyectos de Investigacin

Arquitectura de Sistemas Big Data TOGAF
Cloud Computing Data Lake Ejemplos AE

Tacna 2017 Mayo

ESTRUCTURA DEL CURSO

Sesiones

Introduccin Arquitecturas de Informacin Arquitectura Empresarial Proyectos de Investigacin

Arquitectura de Sistemas Big Data TOGAF
Cloud Computing Data Lake Ejemplos AE

Tacna 2017 Mayo

Arquitectura Empresarial
Arquitectura

Punto de enlace entre

lo bonito y lo funcional

Casas o edificios que sean lindos

dentro de un contexto, pero que
sirva para lo requerido
Problemas que queremos resolver con la
Arquitectura de TI

La falta de Aplicaciones
alineacin entre desintegradas
TI y el negocio (silos).
La falta de alineacin entre TI y el negocio

Como puede la TI apoyar la estrategia

Tipos de estrategia:
Operational excellence
Eficiencia en los procesos
Volumen y bajos costos
Product leadership
Innovacin en producto y mercadeo
Customer intimacy
Excelencia en el servicio al cliente
Aplicaciones desintegradas (silos)

Duplicidad de datos y
funcionalidad
Organizacin funcional
de la empresa
Diferentes
departamentos para
diferentes funciones
Cada departamento
tiene su propio sistema
No existen procesos
Qu es Arquitectura Empresarial?

Arquitectura:
El Arte y Ciencia de disear para edificar y construir

Arquitectura Empresarial:
El Arte y Ciencia de disear estrategias de TI para las
empresas que innoven y agreguen valor
Por qu es necesaria Arquitectura Empresarial?

Una arquitectura empresarial permitir por ejemplo:

Focalizar el desarrollo de aplicaciones en la implementacin de soluciones de negocio.

Mejorar la calidad del resultado final de los desarrollos reforzando el uso de estndares.
Reducir la complejidad y los tiempos de desarrollo (time to market).
Optimizar el rendimiento de las aplicaciones, favoreciendo su modularidad y
escalabilidad.
Simplificar el mantenimiento de aplicaciones.
Facilitar la portabilidad entre plataformas.
Predecir costes de desarrollo y mantenimiento de manera ms precisa.
Qu es una empresa?

Depto Depto Depto

Cliente A B C
Proveedor
Qu es Arquitectura de TI?

Organizacin fundamental de un sistema que

describe sus elementos y la relacin entre
ellos. Guiado por unos principios y pensando
en su evolucin.
Generar una estructura con una visin
Arquitectura Empresarial Arquitectura de TI

El arte y la ciencia de disear soluciones tecnolgicas

que produzcan valor a las organizaciones
Punto de enlace entre el negocio(objetivos,
innovacin, valor) y tecnologa.
Estratega de tecnologa para el negocio
El innovador de la empresa apalancado en la
tecnologa.
Arquitectura Empresarial Arquitectura de TI

La ciencia de alinear las necesidades de negocio y las

soluciones de TI, tal como existe hoy en da.

El objetivo de la arquitectura empresarial es maximizar el

valor de negocio entregado por la inversin en TI.
Arquitectura Empresarial

Es la organizacin lgica de los procesos de negocio y la

infraestructura de TI, reflejando las necesidades
de integracin y estandarizacin del modelo de funcionamiento
de la empresa.

La arquitectura empresarial ofrece una visin a largo plazo de

los procesos de la empresa, sistemas y tecnologas para que los
proyectos se puedan ejecutar y no slo satisfacer las
necesidades inmediatas.
Elementos de la AE

Requerimientos Stakeholders

logical layers,
Proceso tiers, Lenguaje
viewpoints/views

Modelos de Referencia
Requerimientos o Requisito

La arquitectura es un medio para asegurar que las

organizaciones pueden cambiar y satisfacer las demandas del
mercado y que operar de manera eficiente.

Un requerimientos describe una condicin o capacidad que un sistema

debe cumplir, ya sea derivado directamente de las necesidades del
usuario, o dicho en un contrato, norma, especificacin u otro documento
formalmente impuesto

Mecanismos para expresarlos

Casos de Uso
Historias de Usuario
Stakeholders

Quienes pueden afectar o son afectados por las

actividades de una empresa.
R. E. Freeman.Strategic Management: A Stakeholder
Approach (Pitman, 1984)
Deben ser considerados como un elemento esencial
en la planificacin estratgica de los negocios
Traduccin literal: Parte Interesada
Tambin son llamados interesados o involucrados en un
problema determinado, y que necesitan una solucin
Logical layers, tiers, viewpoints/views

Cuando dividimos todo en: negocios, informacin, aplicaciones e

infraestructura, estamos hablando de capas (layers) de la
arquitectura.
Cuando dividimos software en: la presentacin, lgica de negocio, y
componentes de datos, estamos hablando de niveles lgicos (tiers)
en el software
Cuando describimos el sistema de forma diferente dependiendo de la
perspectiva de la parte interesada(stakeholder), decimos que estamos
describiendo una visin (view) de la arquitectura desde un punto de
vista determinado (viewpoints).
Proceso

Seleccionar
Proyectos

Administrar Crear
Arquitectura Arquitectura

Comunicar
Arquitectura
Lenguajes y Modelos

La arquitectura se Lenguaje Alcance Audiencia Estilo

expresa usando Negocio, Arquitectos y

diagramas y modelos. Archimate Informacin y Stakholders Grafico
Tecnologa
Negocio, Arquitecto e
UML Informacin y Ingeniero de Grafico
Software Software
Existen diferentes Negocio Analistas de
lenguajes de modelado. BPMN (procesos) proceso Grafico

Grficos y Texto ERM (Entity Ingeniero de

Relationship Informacin software Grafico
Model)
Modelos de Referencia

Modelos genricos de referencia (plantilla) que pueden ser

utilizados como punto de partida para las organizaciones, para
estructurar su propia arquitectura de la empresa. Proporciona
un vocabulario comn.
AQPC (procesos). http://www.apqc.org
Business Information Services Library(BISL)
Modelos de Referencia de TOGAF
ETOM
Frameworks y Metodologas de AE

The Zachman Framework for Enterprise Architectures

The Open Group Architecture Framework
(TOGAF)
Federal Enterprise Architecture (FEA)
Gartner

http://msdn.microsoft.com/en-us/library/bb466232.aspx
Por qu se necesita un Framework?

Agiliza y simplifica la definicin y el desarrollo de

la arquitectura, asegurando un cubrimiento ms
completo de la solucin diseada
Asegura que la arquitectura seleccionada permita el
crecimiento futuro en respuesta a las necesidades del
negocio.
Por que disear una Arquitectura es un proceso
tcnicamente complejo, y el diseo de arquitecturas
heterogneas de mltiples proveedores es
particularmente complejo.
Desmitificar la Arquitectura Empresarial
ZACHMMAN
ZACHMMAN

Es el primer modelo de Arquitectura

Empresarial. Ao 1987.
Framework for Information System Architecture
No propone un mtodo especfico para
obtener cada elemento
Demasiados elementos. Estructurados y
organizados
The Open Group Architecture Framework (TOGAF)
The Open Group Architecture Framework (TOGAF)
The Open Group Architecture Framework (TOGAF)
Escoger un Framework
Innovaciones Tecnolgicas
CLOUD COMPUTING
MOVIL
INTERNET

AS-IS TO-BE
Arquitectura de Negocio Arquitectura de Negocio
proyecto

Arquitectura Arquitectura proyecto Arquitectura Arquitectura

de de de de
Informacin Aplicaciones Informacin Aplicaciones
proyecto

Arquitectura de Tecnologa Arquitectura de Tecnologa

Requerimientos del Negocio

Mercado y Competencia
Restricciones Legales
Crear Arquitectura
(Punto inicial de TOGAF)
Innovacin

TO - BE

Proyectos

Arquitectura Empresarial
Business Architecture - Arquitectura de Negocio

Procesos

Objetivos
Entidades
Actores de
Informacin
Procesos en la Organizacin

Excelencia Operativa
Estandarizacin e
Integracin
Simplificacin
Digitalizacin de Procesos
Autoservicio
Empresa 5 ceros
0 Inventario
0 Papel
0 Retardo
0 Desperdicio
0 Errores
Que es un proceso de negocio o Business Process ?

Es un flujo coordinado de BPMN

decisiones, eventos y
actividades, conducida por
participantes que actan
sobre datos, informacin o
conocimiento y que son
necesarias para lograr un
objetivo de la organizacin
Data Architecture Arquitectura de Informacin

La informacin es el mayor
activo de la empresa
Existen diferentes Master Data

Metadata

Analtica
dominios de informacin

Data
El modelo relacional y SQL no Data Data No
es lo nico que existe Estructurada Estructurada
Arquitectura de Informacin

Ontologas
MOF
Meta Modelo de Datos
ECORE
Entity framewo

Master Data
Metadata

Analtica
Data
Data Data No
Estructurada Estructurada
Application Architecture - Arquitectura de Aplicaciones

Aplicaciones y servicios para cumplir los objetivos

del negocio.
Las aplicaciones no se deben describir como software
complejos, sino como grupos lgicos de capacidades y
servicios.
Application Architecture Arquitectura de Aplicaciones

Antes de SOA Despus de SOA

Cliente

GUI
Aplicacin
Monoltica Lgica

Servidor BD

Archivos

SOA Open Group Reference

Technical Architecture - Arquitectura de Infraestructura

Describir la
infraestructura
tecnolgica
Servidores
Sistemas operacionales
Bases de Datos
Middleware
Redes
Canales
Routers
Firewalls
Ejemplo: Venta en mostrador

Descripcin de Negocio
Venta directa de productos especializados como:
empanadas, arepas, etc. Con una receta original
No existe ningn sistema de informacin
El segmento de clientes las personas que pasan
por la tienda
Propuesta de valor: la receta original y la atencin
por parte del dueo
Ventas diarias de 200 unidades
Ejemplo: Venta en mostrador
TO-BE

Objetivos del Negocio

Automatizacin del Servicio

Aumento de Ventas

Proyecto N
AS-IS Proyecto 2
Proyecto 1

Acceso Web
Dispositivos Electrnicos

Tendencias Tecnolgicas
Anlisis de Brechas
Anlisis de Brechas
Hoja de Ruta y Gestin de Portafolio de Proyectos
Project Portfolio Management (PPM)
IBM Rational Software Conference 2009

Los Project Portfolios son conjuntos de proyectos o programas

relacionados que pueden ser, desde el punto de vista de la inversin,
gestionados juntos.

La misin de la gestin del portfolio es alinear estas inversiones con

objetivos estratgicos del negocio y maximizar su valor, dentro de un
marco establecido de riesgo.

Riesgo aqu significa riesgo de la inversin

Investment risk es la incertidumbre de comprender el valor de un proyecto

Gestin de Portfolio es una disciplina financiera, no es una disciplina de

ingeniera

La Gestin de Portfolio incluye priorizacin, la seleccin, la iniciacin y la

revisin peridica para asegurar el alineamiento contnuo y el valor Las revisiones
pueden acarrear que el proyecto se acelere, se retrase o se cancele
Project Portfolio Management (PPM)
Evaluacin y ponderacin de todas
las iniciativas

Decisin por maximizacin del

valor/ROI

Planificacin y
establecimiento de
roadmaps/planes de
proyectos de alto nivel
Project Portfolio Management (PPM)
Los proyectos son trabajos relacionados en el tiempo que
producen un nico resultado
Los programas son grupos de proyectos que pueden ser
gestionados en conjunto
Recursos compartidos
Dependencias

La misin es la ejecucin del proyecto dentro de los

tiempos, costes y restricciones de calidad establecidos
Riesgo aqu significa Riesgo Operacional
Operational Risk es un evento que puede ocurrir y que impacta de forma negativa
Project Portfolio Management (PPM)

Planificacin detallada y gestin del

riesgo
Contabilidad del proyecto durante su ejecucin

Control del rendimiento en la ejecucin y tendencias

PPM: Pasos hasta maximizar el valor para el negocio

Fase 4

Valor
Valor
Fase 3
Optimizacin del Portfolio
Project lifecycle Cost/ROI
Valor y Riesgo del Proyecto
Fase 2 Resource capacity/demand

Alineacin del Portfolio / Seleccin de Proyectos

Propuestas y Casos de Negocio Scoring
and Ranking
Fase 1 Phase Gate y procesamiento de aprobaciones
Limpieza del Portfolio

Proyectos/Programas redundantes
Proyectos no estratgicos
Proyectos de poco valor o de alto riesgo

Visibilidad / Inventorio del portfolio de proyectos

90 Das 9 Meses 12 Meses

45 Das
Project Portfolio Management y Project Management
Seleccin de proyectos y procesos peridicos de revisin
System Architect
Enterprise
Architecture

Objetivos Estratgicos Objetivos Estratgicos Objetivos Estratgicos

Enterprise Architecture Enterprise Architecture Enterprise Architecture

Focal Point Project Evaluar Propuestas Revisar Portfolio Revisar Portfolio

Portfolio Mgmt.
Q1 Q2

Proyecto Aprobado Actualizacin Proyecto Actualizacin Proyecto

Project Conductor Ejecucin Ejecucin

Project and Program
Mgmt. I1 I2 I3 I4 I5 I6
Por qu hacer AE?

La empresa no cuenta con informacin confiable ni a

tiempo.
Existen muchos proyectos de TI y esto se esta
volviendo complejo de manejar.
Fusiones y adquisiciones de empresas
La empresa quiere eliminar una unidad o esta
buscando oportunidades de outsourcing.
Cambios en leyes que afectan el negocio.
Automatizacin de la relacin con clientes o
proveedores.
Relacin muy dbil entre las reas y TI
Sistemas desconectados (silos)
Qu conocimientos y competencias debe tener el AE?

Arquitectura de Arquitectura de Arquitectura de Arquitectura de

Dominios Negocio Informacin Software Infraestructura

Estrategia de Tecnologa y Negocios

Entorno de TI
Fundamentos
Conceptuales Requerimientos, Atributos de Calidad

Diseo

Dinmicas Humanas
TOGAF
 An Overview of
TOGAF Version 9.1

44 Montgomery Street
Suite 960
San Francisco, CA
94104 USA

Tel +1 415 374 8280

Fax +1 415 374 8293
www.opengroup.org

TOGAF is a registered trademark of The

Open Group in the United States and other
countries
Agenda
Background on TOGAF
TOGAF Version 9.1

56
What is
TOGAF ?
TOGAF, an Open Group Standard:
A proven enterprise architecture methodology and framework used by the world's
leading organizations to improve business efficiency
The most prominent and reliable enterprise architecture standard, ensuring
consistent standards, methods, and communication among enterprise architecture
professionals
Enterprise architecture professionals fluent in TOGAF standards enjoy greater
industry credibility, job effectiveness, and career opportunities
TOGAF helps practitioners avoid being locked into proprietary methods, utilize
resources more efficiently and effectively, and realize a greater return on investment
The Origins of TOGAF

A customer initiative
A framework, not an architecture
A generic framework for developing architectures to meet
different business needs
Not a one-size-fits-all architecture
Originally based on TAFIM (U.S. DoD)
Member (End User) Driven
Customer members demand architecture standards
Customer members select TAFIM as preferred starting point
DoD Information Systems Agency (DISA) donate TAFIM as base
TOGAF first published
93 94
TOGAF 7 Technical Edition
96
01 02 03 TOGAF 9 Enterprise
06 09
11
Edition

TOGAF 9.1
TOGAF 8.1.1
The Interoperable Enterprise TOGAF 8 Enterprise Edition
Business Scenario First TOGAF Certification
first published Program Launched
Why TOGAF ?
A comprehensive Vendor, tool and
general method technology neutral
open standard
Complementary to, not
competing with, other Avoids re-inventing the
frameworks wheel

Widely adopted in the

market Business IT alignment

Tailorable to meet an
organization and Based in best practices
industry needs

Possible to participate
Available under a free in the evolution of the
perpetual license framework
TOGAF Momentum
More than 100,000 downloads

Over 16,000 certified practitioners

More than 220 corporate members of The Open Group Architecture Forum

Over 55,000 TOGAF series books shipped

Association of Enterprise Architects membership at more that 20,000

61
TOGAF 9 Market Drivers
Ongoing quest for Boundaryless Information Flow
In a survey of members, the three most prominent views:
The need for closer alignment with the business
The desire for simple implementation, greater usability
The next version of TOGAF should be an evolution rather than a revolution
Consideration for different architectural styles, e.g. SOA
Security is an increasing concern for CIOs and Enterprise Architects due to disappearance
of traditional boundaries
Need for greater detail on Architecture Development Method (ADM)

62
Introducing TOGAF 9
Developed, reviewed and approved by a collaborative of 300 members from
some of the worlds leading IT customers and vendors
An evolution from TOGAF 8.1.1 that preserves existing investments
The core Architecture Development Method
Existing investment in people - knowledge and skills
Existing investment in tools
Expanded detail and clarification of existing proof points
Restructured for better usability
More focused on holistic enterprise change
Clear links between business and IT objects
Increased consistency of output

63
TOGAF 9.1
TOGAF 9.1 was released in December 2011
It is the first maintenance update to TOGAF 9
It is an upwards-compatible evolution from TOGAF 9, addressing
usage feedback and comments raised
It addresses over 400 comments received
Contains over 450 changes
TOGAF 9 Technical Corrigendum 1 (Document U112) is available
describing each change in detail
The TOGAF 9.1 Standard
Part I - Introduction

Preface, Executive Overview, Core Concepts, Definitions and Release Notes

Part II Architecture Development Method

Introduction to ADM
ADM Phase Narratives
Part III ADM Guidelines and Techniques
Guidelines for Adapting the ADM Process
Techniques for Architecture Development
Part IV Architecture Content Framework
Content Metamodel
Architectural Artifacts
Architecture Deliverables
Building Blocks
Part V Enterprise Continuum and Tools
Enterprise Continuum
Architecture Partitioning
Architecture Repository
Tools for Architecture Development
Part VI TOGAF Reference Models
Foundation Architecture: Technical Reference Model
Integrated Information Infrastructure Reference Model
Part VII Architecture Capability Framework
Architecture Board
Architecture Compliance
Architecture Contracts
Architecture Governance
Architecture Maturity Models
Architecture Skills Framework
 Modular Structure
Content Framework
Extended Guidance
TOGAF Capability Framework Architectural Styles
Additional ADM detail

Informs the Sets targets, KPIs,

capability Architecture Capability budgets for
Framework (Part VII) architecture roles
Ensures Realization
Drives need for
of Business Vision Architecture Capability
maturity

Business needs Architecture Development Delivers new

feed into method Method (Part II) business solutions

Business ADM Guidelines &

Refines Business
Vision and Techniques (Part III)
Understanding Capabilities
Drivers
TOGAF ADM &
Architecture Content Content Framework
Framework (Part IV)

Enterprise Continuum &

Tools (Part V)
Informs the Business Operational changes
TOGAF Reference cause updates
of the current state
Models (Part VI)
TOGAF Enterprise
Continuum & Tools
TOGAF 9 Components
The Architecture Development Method

The core of TOGAF

A proven way of developing an
architecture
Specifically designed to address
business requirements
An iterative method
A set of architecture views to
ensure that a complex set of
requirements are adequately
addressed
ADM Basic Principles

An iterative method, over the whole

process, between phases and within
phases
Each iteration = new decisions:
Enterprise coverage
Level of detail
Time horizon
Architecture asset re-use:
previous ADM iterations
other frameworks, system
models, industry models,
Decisions based on:
Competence / resource availability
Value accruing to the enterprise.
 Prepare the organization for a
ADM Phases successful architecture project
Provide continual monitoring and a
change management process to
ensure that the architecture
responds to the needs of the
enterprise
Provide architectural oversight
for the implementation; ensure
that the implementation
project conforms to the
architecture
Analyze costs, benefits and
risks; develop detailed
Implementation and
Migration Plan
Ensure that every stage of a
TOGAF project is based on and
validates business requirements
Set the scope, constraints and
expectations for a TOGAF project;
create the Architecture Vision;
validate the business context; create
the Statement of Architecture Work
Develop Business
Architecture
Develop baseline and target
architectures and
analyze the gaps
Develop Information
Systems Architectures
Develop baseline and
target architectures and
analyze the gaps
Develop Technology
Architecture
Develop baseline and target
architectures and
analyze the gaps
Perform initial implementation
planning; identify major
implementation projects
ADM Phase Steps Example
ADM Guidelines and Techniques

A set of guidelines and techniques to support the application of the

ADM
The guidelines help to adapt the ADM to deal with different scenarios,
including different process styles (e.g. the use of iteration) and also
specific requirements (e.g. security).
The techniques support specific tasks within the ADM (e.g. defining
principles, business scenarios, gap analysis, migration planning, risk
management, etc).
Applying Iteration to the ADM

Example Guideline
Applying the ADM
Across the Architecture Landscape

Example Guideline
Categories of Stakeholder

Example
Technique
Architecture Content Framework
Provides a detailed model of architectural
work products, including Deliverables,
Artifacts within deliverables, and the
Architecture Building Blocks (ABBs) that
deliverables represent.
It drives for greater consistency in the
outputs of TOGAF
It provides a comprehensive checklist of
architecture outputs
It promotes better integration of work
products
It provides a detailed open standard for
how architectures should be described
It includes a detailed metamodel
Deliverables, Artifacts and Building Blocks
Full Content Metamodel with Relationships
The Enterprise Continuum
Architecture Repository
TOGAF Reference Models

Two Reference Models are provided

The TOGAF Technical Reference Model (TRM)
A Foundation Architecture
A model and a taxonomy of generic platform services
The Integrated Information Infrastructure Model (III-RM).
A model for business applications and infrastructure applications
Specifically aimed to support the vision of Boundaryless Information Flow
High-Level TRM
Detailed TRM
The Integrated Information Infrastructure
Reference Model (III-RM)
Capability Framework
Stand-alone or Complementary

Zachman Framework

Support or
Guidance

DoD Architecture Framework

TOGAF 9

Other Frameworks
Federal Enterprise Architecture Framework
Complementary

ITIL
Framework, method
and resources
IT Service Management
Best Practice

TOGAF 9

COBIT
Modeling languages
Governance and and notation
control
Summary
TOGAF, an Open Group Standard, is
An effective, industry standard framework and
method for enterprise architecture.
Complementary to, not competing with, other
enterprise frameworks
A repository of best practice
Vendor, tool, and technology neutral
A framework and method for achieving the
Boundaryless Information Flow vision
For More Information . . .

The TOGAF Web Site

http://www.opengroup.org/togaf/

The Architecture Forum

http://www.opengroup.org/architecture/

TOGAF Version 9.1 on-line

http://www.opengroup.org/architecture/togaf9-doc/arch/

TOGAF Version 9.1 licensing and downloads

http://www.opengroup.org/togaf/
Ejemplo de Arquitectura
Empresarial
Caso: Glugg Soluciones Web
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .

P
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
For More Information . . .
P
P