elaborando un roadmap hacia un soa v4

Elaborando un roadmap hacia un SOA

Consideraciones sobre la implementación de un plan y estrategia de adopción

Contenido

• Evaluación inicial ¿Cuándo vale la pena?• Componentes y recursos necesarios ¿Qué tengo

que tener para partir?• Etapas del proceso ¿Qué pasos debo seguir?• Duración del proceso ¿Cuánto me voy a

demorar?• Durante la implantación ¿Qué problemas puedo

esperar?• Conclusiones ¿Qué beneficios debiera esperar?

Evaluación inicial ¿Cuándo vale la pena?• Requerimientos

de integración• Estrategia de

crecimiento• Diversidad de

ambientes• La práctica

antecede a la herramienta

• ¿Es mi negocio diverso?• Más diverso -> más cosas que integrar• Gerencias comerciales y operaciones

dispersas• Más sistemas de negocio• Más entidades, conceptos

• ¿Interactúo con clientes/proveedores en forma electrónica?• Más en línea -> más compleja la

integración

La integración de sistemas crea la necesidad de arquitecturas orientadas a servicios






• Negocios iniciándose• Pueden tener todos los beneficios y

ahorrarse el sufrimiento• Negocios en procesos de fusión

• Requerimientos de integración son muy grandes

• Podemos tener 2 caras y simplificar el problema

• Negocios estables• Podemos usar un esquema muy gradual

El crecimiento rápido hace más compleja la adopción, pero más grandes los beneficios






• Convivencia de sistemas nuevos y antiguos• Diversidad de bases de dato• Diversidad de significado

• Integrar sistemas que tienen el mismo nombre para conceptos distintos

• Conciliación semántica

La diversidad de ambientes fuerza integraciones más complejas y se beneficia de SOA






• Una arquitectura no es una herramienta sino una forma de organizar las herramientas

• ¿Tenemos un proceso formal de desarrollo?• ¿Tenemos el hábito de usar componentes

reusables?• ¿Tenemos experiencia interna en el desarrollo

de objetos, modelamiento de objetos?

Las herramientas no fuerzan el comportamiento, las personas lo hacen

Componentes y recursos necesarios• Competencias

en el personal• Plataforma de

integración• Modelos

corporativos de dato

• Soporte de proveedor

• SOA requiere un paradigma de modelamiento de la integración• Aislamiento de niveles• Modelos corporativos• Diseño de componentes

• Capacitación y centro de competencia• Separación de roles• Socios estratégicos

Sin personal entrenado en las metodologías y herramientas no podemos hacerlo






• Seleccionar una herramienta• Evitar la diversidad• Definir los niveles de solución de acuerdo a la

herramienta• Modelo de “iceberg” ¿qué dejaremos a la

superficie?

Cuando lo que tenemos es un martillo, todos los problemas parecen clavos

Arquitectura: crecimiento no integrado

Logistics

B2B portal

Retail Systems

Reception

Storage

Dispatch

DC

Mgmt Support

Back Office

Customer Admin

Travel Agency

Risk Mgmt Insurance

CRM

Collection

Modem

Insurance Companies

Policy Info

External Collection Companies

Internet

Finance

Financial Accounting

Foreign Trade

Mgmt Support

HR

HR Management

Mgmt Support

Credit Card

Batch processes

(Online, batch, EPU, etc …)

MIRROR MIRROR MIRROR

CAC

Online RMS files

Batch RMS files

MIRROR

MIR

RO

RF

TP

Centauro

IBM/AIX

PDSAIMArthur

OSIRIS

IBM/AIX

POLP4CRRHH

EXRTL2Big Ticket

S_HORUS

Windows NT

BD_PROInsurance

BD_POLInsurance

BD_ENDInsurance

Mercurio

Sun Solaris

IASInfoper

Neptuno

Sun Solaris

SCORRisk Mgmt

Jupiter

Windows NT

APOLCall Center

STAGCall Center

MERCCall Center

2Milba

OpenVMS

EXCRT1Credito

S_AnubisS_Anukis Windows 2000

ORASP2SPOS

Vulcano

IBM/AIX

POLLC1JDA-PMM

Gesti2

Open VMS

EXCOM1CNAC

OFIUNI

Digital Unix

PRODFinancials

BTIC

UnixNCR

EXRTL1Big Ticket

ISServer

SunSolaris

RIPLEY_DBTienda Virtual

OMEGA

Open VMS

EXCRT2Credito

EXCRH1Credito Historico

BASPOSCredito

Sales Info

qweInfo

Payments InvoicesSales Invoices, Debit,

Credit Note (Manual)

Sales Invoices, Debit Credit Note Supplier Info

Payroll Benefits

Policy Info

Exchange Intranet

AdexusHosting

Services

SW L2/3

InternetNational

InternetInternational

asdasd novios.cl bebes.cl B2B

SW L2/3

SW L2/3

FW

SW L2/3

FW

SW L2/3

LB

Tienda

Virtual Brides&Grooms

BabiesB2B

Portal ChannelTransactions

POSPOSPOS

FinancialTerminals

FinancialTerminals

FinancialTerminals

FinancialTerminals

FinancialTerminals

AutoConsulta

FinancialTerminals

FinancialTerminals

xysMatico

FinancialTerminals

FinancialTerminalsRCWEB

Windows NT

Data Collection

Windows NT (Backup)

Data Collection

NQC

Switch Central

Trans Bank ORSAN DICOM

External Authorization

Switch Local

FinancialTerminals

FinancialTerminalsEnrollment

Call Center

IVR Telephony

Phone-Buy

Telemarketing

Collection

SPOS

CTC

JumboSantaIsabel …

GTD

RAS-ASCENDMAX 4000

RADIUS SERVERS_GHEB

FW

SPOSSPOS

Esso

NETSET

CAC

Store warehouse

RF InterfaceStore Inventory data

Esquema genérico de lo que se quiere

Canal 1

Canales

Hub de Integración

Canal 2 Canal 3 Canal 4

Conector

Conector Conector

BD1 Applic1

Conector Conector Conector

Conector

BD2

Conector

Applic2

Canal 1

Canales

Hub de Integración

Canal 2 Canal 3 Canal 4

Conector

Conector Conector

BD1 Applic1

Conector Conector Conector

Conector

BD2

Conector

Applic2

Diferencia entre tipos de servicios y objetos (modelo de “iceberg”)

Objetos técnicos

Objetos visibles

Superficie

Objetos técnicos

Objetos visibles

Objetos “reales”


Aplicación






• Quién tiene el control de la información • Buscar normas internacionales como

“traductor”• Definir las interfaces, entre capas• Definir los protocolos, entre niveles

equivalentes de elementos diversos

Sin un vocabulario común no hay comunicación

Objetos técnicos

Objetos visibles

Superficie

Objetos técnicos

Objetos visibles



Aplicación






• Experiencia real• Experiencia en Chile• Nivel de compromiso• Capacitación y certificaciones• Otros socios para el desarrollo y soporte

SOA es un camino que no debemos recorrer solos

Etapas del proceso ¿Qué pasos debo seguir?• Selección de

herramientas y plataforma

• Estudio de estado actual

• Conocimiento del plan de desarrollos

• Definir la secuencia de introducción

• “pilotos”

• ¿Estamos preparados con el personal que tenemos?

• ¿Cuánto nos costarán las herramientas para el total del proyecto?

• ¿Hay más experiencias cercanas?• ¿Soy un pionero?

Herramientas y competencias es largo y debe ser nuestra primera ocupación






• “pilotos”

• Estado de sistemas actuales• Funcionalidad• Robustez• Plataforma tecnológica

• ¿Cuántos sistemas hay en realidad?• ¿Qué plataformas tenemos?

Conocer sistemas legacy






• “pilotos”

• Sistemas centrales de negocios• Canales de contacto con clientes y

proveedores• Enfocarse en sistemas nuevos

Alineamiento con los planes de negocio: Ahora viene el plan real






• “pilotos”

• Suficientes recursos• Plazos razonables• Coordinación entre las unidades de desarrollo• Procesos formales• Perseverancia

El viejo truco






• “pilotos”

• Proyectos piloto deben ser parte del proceso de aprendizaje

• “Evaluación” de la tecnología• Buscar ejemplos valiosos

SOA debe servir al negocio, no a la entretención técnica

Duración del proceso• Evaluación

inicial• Formación de

competencias• “piloto”• Desarrollo de

Proyecto

• Una evaluación puede tomar varios meses• Formar personal es un proceso de 6 meses a 1

año• Se puede hacer en paralelo y aprovechar el

proyecto “piloto”• El proceso completo de adoptar SOA puede

tomar un par de años

La integración es una parte de la estructura de la organización no un proyecto

¿Qué problemas puedo esperar?• Personal• Tecnológicos• Modelos• Negocio

• Incapacidad de reciclar personal antiguo• Formar centro de competencia• Depender de empresas especialistas

• Resistencia al trabajo integrado• Formar equipos multidisciplinarios

• Manejo de problemas• Control formal de problemas y resolución

• Poca costumbre de usar interfaces y protocolos formales• Capacitación y comunicación

De acuerdo a Murphy: Todos


• Estabilidad• Apoyo en la configuración

• Rendimiento• Máquina, memoria

• Testing• Definir un solo responsable

• Incidentes y problemas; dispersión de la responsabilidad• Administración de incidentes y problemas;

ITIL

Los menos importantes son los problemas tecnológicos, SOA no es una tecnología


• Exceso de componentes• Solución es convencional

• Falta de componentes• SOA empieza a mostrar su beneficio

• Errores semánticos• ¿Cuál es el origen? Canal, BUS, Sistema de

negocio• Evitar resolver en el BUS

Estos problemas son los más graves


• Cambios constantes de especificaciones• Contacto constante con líderes de los

proyectos• Ambigüedades de las especificaciones• Comunicación y capacitación

Cualquier arquitectura debe llevar un ritmo acorde al del negocio

Conclusiones ¿Qué beneficios debiera esperar?• Personal• Tecnológicos• Modelos• Negocio

• Aprovechar los conocimientos en áreas específicas del negocio

• Administrar en forma eficiente la creciente complejidad de la configuración

• Integrar en forma sencilla recursos externos, empresas y operaciones en otros países

Aprovechar competencias en áreas específicas


• Adopción modular de nuevas tecnologías• Aislamiento de tecnología obsoleta• Simplificación de seguimiento de problemas• Reducción de los tiempos y esfuerzos para

nuevos canales

Simplificar el soporte de la diversidad


• Modelos más estables implican menos cambios

• Cambios no se propagan a todos los sistemas• Evolución en diferentes ritmos

Aislamiento y modularidad


• Mejor capacidad de responder• Mayor agilidad• Más fácil integración con clientes y

proveedores

Mejorar time-to-market

elaborando un roadmap hacia un soa v4

Documents