ponecia arquitectura ii jornada itsmf en sevilla

Hacia una mejora en la

eficiencia y predictibilidad

de los sistemas de

información empresariales

Ángel Hernández Bravo

II JORNADA itSMF en Sevilla

ARQUITECTURA EMPRESARIAL

20

MAR

2014

II Jornada itSMF en Sevilla. ARQUITECTURA EMPRESARIAL

2

Información sobre la organización y el ponente

International Business Machines

Executive IT Architect

Member CTO and TEC (IBM Academy of Technology Associated)

Member of AEA


3

IBM, John Zachman

He joined IBM Corporation in 1964 and held various marketing-related

positions in Chicago, New York and Los Angeles.

He became involved with Strategic Information Planning methodologies in

1970 and in 1973 he was assigned responsibility for the Business Systems

Planning (BSP) program in IBM’s Western Region.

He retired at IBM in 1990, having served them for 26 years. Afterwards he co-

founded, with Samuel B. Holcman, the Zachman Institute for Framework

Advancement

http://en.wikipedia.org/wiki/IBM

http://en.wikipedia.org/wiki/Marketing

http://en.wikipedia.org/wiki/Business_Systems_Planning


4

IBM, John Zachman

Six Hats, Six Coats: The

Structured Thinking System

http://relationary.files.wordpress.com/2007/07/asixhatsb.jpg

http://relationary.files.wordpress.com/2007/07/asixhatsb.jpg


5

IBM, Zachman framework, EA method


6

Para que una AE

Para desarrollar una arquitectura empresarial útil (EA), es

importante entender primero las preguntas que desea responder

con la arquitectura.

En base a estas preguntas, se puede desarrollar un enfoque e

identificar los modelos que se necesitan

Por último, se puede hacer un análisis cuantitativo y cualitativo

de la arquitectura ya sea para:

ver donde el negocio se puede mejorar

identificar los cambios o mejoras necesarias en la arquitectura


7

Que es una AE

Una Arquitectura Empresarial es una organización lógica de una

empresa así como sus datos, aplicaciones, y la infraestructura

de TI, con metas y objetivos claramente definidos para el futuro

éxito del negocio.

Una arquitectura típica consta de diagramas o modelos, que

muestran cómo se relacionan los diversos aspectos del

negocio.

Por ejemplo un organigrama es un modelo de cómo las unidades

de negocio se relacionan con

entre sí.


8

Que es una AE

La arquitectura empresarial alinea las siguientes áreas clave:

• Negocio: Procesos, estrategias, organigramas y funciones

• Información: modelos de datos conceptuales, lógicos y físicos

para mostrar qué información es necesaria y cómo se relaciona

con otra información, por ejemplo, un cliente y un pedido

• Aplicación: Carteras, interfaces y servicios

• Infraestructura: diagramas de conceptos de redes, modelos de

referencia de tecnología


9

Que es una AE

Las empresas deben tener:

una arquitectura AS IS que representa su estado actual, y

una Arquitectura planificada , TO BE, para mostrar la dirección de

la empresa durante los próximos uno a cinco años.


10

Que es una AE

Se debe modelar cada area de acuerdo a su perspectiva y

luego enlazar cada modelo para alinearlos.

En el modelo de procesos de negocio no se deben incluir

cosas como aplicaciones . Luego se enlazara con las

aplicaciones para alinearse, pero las aplicacciones no deben

dictarla forma en que un proceso de negocio es diseñado.

Cada decisión debe basrase en una necesidad de negocio.


11

Pasos para construir una AE

Paso 1: tener un proposito (¿para que se hace la AE?

Si no se tiene el proyecto AE fallará

SE deben contestar estas preguntas:

QUE información es importante para la AE?

QUE detalle se necesita para soportar el analisis y la toma de

decisiones?

QUIEN produce y usa la AE?

CUAL es el ROI esperado de la AE?

CUALES son las consideraciones de mantenimiento?


12


Paso 1: tener un proposito (¿para que se hace la AE?

Equipos no muy numerosos para capturar la información relevante

No ofuscarse con lo irelevante: no hace falta modelar 5’000 procesos

de negocio si solo 50 son críticos para el negocio


13


Paso 2: Identificar las preguntas principales del cliente

La AE proporciona una ruta para contestar preguntas

Hay que enfocarse en las preguntas críticas del cliente y luego

identificar las que son mas complejas de responder.

The hotel's purpose for doing architecture was to improve the check-in and

check-out experience so they could be more competitive.


14



Cual es el impacto de retirar una aplicacion?

Cual es el impacto de mover una LOCATION?

Que aplicaciones son necesraias para soportar un proceso ?

Que procesos se necesitan para desarrollar una nueva estrategia?


15



Las preguntas determinan el contenido de la arquitectura

Si hay mas preguntas relativas al portfolio de aplicaciones entonces

hay que enfocarse en ele area de aplicaciones

Despues ya se puede proceder a expandir la arquitectura con

nuevas preguntas.


16


Paso 3: Identificar asumciones y reglas de negocio

Ya hemos identificado: audiencia, proposito y preguntas

Ahora deb en identificarse las reglas de negocio que constriñen o

explican el area de interes

Cada negocio tiene reglas : regulaciones, estandares… (HIPAA, SO

O mas triviales: “cada LoB es responsible de documentar sus

procesos de negocio”


17


Paso 4: Identificar el framework mas apropiado

Zachman, AE3, TOGAF, DoDAF

Proporciona un esqueleto sobre el que insertar los modelos.

Proporciona uan guia sobre que información es necesario capturar

en base a los stakeholders que usaran la AE . Es una uia para

organizar la información pero NO sugiere una implementación

particular de la AE.


18



El framework a elegir depende :

del objetivo de la AE que hay que construir

de la experiencia del equipo

de si se quiere n seguir procesos ToGAF, o solo se necesita ayuda

para identificar que modelo usar para que proposito como en Zachman.

Se suelen combianr farmeworks . (muy usual : ToGAF y Zachman )


19



Es una guia para saber que modelar . Las metodologias se usan

para crear modelos .

Una metodología es una regla que explica como modelar algo :

P.EJ BPMN ES UNA METODOLOGÍA PARA MODELAR PROCESOS

DE NEGOCIO.


20




21



Un framework ayuda a organizar las key areas de la AE e

identifica las VIEWS que se necesitan para el modelo (perspectiva

y datos para contestar a preguntas de negocio ) .

Usar estandares (las cosas caseras fallan en la captura y el

analisis)

SE generan múltiples modelos dentro de la AE


22


Paso 5 : Crear un metamodelo

Un metamodelo es una vista abstracta de la AE : muestra los

datos a capturar y las relaciones entre ellos.

Permite ver el alineamiento que se basa en las respuestas a las

preguntas de negocio .

P. ej un a aplicacion que soporta un proceso de negocio , debe

reflejarse en una relación en el metamodelo. De otra manera no

hay conexion entre datos , no hay respuesta a una pregunta y la

AE no es funcional.

.


23



No hace falta una relacion entre todo con todo. Solo las que

tienen una lógica detrás

i.e.: enlazar un departamento organizacional a una tecnologia no tiene

sentido, pero si una tecnología a una aplicación

Una buena herramienta de modelado como Rational System Architect

soporta crear reportes complejos con cortes transversales del

metamodelo


24



El metamodelo debe soportar:

Relationships between the architecture elements.

Definitions of the elements.

Traceability to business questions.


25




26


Paso 6 : Identificar los modelos necesarios en la arquitectura

Ya esta identificado : el conjunto de pregunats de negocio, el FW,

el Metamodelo par responder preguntas

Ahora necesitamos los modelos a dibujar .

P. ej. : un business process. Hay varios estandares de modelado

como BPMN y los flow charts.

La audiencia: los managers comprenden BPMN; pero los software

developers prefieren UML sequence diagrams o use cases.


27



Implicación en el metamodelo:

Si es necesario linkar datos y procesos de negocio debe considerarse

BPMN . Pero si hay mas preocupacion por la secuencia de procesos es

mejor un flow chart. En este ejemplo necesitariamos:

BPMN (captura business processes) ,

System architecture (captura aplicaciones, interafces)


28



Usar buenas

herramientas


29


Paso 7 : Integrar la AE

Linkar los datos capturados basandose en las relaciones

identificadas.

Una herramienta NO hace esto mágicamente

SI, es muy dificil de hacer sin un repositorio . (descartar el Excel pls)


30


Paso 7 : Integrar la AE

Si hay ya arquitecturas parciales previas: poblar la AE desde

bottom up.

Poner los elementos comunes en un repositorio

Estandarizar modelos y terminologia

Si se parte de cero :

Usar un blueprint comun con todas las lineas de negocio usando el

mismo framework, terminologia y modelos


31


Paso 8 : Reservar fuerzas para analizar la AE

Si no se planifica , no habra tiempo a hacerlo y si no se hace, para

que se hizo?

Pistas:

50% del tiempo para analisis (revision de modelos, verificación y

validación)

Hacer análisis cualitativo y cuantitativo (ROI, cuellos de botella en un

proceso, ahorros de tiempo y costes , eliminación de redundancias.

BPMN permite reglas y estructuras valiosas para ello, las herramientas

incluye simuladores para estimar ..


32


Paso 8 : Reservar fuerzas para analizar la AE

El análisis cualitativo se hace mediante de una busqueda en el

modelo de potenciales problemas . P.ej un proceso de negocio que

da feedback a una parte anterior del proceso indica un posible

punto de revisión y refacorización (hay que evitarlos)

Cuando se termina el análisis se deben compartir los resultados

La gente verá valor en la AE si aprende a usarla

El reporte es el principal valor añadido de una herramientas de AE


33


Puntos importantes:

Necesitamos un plan

Temas administrativos a manejar : Como desplegar la AE? Donde?

Quine hay en el Team? Hay un AE?, Board de revision ?, Dirección

de proyecto , privilegios de acceso a la información


34


Puntos importantes:

No partir de cero:

- Sponsores

- Stakeholders deben estar involucrados en toma de decisiones


35


Puntos importantes:

Governanza:

- se requiere para una correcta toma de decisiones

- define las reglas y estrategias usada para la AE

- determina que modelos estan aptos para ser aprobados (Boards)

• Architecture review board

• Configuration and control board

• Administration guidelines (workflow de aprobaciones)


36

AE y otros frameworks


37

The IBM approach to architecture conforms to, or at

least aligns with, these key standards How we visualize our models

(“Views and Viewpoints”)

IEEE: Recommended Practice for ArchitectureDescription of Software-Intensive Systems (1471/2000)

How we organize our methods

Object Management Group: Software and Systems Process EngineeringMetamodel (SPEM)

How we model in the Functional Aspect

Object Management Group: Unified Modeling Language (UML)

How we reason about Enterprise Architecture

The Open Group:The Open Group Architecture Framework (TOGAF)


38

IEEE 1471-2000 Recommended Practice for Architecture

Description of Software-Intensive Systems

System Architecture

StakeholderArchitectural

Description

has an

described by 1has 1..*

identifies 1..*


39

IEEE 1471-2000 introduces the concepts of viewpoints and

views

Viewpoint View

Library

ViewpointModel

conforms to

consists of 1..*has source 0..*

establishes methods

for 1..*

participates in 1..*


40

The OMG Software and Systems Process Engineering

Metamodel (SPEM)


41

The Open Group Architecture Framework (TOGAF)

Technology Architecture

Application

Architecture

Data

Architecture

Business Architecture

Data

Information

Services

Business

Processes

Organization

People

Hardware

Software

Network


42

The six components of TOGAF 9


43

The “IT architecture” part of TOGAF’s Content

Framework…


44

…Compared with the IBM Views and Viewpoints Framework (1) (1 of 7)

The cube’s

conventional

arrangement

Functional Operational

Logical

Physical

Ap

pli

ca

tio

nTe

ch

nic

al


45

…Compared with the IBM Views and Viewpoints

Framework (2) (2 of 7)

The cube re-

arranged to highlight

the functional “face”

Application Technical

Functional

Operational

Lo

gic

al

Ph

ys

ica

l


46



Logical

functional

application


Functional

Operational

Lo

gic

al

Ph

ys

ica

l

The cube re-



Logical

Application


47




Functional

Operational

Lo

gic

al

Ph

ys

ica

l

The cube re-



Logical

functional

application

Logical

Application

Logical

functional

technical

Logical

Technical


48




Functional

Operational

Lo

gic

al

Ph

ys

ica

l

The cube re-



Logical

functional

applicationPhysical

functional

application

Physical

Application

Logical

Application

Logical

functional

technical

Logical

Technical


49




Functional

Operational

Lo

gic

al

Ph

ys

ica

l

The cube re-



Logical

functional

applicationPhysical

functional

application

Physical

Application

Logical

Application

Logical

functional

technical

Physical

Technical

Logical

Technical

Physical

functional

technical


50




Functional

Operational

Lo

gic

al

Ph

ys

ica

l

The cube re-


the functional “face”Logical

functional

technical

Logical

functional

applicationPhysical

functional

application

Physical

functional

technical

Operational

in

TOGAF = ?

Physical

Application

Physical

Technical

Logical

Application

Logical

Technical


51

Application and Data Architecture in TOGAF and IBM’s EA Method (1 of 3)

Both frameworks

adopt the same

layering…


52


Both frameworks

adopt the same

layering…

Ap

plic

atio

n A

rch

itectu

re

Info

rma

tion

Arc

hite

ctu

re

…but IBM’s EA method

amplifies the need to

model “what’s done” and

“what it’s done to” across

all layers





all layers


53


Op

era

tion

al A

rch

itectu

re

Ap

plic

atio

n A

rch

itectu

re

Info

rma

tion

Arc

hite

ctu

re

Both frameworks

adopt the same

layering…





all layers

…And as before,

TOGAF has no

explicit coverage of

“where things are

done”





all layers


54

On a wider scope, TOGAF’s content framework addresses the

same spaces as IBM’s architecture methods in a simpler manner

IBM’s AT and EA classes

amplify the “top to bottom”

distinction between “the

parts” (EA) and solutions

constructed from those

parts (AT)

IBM’s EA maintains

focus on AA and IA

through all levels, as

well as explicitly

covering the

operational aspect


55

The IBM System Description Standard (SDS) versus

the IEEE 1471-2000 Architectural Description Standard

SDS has a rich meta-model that defines the

“language” for describing a system’s architecture.

DS defines a general set of system concepts,

which are then constrained to specific types of

systems, such as IT.

ADS is a constraint on SDS, specifically

for IT systems.

o The concepts (and engineering perspectives)

in ADS are supported SA4TeamSD

configuration of Rational System Architect.

ADS is used in IBM’s EA and solution architecture

methods.

SDS

ADSXYZ-DS

Angel Hernández Bravo

•Email: [email protected]

•Web: www.ibm.com

•Twitter: @angelhbravo

II JORNADA itSMF en Sevilla

ARQUITECTURA EMPRESARIAL

20

MAR

2014

http://www.ibm.com/

ponecia arquitectura ii jornada itsmf en sevilla

Documents

arquitectura empresarial4ibm

arquitectura empresarial5ibm

arquitectura empresarial3ibm

arquitectura planificada

arquitectura empresarial7que

arquitectura empresarial8que

arquitectura empresarial10que

arquitectura empresarial9que