MMCD - A3 - Mod11 - Tecnología Aplicada A La Empresa 2.0 PDF

Módulo
Tecnología Aplicada a
la Empresa 2.0
Módulo
Tecnología Aplicada a
la Empresa 2.0
1. INTRODUCCIÓN A LAS TECNOLOGÍAS DE INTERNET Y SISTEMAS DE
E-BUSINESS .............................................................................................................. 06
1.1. INTERNET Y SU UTILIDAD EN EL ÁMBITO EMPRESARIAL.................................. 07
1.1.1. MODELOS MÁS REPRESENTATIVOS DE E-BUSINESS.................................. 08
1.1.1.1. EL MERCADO ELECTRÓNICO : ACTORES Y CATEGORÍAS ..................... 08
1.1.1.2. TIPOS DE MODELOS DE NEGOCIO ELECTRÓNICO................................. 14
1.2. SISTEMAS DE COMERCIO ELECTRÓNICO Y LA ARQUITECTURA EMPRESARIAL.24
1.3. CONCLUSIONES.............................................................................................. 26
2. ARQUITECTURA EMPRESARIAL........................................................................... 28
2.1. DOMINIOS ARQUITECTURA EMPRESARIAL...................................................... 29
2.1.1. ARQUITECTURA DE NEGOCIO................................................................. 30
2.1.1.1. VISTA DE ESTRATEGIA DE NEGOCIO..................................................... 31
2.1.1.2. VISTA DE CAPACIDADES DE NEGOCIO................................................. 31
2.1.1.3. VISTA DEL FLUJO DE VALOR.................................................................. 31
2.1.1.4. VISTA DEL CONOCIMIENTO DE NEGOCIO............................................. 31
2.1.1.5. VISTA DE ORGANIZACIÓN.................................................................... 31
2.1.2. ARQUITECTURA DE DATOS O INFORMACIÓN.......................................... 32
2.1.3. ARQUITECTURA DE APLICACIONES O INTEGRACIÓN............................... 33
2.1.4. ARQUITECTURA TÉCNICA O DE INFRAESTRUCTURAS.............................. 34
2.2. CONCLUSIONES.............................................................................................. 36
3. ARQUITECTURA TÉCNICA O DE INFRAESTRUCTURAS (SISTEMAS DE
NEGOCIO ELECTRÓNICO)......................................................................................... 37
3.1. PROPIEDADES DE LOS SISTEMAS..................................................................... 37
3.1.1. FIABILIDAD.............................................................................................. 38
3.1.2. DISPONIBILIDAD....................................................................................... 39
3.1.2.1. DETECCIÓN TEMPRANA DEL FALLO...................................................... 41
3.1.2.2. INICIO DEL PROCEDIMIENTO DE RECUPERACIÓN.................................. 41
3.1.3. ESCALABILIDAD....................................................................................... 41
3.1.3.1. ESCALADO VERTICAL........................................................................... 42
3.1.3.2. ESCALADO HORIZONTAL...................................................................... 42
3.1.4. SEGURIDAD............................................................................................. 42
3.1.5. EFICIENCIA / RENDIMIENTO..................................................................... 46
3.1.6. CAPACIDAD............................................................................................ 47
3.2. MODELOS DE COMPUTACIÓN........................................................................ 47
3.2.1. COMPUTACIÓN CENTRALIZADA.............................................................. 48
3.2.2. COMPUTACIÓN DISTRIBUIDA.................................................................. 49
3.2.3. VENTAJAS E INCONVENIENTES CENTRALIZADA VS DISTRIBUIDA.............. 49
3.3. ARQUITECTURA INTERNET.............................................................................. 50
3.3.1. ARQUITECTURA CLIENTE SERVIDOR (C/S)................................................ 51
3.3.2. ARQUITECTURA DE 2 NIVELES ................................................................ 53
3.3.3. ARQUITECTURA DE 3 O N NIVELES.......................................................... 54
3.3.4. ARQUITECTURA DE REDES ENTRE PARES (P2P)......................................... 57
3.3.4.1. P2P NO ESTRUCTURADAS (P2P PURAS)................................................. 58
3.3.4.2. P2P ESTRUCTURADAS........................................................................... 58
3.3.4.3. P2P HÍBRIDAS....................................................................................... 58
3.4. MODELOS DE EXPLOTACIÓN........................................................................... 60
3.4.1. GESTIÓN INTERNA DE SERVICIOS............................................................. 61
3.4.1.1. POTENCIA ELÉCTRICA Y REFRIGERACIÓN ............................................ 61
3.4.1.2. COSTES DE ELECTRICIDAD ................................................................... 61
3.4.1.3. TIC VERDE (GREEN IT)........................................................................... 62
3.4.2. EXTERNALIZACIÓN DE SERVICIOS TIC...................................................... 62
3.4.2.1. REGULACIÓN........................................................................................ 62
3.4.2.2. CONTROL DE COSTES Y OPTIMIZACIÓN............................................... 63
3.4.2.3. GESTIÓN DE RIESGOS........................................................................... 64
3.4.2.4. FIABILIDAD Y TIEMPO DE DISPONIBILIDAD............................................ 64
3.5. CONCLUSIONES.............................................................................................. 65
4. ARQUITECTURA DE LA INFORMACIÓN............................................................... 66
4.1. EL IMPACTO EN EL NEGOCIO DE LA ARQUITECTURA DE INFORMACIÓN
EMPRESARIAL........................................................................................................ 66
4.2. UN POSIBLE MARCO DE REFERENCIA DE LA ARQUITECTURA DE INFORMACIÓN
EMPRESARIAL........................................................................................................ 68
4.2.1. DOMINIOS DE DATOS.............................................................................. 69
4.2.2. MODELO DE CAPACIDAD DE LA ARQUITECTURA DE LA INFORMACIÓN.. 70
4.2.2.1. ENTREGA E INTERCAMBIO DE INFORMACIÓN EMPRESARIAL................ 70
4.2.2.2. INTELIGENCIA DEL NEGOCIO Y ALMACENES DE DATOS....................... 70
4.2.2.3. INTEGRACIÓN DE DATOS...................................................................... 71
4.2.2.4. GESTIÓN DE DATOS MAESTROS........................................................... 71
4.2.2.5. MODELO DE DATOS EMPRESARIAL....................................................... 72
4.2.2.6. GESTIÓN DE CONTENIDOS.................................................................... 72
4.2.2.7. GOBIERNO, CALIDAD Y GESTIÓN DEL CICLO DE VIDA DE LOS DATOS.. 72
4.2.2.8. GESTIÓN DE SEGURIDAD DE LOS DATOS.............................................. 73
4.2.2.9. GESTIÓN DE TECNOLOGÍA DE LOS DATOS............................................ 73
4.3. DISTINCIÓN ENTRE EIA Y IA............................................................................. 78
4.4. DEFINIENDO LA ARQUITECTURA DE LA INFORMACIÓN EN EL ENTORNO WEB.79
4.5. QUÉ NO ES LA ARQUITECTURA DE LA INFORMACIÓN.................................... 80
4.6. FUNCIONES E IMPORTANCIA DE LA ARQUITECTURA DE LA INFORMACIÓN.... 81
4.7. PRÁCTICA DE LA ARQUITECTURA DE LA INFORMACIÓN EN EL MUNDO REAL... 83
4.7.1. CONTEXTO.............................................................................................. 84
4.7.2. CONTENIDO............................................................................................ 85
4.7.2.1. PROPIEDAD........................................................................................... 85
4.7.2.2. FORMATO............................................................................................. 86
4.7.2.3. ESTRUCTURA........................................................................................ 86
4.7.2.4. METADATOS......................................................................................... 86
4.7.2.5. VOLUMEN............................................................................................ 86
4.7.2.6. DINAMISMO......................................................................................... 86
4.7.3. USUARIOS............................................................................................... 87
4.8. GESTIÓN DE DATOS........................................................................................ 87
4.8.1. GOBIERNO DE DATOS.............................................................................. 90
4.8.1.1. PLANIFICACIÓN DE LA GESTIÓN DE DATOS.......................................... 90
4.8.1.2. CONTROL Y SUPERVISIÓN DE LA GESTIÓN DE DATOS........................... 91
4.8.2. GESTIÓN DEL DISEÑO, ANÁLISIS Y ARQUITECTURA DE DATOS................ 91
4.8.2.1. ARQUITECTURA DE DATOS EMPRESARIALES......................................... 91
4.8.2.2. MODELADO Y ESPECIFICACIÓN DE DATOS........................................... 92
4.8.2.3. GESTIÓN DE LA CALIDAD DEL MODELO DE DATOS.............................. 92
4.8.3. GESTIÓN DE BASES DE DATOS................................................................. 92
4.8.3.1. DESARROLLO DE BASES DE DATOS....................................................... 92
4.8.3.2. SOPORTE A LA PRODUCCIÓN DE LA BASE DE DATOS........................... 93
4.8.3.3. GESTIÓN DE LA TECNOLOGÍA DE LOS DATOS....................................... 93
4.8.4. GESTIÓN DE LA SEGURIDAD DE LOS DATOS............................................ 93
4.8.5. GESTIÓN DE LA CALIDAD DE LOS DATOS................................................ 94
4.8.6. GESTIÓN DE DATOS MAESTROS Y DE REFERENCIA.................................. 95
4.8.7. GESTIÓN DE INTELIGENCIA DE NEGOCIO Y ALMACENES DE DATOS........ 95
4.8.8. GESTIÓN DOCUMENTAL, DE CONTENIDOS Y DE REGISTROS................... 96
4.8.9. GESTIÓN DE METADATOS........................................................................ 96
4.9. CONCLUSIONES.............................................................................................. 97
5. DESARROLLO DE SISTEMAS DE E-BUSINESS...................................................... 98
5.1. ALTERNATIVAS: CONSTRUIR, COMPRAR, SW LIBRE......................................... 98
5.1.1. CRITERIOS DE DECISIÓN.......................................................................... 99
5.1.1.1. PRINCIPAL VS CONTEXTO................................................................... 100
5.1.1.2. COBERTURA....................................................................................... 101
5.1.1.3. DIRECCIÓN......................................................................................... 101
5.1.1.4. COSTE TOTAL DE LA PROPIEDAD (TCO).............................................. 102
5.1.1.5. ESCALA.............................................................................................. 103
5.1.1.6. TIEMPOS............................................................................................. 103
5.1.1.7. ESTÁNDARES...................................................................................... 103
5.1.2. DIFERENCIAS ENTRE ALTERNATIVAS....................................................... 104
5.1.2.1. CICLO DE VIDA ECONÓMICO............................................................. 105
5.1.2.2. VOLATILIDAD...................................................................................... 105
5.1.2.3. PROCESOS DE NEGOCIO.................................................................... 106
5.1.3. PROCESO DE DECISIÓN......................................................................... 106
5.1.3.1. EVALUAR LA TENDENCIA O SESGO DE LA ORGANIZACIÓN................ 107
5.1.3.2. DETERMINAR LO BÁSICO Y LO CONTEXTUAL..................................... 107
5.1.3.3. DOCUMENTAR LOS REQUISITOS BASADOS EN ESCENARIOS............... 107
5.1.3.4. REVISAR LAS SOLUCIONES COMERCIALES CANDIDATAS.................... 108
5.1.3.5. DESARROLLAR ESTIMACIONES TCO PARA LAS MEJORES ALTERNATIVAS... 108
5.1.3.6. PREPARAR MATRIZ DE RIESGO / MITIGACIÓN..................................... 109
5.1.4. SOFTWARE LIBRE: LA TERCERA VÍA....................................................... 110
5.1.4.1. OSS VS PROPIETARIO (SOLUCIONES COMERCIALES)........................... 112
5.1.4.2. LICENCIAMIENTO............................................................................... 115
5.1.4.3. MODELOS DE NEGOCIO..................................................................... 118
5.1.4.4. REPASO A APLICACIONES OSS REPRESENTATIVAS............................... 129
5.2. INGENIERÍA DEL SOFTWARE: METODOLOGÍAS, FASES, ESTÁNDARES Y
MEJORES PRÁCTICAS........................................................................................... 131
5.2.1. NACIMIENTO DE LOS MODELOS DE DESARROLLO DE SOFTWARE......... 133
5.2.2. COMPARATIVA DE CINCO MODELOS PRINCIPALES DE DESARROLLO DE
SOFTWARE...................................................................................................... 136
5.2.2.1. MODELO EN CASCADA...................................................................... 137
5.2.2.2. MODELO ITERATIVO........................................................................... 141
5.2.2.3. MODELO O MÉTODO EN V................................................................. 141
5.2.2.4. MODELO EN ESPIRAL.......................................................................... 143
5.2.2.5. MODELO DE PROGRAMACIÓN EXTREMA........................................... 145
5.3. CONCLUSIONES............................................................................................ 148
6. TECNOLOGÍAS Y CONCEPTOS WEB.................................................................. 149
6.1. ESTÁNDARES WEB........................................................................................ 149
6.1.1. EL PROCESO DE ESTANDARIZACIÓN...................................................... 150
6.1.2. LAS VENTAJAS DE LOS ESTÁNDARES..................................................... 152
6.1.3. ESTÁNDARES ACTUALES........................................................................ 153
6.2. SOA: CONCEPTOS CLAVE............................................................................. 154
6.2.1. SERVICIOS WEB..................................................................................... 156
6.3. WEB 2.0 Y MASH-UPS................................................................................... 158
6.3.1. DEFINICIÓN DE WEB 2.0........................................................................ 159
6.3.2. MASH-UPS............................................................................................. 162
6.4. REST Y AJAX: LA VENTAJA DE LA FLEXIBILIDAD............................................. 163
6.5. LA WEB COMO LA NUEVA PLATAFORMA Y NUEVOS MODELOS DE NEGOCIO .165
6.6. CONCLUSIONES............................................................................................ 167
Centro Europeo de Postgrado Módulo. Tecnología Aplicada a la Empresa 2.0
1. Introducción a las tecnologías de

Internet y sistemas de e-business
“Un modelo de negocio se refiere al plan implementado por una em-
presa para generar unos ingresos y generar unas ganancias prove-
nientes de las operaciones. El modelo incluye los componentes y fun-
ciones del negocio así como los ingresos que genera y los gastos en los
que incurre.”
Hoy en día lo que llamamos Internet (“la red”) permite a las personas, empresas, organiza-
ciones y gobiernos una increíble facilidad y flexibilidad para realizar actividades de toda
índole e interactuar entre sí por medios y localizaciones diversas.
No existe una única causa que sea capaz de explicar por sí misma el fenómeno de Inter-
net en nuestra sociedad actual. Si nos fundamentamos únicamente en el avance de las
Tecnologías de la Información y Comunicaciones (en adelante, TIC), podemos citar la
reducción del coste de acceso a las mismas y la consiguiente popularización a todos los
sectores de la sociedad como unas de las razones principales del auge del fenómeno.
Entre los principales avances tecnológicos que han catapultado el cambio podemos citar
las siguientes:
• El exponencial avance de las tecnologías que soportan la infraestructura del nú-

cleo de “la red” (enlaces, puntos de interconexión, protocolos,…) así como su exten-
sión geográfica a todos los países.
• Las mejoras en capacidad, fiabilidad y velocidad de las llamadas “tecnologías de

acceso a la red” tanto fijas-terrestres (xDSL, fibra óptica,…) como móviles-sin ca-
bles (3G, 4G, HSPA+, LTE, WIFI, WIMAX…) y el aumento de cobertura geográfica-
poblacional.
• Las mejoras en capacidad (memoria, proceso,…), portabilidad, usabilidad (pantallas

táctiles, Sistemas Operativos, aplicaciones amigables...) y la autonomía de disposi-
tivos de acceso personal (portátiles, smartphones, tablets, consolas,..).
06
TIPOS DE EMPRESAS POR CAPAS DE ECONOMÍA DE INTERNET
Capa de Economía Capa 1 – Infraestruc- Capa 2 – Infraestruc- Capa 3 – Intermedia- Capa 4 – Comercio de
de Internet tura de Internet: Las tura de Aplicaciones de rios de Internet: Em- Internet: Empresas
empresas que propor- Internet: presas que unen a los que venden directa-
cionan el Hardware, compradores y ven- mente sus productos
Sofrware y equipamien- Empresas que hacen dedores del comercio o servicios a los
to de red para Internet los productos Soft- electrónico; aquellas consumidores finales
y la WWW ware que facilitan las que proporcionan con- o empresas
transacciones Web o que tenido Web; aquellas
propocionan servicios que proporcionan mer-
de consultoría, diseño y cados donde pueden
desarrollo Web ocurrir transacciones
Tipos de Empre- Redes, HW/ Aplicaciones de comercio Creadores de merca- Vendedores mino-
sas SW, Fabricantes de en Internet dos en industrias ver- ristas por Internet,
Aceleradores de enla- ticales, agencias online ocio por Internet,
ces, PCs y servidores, Software de desarrollo de viajes, vendedores Servicios profesio-
ISPs, Proveedores de Web online, agregadores de nales, fabricantes,
servicios backbone, fa- contenido, publicitarias venta online, billetes
bricantes de seguridad, online, vendedores de o entradas online,
Consultores de Internet
de fibra óptica. anuncios por Internet, empresas basadas en
proveedores de conte- suscripciones
Formación online nidos de portales
SW de motores de
búsqueda
BBDD Web
Aplicaciones multimedia
Ejemplos CISCO, Ericsson, Adobe, Microsoft, IBM, Thomas Cook, Travel Amazon.com, DELL,
HUAWEI, AOL, AT & T, Oracle… City, Yahoo!, ZDNet… …
COLT, Telefonica, Voda- eBay
fone, BT, FR Telecom,
Deutsche Telekom,
NTT, ...
1.1. Internet y su utilidad en el ámbito empresarial

Las múltiples utilidades que se han ido encontrando a Internet son en definitiva un reflejo
de la sociedad actual y de sus actividades tanto personales como profesionales.
Si bien la red nació con un propósito militar-estratégico y posteriormente evolucionó

hacia una vertiente de colaboración académico-científica hoy en día contamos con todo
el abanico de interacciones posibles.
Entre ellas encontramos desde la más puramente mercantil (negocio electrónico o “e-
business”), pasando por relaciones con la administración, asociaciones, grupos de interés
y ONGs, sistemas de formación “on-line”, “tele-trabajo”, hasta llegar a las actividades de
ocio y las de comunicación social-personales, elemento éste de muy especial relevancia.
07
El fenómeno de las llamadas “redes sociales” resulta importantísimo y merecería un ca-

pítulo independiente por el impacto que tiene en sí en la misma sociedad, cerrando una
especie de círculo mágico (personas → TICs → personas), donde un propio reflejo de la
sociedad evoluciona hasta ser capaz de hacer cambiar la misma forma de relacionarnos.
Las redes sociales han llegado a generar no sólo nuevas formas de comercio electrónico,
sino nuevas formas de comunicación creando grupos de interés y marcando tendencias
de opinión, hasta el punto de nacer nuevas profesiones como por ejemplo la del “Commu-
nity Manager”, posición que vela por la reputación social de la empresa en Internet.
1.1.1. Modelos más representativos de e-Business

Un modelo de negocio electrónico o e-business no es más que la adopción del modelo de
negocio de la empresa en el entorno de Internet. Aunque existe una gran diversidad de
enfoques y no es nuestro objetivo profundizar demasiado en este tema por simplicidad
nos quedamos con la definición ofrecida por Investopedia.com.
En esta fuente se indica que un “modelo de negocio” se refiere al plan implementado

por una empresa para generar unos ingresos y generar unas ganancias provenientes
de las operaciones. El modelo incluye los componentes y funciones del negocio así
como los ingresos que genera y los gastos en los que incurre.
Los métodos en la que cada empresa genera esos beneficios pueden ser muy diversos.
Unos venden directamente un producto que producen y los clientes lo adquieren, otros
trabajan en la cadena de valor y transforman productos, otros únicamente lo distribuyen,
otros venden servicios profesionales como asesorías, consultorías, análisis, etc.
Internet ha posibilitado que nuevas formas de comercio se abran paso y así por ejemplo
tenemos modelos de e-business que se fundamentan en ofrecer un servicio gratuito a los
potenciales usuarios on-line (información, aplicación, juego, comunicación…) a cambio de
introducir publicidad de terceros.
1.1.1.1. El mercado electrónico : actores y categorías

El comercio electrónico se puede definir sin ser demasiado riguroso como una forma de
transacción en la cual las partes interaccionan por un medio electrónico. Una transacción
en un mercado electrónico representa un número de transacciones entre las partes. Por
ejemplo, podría implicar varios pasos como son el marketing, el proceso de orden, pagos
y soporte a la entrega.
Un mercado electrónico permite la participación de vendedores y compradores para

intercambiar productos y servicios con el soporte de las tecnologías de la Información.
Los mercados electrónicos tienen tres funciones principales:
08
• Unir a compradores con vendedores
• Facilitar las transacciones comerciales
• Proporcionar una infraestructura legal
Las tecnologías de la información impregnan las tres funciones y ayudan a mejorar la

eficiencia del mercado y reducir los costes por transacción.
La interacción entre participantes está soportada por los procesos de comercio electróni-
co que son básicamente búsqueda, valoración, pagos y acuerdos, logística y autenticación.
Internet y la WWW (o simplemente “la Web” permiten a las empresas implementar

de forma eficiente estos procesos del comercio.
Como ejemplo, muchos servicios de búsqueda y agentes comerciales están disponibles

para ayudar a los compradores a encontrar información, productos y mercancías en los
mercados electrónicos.
Servicios del Mercado Electrónico
09
Las empresas, individuos y organizaciones gubernamentales son los principales actores

en un mercado electrónico.
Actores del mercado electrónico
Atendiendo a las posibles relaciones que pueden establecerse entre estos actores el e-bu-
siness observa las siguientes categorías principales del mercado electrónico por división
entre proveedores o productores y clientes o consumidores:
• Business-to-Business (B2B).
• Business-to-Customer (B2C) y Customer-to-Business (C2B).
• Customer-to-Costumer o Citizen-to-Citizen (C2C)
• Government-to-Business (G2B) y Business-to-Government (B2G).
• Government-to-Citizen (G2C) y Citizen-to-Government (C2G)
• Government-to-Government (G2G)
Es notorio que tradicionalmente es siempre mayor la prevalencia de relaciones “top-

down” (p.e. B2C) frente a las “bottom-up” (p.e. C2B), aunque las últimas están despegando
con ciertas iniciativas reseñables.
10
Debemos tener en cuenta que existen otras categorizaciones o tendencias actuales (Bu-
siness-to-Employee , B2E), Online-to-Offline, O2O),..), aunque no es el objetivo de este
manual tratar en profundidad cada una de estas categorías.
Presentamos a continuación una breve descripción de cada una de estas categorías prin-
cipales para permitirnos contextualizar futuras unidades y capítulos.
Business to Business (B2B)
Empresa a Empresa. Esta categoría incluye todas las transacciones realizadas por una
empresa con sus proveedores o cualquier otra empresa (por ejemplo, entre fabricante y
mayorista o mayorista y minorista o cualquier otra combinación).
Las aplicaciones B2B están perfectamente establecidas desde hace años, particularmente
utilizando el intercambio de datos electrónicos o EDI (Electronic-Data-Interchange)
sobre redes privadas o de valor añadido (VANs) aunque actualmente existen métodos
alternativos a través de conexiones seguras por Internet y nuevos estándares que se van
desarrollando (ebXML,..).
Business to Customer y Costumer to Business (B2C/C2B)
Empresa a cliente/consumidor y viceversa. Esta categoría está representada principal-

mente por la venta minorista y cubre una gran parte de los sitios Web comerciales desde
servicios financieros hasta publicaciones online.
Por otro lado el modelo opuesto es el C2B es una tendencia creciente donde individuos,
plataformas o uniones de consumidores que ofrecen productos y servicios o demandan
nuevos a las empresas utilizando la fuerza de la demanda masiva o su capacidad de in-
fluencia. Es por lo tanto un modelo invertido de negocio en el que los consumidores crean
valor y las empresas lo consumen.
Customer to Customer o Citizen to Citizen (C2C)
Consumidor a consumidor o ciudadano a ciudadano. Los mercados C2C están formados

principalmente por subastas en la Web, donde se utiliza un intermediario que cobra una
comisión o tarifa por la transacción entre particulares.
Podemos encontrar por ejemplo la venta de objetos de segunda mano como coches, mue-
bles u otros enseres que normalmente podríamos encontrar en anuncios clasificados de
cualquier periódico tradicional.
11
Government to Business y Business to Government (G2B/B2G)
Gobierno a empresa y viceversa. Esta categoría cubre todas las transacciones entre las
compañías y las organizaciones gubernamentales. Incluye las adquisiciones electrónicas
del gobierno y otras comunicaciones del gobierno hacia las empresas.
Además de las adquisiciones públicas, las organizaciones gubernamentales pueden ofre-

cer también la opción de realizar transacciones electrónicas como el pago de impuestos
de sociedades.
Government to Citizen y Citizen to Government (G2C/C2G)
Gobierno a ciudadanos y viceversa. Esta categoría incluye todas las interacciones electró-
nicas entre los ciudadanos y los gobiernos en áreas tales como los pagos de prestaciones
sociales, pagos o devoluciones de impuestos, etc. En la categoría de C2G
Government to Government (G2G)
Gobierno a gobierno. Se trata de una categoría que engloba las relaciones electrónicas
entre administraciones, organizaciones e instituciones públicas (locales, regionales, na-
cionales e internacionales) al mismo o distintos niveles. El objetivo de esta categoría es
soportar las iniciativas de gobierno electrónico (e-government) por medio de la mejora en
las comunicaciones y el acceso y compartición de datos.
Los mercados electrónicos están emergiendo en diversos campos. Las distintas industrias
tienen mercados con características distintas. Por ejemplo, un mercado B2C de informa-
ción difiere en muchos aspectos del mercado B2B de automoción.
El primero representa empresas que venden activos de información digital como noticias,
artículos, música, libros o videos digitales.
En un mercado B2C de información la infraestructura electrónica no sólo ayuda a juntar a

clientes y vendedores sino que además actúa como un canal de distribución, entregando
los productos a los clientes.
En este caso, la infraestructura como los servidores y redes deben ser capaces de aguan-
tar la entrega de grandes archivos, la transferencia continua de contenidos (Streaming
media) y otros tipos de productos digitales de una manera eficiente. Este mercado B2C
en Internet se puede ver como un sistema abierto donde el número de participantes es
desconocido.
12
En el mercado B2B de automoción, los productos que se comercian tienen un alto grado
de especialización tales como partes y componentes de vehículos. La infraestructura del
mercados solía estar principalmente basada en el intercambio de datos electrónicos sobre
costosas servicios VAN. EDI implica el intercambio de información estándar y estructu-
rada entre organizaciones permitiendo la comunicación directa entre sistemas computa-
cionales.
Hoy en día, el mercado B2B utiliza Internet para muchas de sus actividades. En el corazón
de las aplicaciones B2B está la integración fuerte de las diferentes aplicaciones.
Los servidores, redes y Software deberían proporcionar la infraestructura para integrar

aplicaciones Web con computadores centrales (mainframes) y sistemas antiguos (lega-
cy systems). El B2B es también un mercado cerrado en el sentido de que el número de
participantes implicados en el movimiento comercial está limitado y es conocido a priori.
Cadena de valor y relación entre mercados B2B y C2C
Conocer la naturaleza de los requisitos del mercado es crítico para crear la infraestructura
de e-business subyacente.
La relación entre los modelos B2B y B2C puede observarse claramente en la figura ante-
rior. B2B cubre las transacciones comerciales a lo largo de las distintas interacciones exis-
tentes en la cadena de valor desde los productores de materias primas a los vendedores
minoristas, incluyendo los fabricantes y los distribuidores.
13
Por otro lado, B2C refleja sólo las interacciones entre un cliente y un vendedor minorista.
Básicamente una transacción B2C incluye los siguientes pasos:
• Adquisición de cuenta
• Descubrimiento de producto por medio de búsqueda y navegación
• Negociación de precio
• Pago
• Entrega de producto
En algunos casos puede existir la resolución de disputas y servicios al cliente.
1.1.1.2. Tipos de modelos de negocio electrónico

Los modelos de negocio electrónico que adoptan las empresas están en constante evolu-
ción por los constantes avances que se producen tanto con las tecnologías (sobre todo las
denominadas “disruptivas”) como en la forma de realizar las transacciones que producen
nuevos modelos.
A día de hoy podemos encontrar multitud de tipologías de modelos donde destacamos

los siguientes que se presentan a continuación. Las empresas pueden optar por uno de
estos modelos o cualquier combinación entre varios, que suele ser lo más común.
Modelos tipo Correduría/Agencia (“Brokerage Model”)
Los agentes son creadores de mercado, pues unen a compradores y vendedores y facili-
tan las transacciones. Los agentes juegan un papel muy frecuente en los mercados B2B,
B2C o C2C. Normalmente el agente cobra una tarifa o comisión por cada transacción que
habilita. Las diferentes fórmulas para aplicar estas tarifan pueden cambiar. Este tipo de
modelos incluye:
• Intercambio de mercado (Marketplace Exchange): Ofrece un completo rango

de servicios que cubren el proceso de la transacción, desde la evaluación del mer-
cado hasta la negociación y el cumplimiento del acuerdo. Los intercambios operan
independientemente o son soportados por un consorcio de la industria.
• Cumplimiento de compra/venta (Buy/Sell fulfillment): Toma las órdenes del

cliente de compra/venta de un producto o servicio incluyendo términos como el
precio y la entrega.
• Sistema de recolección de demanda (Demand Collection System): El modelo

patentado “di-tu-precio”. El posible comprador realiza una puja final por un pro-
ducto o servicio específico y el agente concierta el cumplimiento.
14
• Agente de subastas (Auction Broker): dirige las subastas para los vendedores
(individuos o comerciantes). Los agentes cobran al vendedor una tarifa y comisión
proporcional al valor de la transacción. Las subastas varían enormemente en tér-
minos de las reglas de oferta y puja.
• Agente de transacciones (Transaction Broker): proporciona un mecanismo de

pago de terceros para permitir a los compradores y vendedores acordar una tran-
sacción.
• Distribuidor: Es una operación de catálogo que conecta un alto número de fabri-

cantes de productos con compradores mayoristas y minoristas. El agente facilita
las transacciones de negocio entre los distribuidores franquiciados y sus socios
comerciales.
• Agente de búsqueda (Search Agent): es un agente Software o “robot” que se uti-

liza para intentar descubrir el precio y disponibilidad de un producto o servicio
especificado por el comprador potencial o localizar información muy difícil de en-
contrar.
• Mercado o centro comercial virtual (Virtual Marketplace): es un servicio de

hospedaje para los comerciantes “online” que cobrar por el establecimiento, el
mantenimiento mensual en la lista y/o tarifas por transacción. Pueden también
proporcionar transacciones automáticas y servicios de mercadotecnia relacional.
Modelos tipo publicitario
El modelo publicitario de la Web es una extensión del modelo tradicional de los medios
de difusión. El emisor es en este caso un sitio Web, que proporciona contenido (que tradi-
cionalmente puede ser gratuito, aunque no tiene por qué ser así) y servicios (como correo
electrónico, mensajería instantánea, blogs,…) combinados con mensajes en forma de ban-
derola publicitaria (los llamados “banners”). Los banners pueden ser pueden ser la fuente
principal o única de ingresos del emisor. El emisor puede ser el creador del contenido o
un simple distribuidor de un contenido creado en cualquier lugar. El modelo publicitario
funciona mejor cuando el volumen de tráfico de visitantes es muy grande o está altamen-
te especializado. Este tipo de modelos incluye:
• Portal: Normalmente es un motor de búsqueda que puede incluir una variedad de

contenido o servicios. Un alto volumen de tráfico de usuarios hace rentable a la
publicidad y permite una mayor diversificación de los servicios del sitio Web. Un
portal personalizado permite la adaptación del interfaz y el contenido al usuario.
Un portal de nicho cultiva la relación con un tipo de usuario en concreto.
• Clasificados: Se trata de sitios que anuncian productos o servicios a la venta o que

se requieren adquirir. Suele ser habitual cobrar una tarifa por anunciarse aunque
también por estar suscrito.
15
• Registro de usuarios: Sitios Web basados en contenido de libre acceso pero que
requieren registrarse previamente proporcionando algún dato de tipo demográfi-
co. El registro permite realizar un seguimiento de los hábitos de navegación del
usuario a lo largo de las sesiones lo que proporciona un conjunto de datos de un
valor potencial en campañas de publicidad con un público objetivo.
• Pago por posicionamiento en buscadores: Vende una posición favorable de los

enlaces patrocinados o publicidad enfocada a determinados términos de búsqueda
en una consulta de un usuario.
• Publicidad contextualizada / Marketing basado en comportamiento: Desarro-

lladores de software libre que incrustan software de soporte publicitario (adware)
con su producto. Como ejemplos una extensión de nuestro navegador Web que
nos guarde datos de formularios que hemos rellenado, puede a la vez anunciarnos
productos o servicios enfocados a nuestros hábitos de navegación en la red.
• Publicidad orientada al contenido: Aplicada por primera vez por Google, extien-
de la precisión de la publicidad por búsquedas al resto de la Web.
• Intromerciales: Anuncios animados a pantalla completa localizados a la entrada

de un sitio Web antes de que el usuario alcance el contenido buscado.
• Ultramerciales: Anuncios en línea interactivos que requieren que el usuario res-

ponda intermitentemente para permitirle leerse el mensaje antes de alcanzar el
contenido buscado.
Modelos tipo Infomediario (Intermediario de información)
Los datos de los consumidores y sus hábitos de consumo son valiosos, especialmente
cuando esa información es analizada cuidadosamente y se emplea para dirigir campañas
de publicidad.
Los datos de fabricantes y sus productos recogidos de manera independiente son útiles
para los consumidores cuando consideran una compra.
Algunas firmas actúan como infomediarios ayudando a compradores y/o vendedores a

entender un determinado mercado. Este tipo de modelos incluye:
• Redes publicitarias: Alimenta los anuncios banner a una red de sitios asociados
permitiendo así a los anunciantes desplegar grandes campañas de publicidad. Las
redes publicitarias recogen datos sobre los usuarios Web que pueden ser utilizadas
para analizar la efectividad de las acciones publicitarias.
• Servicios de Medición de Audiencia: Agencias de investigación de mercados de

audiencias online.
16
• Publicidad por incentivos: Programas de fidelidad de los consumidores que les

proporcionan incentivos como puntos canjeables o cupones por realizar compras
en sitios adheridos. Los datos recogidos de los usuarios se venden para campañas
de publicidad segmentada o individualizada.
• Metamediario: Facilitan las transacciones entre compradores y vendedores pro-

porcionando información exhaustiva y servicios auxiliares sin estar directamente
implicados en el intercambio de bienes o servicios entre las partes.
Modelos tipo Mercantiles
Mayoristas y minoristas de bienes y servicios. Las ventas pueden realizarse basándose en

listas de precios o a través de subastas. Podemos encontrar los siguientes modelos:
• Comerciante Virtual: aquel comerciante minorista que opera únicamente en la

Web.
• Comerciante de catálogo: negocios de envíos por correo con catálogo Web. Com-
bina pedidos por correo, teléfono y online.
• Click-and-mortar: negocios minoristas tradicionales con tienda física y virtual

en la Web.
• Vendedor digital (Bit Vendor): Un comerciante que trata estrictamente con pro-
ductos y servicios digitales y que en su forma pura gestiona tanto la venta como la
distribución a través de la Web.
Modelos de fabricante / directos
Los modelos de manufactura o “modelos directo” están fundamentados en el poder de la

Web para permitir a un fabricante (una empresa que crea un producto o servicio) llegar a
los compradores directamente y por lo tanto comprimir el canal de distribución.
El modelo de fabricante puede ser fundamentado en la eficiencia, mejora de servicio al

cliente y un mejor entendimiento de las preferencias del consumidor. Se pueden presen-
tar los siguientes modelos:
• Compra: La venta de un producto en el cual el derecho de pertenencia se transfiere

al comprador.
• Arrendamiento: En compensación por una tarifa de alquiler, el comprador recibe

el derecho a usar el producto sujeto a los “términos de uso” del acuerdo. El produc-
to se devuelve al vendedor a la expiración del plazo o falta de pago del contrato de
alquiler. Algunos tipos de acuerdos pueden incluir el derecho de compra al finali-
zar el plazo del alquiler.
17
• Licencia: La venta de un producto que implica sólo la transferencia de los dere-

chos de uso al comprador sujeto al acuerdo de “términos de uso”. Los derechos de
propiedad se mantienen por parte del fabricante (por ejemplo, el licenciamiento
de Software).
• Contenido integrado en la marca: En contraposición al enfoque de contenido pa-

trocinado (modelo publicitario) este modelo se crea por el fabricante mismo con el
único propósito de colocar sus productos.
Modelos tipo afiliado
En contraposición al portal generalista, que busca dirigir un alto volumen de tráfico a un

sitio Web, los modelos tipo afiliado proporcionan oportunidades de compra allí donde los
usuarios se encuentren navegando.
Esto lo realiza ofreciendo incentivos financieros (en forma de un porcentaje de ingresos)

a los sitios Web asociados. Los afiliados proporcionan un atajo a los comerciantes. Es un
modelo de pago por rendimiento. Si un afiliado no genera ventas, no representa un coste
para el comerciante/vendedor.
Este modelo encaja perfectamente de manera innata con la Web, lo que explica su popu-
laridad. En este tipo se encuentran los modelos:
• Intercambio de banners: Se comercializa la localización de los banners dentro de

una red de sitios Web afiliados.
• Pago por clic / pulsación: Se paga a sus afiliados por cada pulsación-click sobre
los anuncios que realicen los usuarios (click-through)
• Programas de compartición de ingresos: Se ofrece una comisión sobre el porcen-

taje de ventas basada en una pulsación-clic de usuario en el cual el usuario termina
comprando un producto.
Modelos tipo comunidad de usuarios
La viabilidad del modelo comunidad está basado en la lealtad del usuario. Los usuarios
realizan una inversión muy elevada tanto en tiempo como en emociones.
Los ingresos se pueden basar en la venta de productos y servicios auxiliares o en contri-

buciones voluntarias; o por otra parte los ingresos pueden estar ligados a la publicidad
contextual y suscripciones de servicios Premium o de alta calidad.
De manera inherente Internet resulta apropiado para modelos de negocio tipo comuni-
dad de usuarios y todavía hoy en día es una de los áreas de desarrollo más fértiles, tal y
como se observa en el crecimiento de las redes sociales. En este tipo de modelos encajan:
18
• Código Abierto (Open Source): Se trata de Software desarrollado en modo colabo-

rativo por una comunidad global de programadores que comparten código abierta-
mente. En lugar de licenciar el código a cambio de una tarifa, el código abierto se
sustenta en los ingresos generados desde servicios relacionados como integración
de sistemas, soporte del producto, tutoriales y documentación de usuario.
• Contenido abierto: Se trata de contenido accesible libremente y desarrollado de

manera colaborativa por una comunidad global de colaboradores que trabajan de
forma voluntaria.
• Servicios de redes sociales: Sitios que proporcionan a los individuos la facilidad

de conectar con otros individuos por medio de un interés común definido (pro-
fesional, hobby, romance,..). Los servicios de redes sociales pueden proporcionar
oportunidades para la publicidad contextual y suscripciones de servicios Premium.
Modelos tipo Suscripción
A los usuarios se les cobra una tarifa periódica (diaria, mensual o anual) por suscribirse a
un servicio. No es inusual que los sitios combinen contenido gratuito con Premium (sólo
para socios). Las tarifas de suscripción se incurren con independencia de las tarifas por
uso. Se suelen combinar los modelos de suscripción con el de publicidad. Podemos en-
contrar los modelos siguientes:
• Servicios de contenido: Proporcionan contenido de texto, audio o video a los

usuarios que se suscriban a cambio de una tarifa para tener acceso al servicio.
• Servicios de contactos persona a persona: Están conducidos por la distribución

de información remitida por usuarios, tal como individuos que buscan antiguos
compañeros de clase.
• Servicios de confianza: Viene en forma de asociaciones de pertenencia que se

rigen por un determinado código de conducta en el cual los miembros abonan una
tarifa de suscripción.
• Proveedores de Servicios de Internet (ISPs): Ofrecen conectividad de red y ser-

vicios asociados a cambio de una suscripción mensual.
Dato importante
Los modelos funcionales pueden ser obtenidos del análisis “top-down” de un nego-
cio electrónico. Se pueden representar por medio de muchas técnicas, tales como
modelos de flujo de procesos, modelos de actividad jerárquica, diagramas de flujo
de datos y modelos de entidad-relación.
19
Modelos tipo Empresa de servicios públicos
Este modelo “a demanda” se basa en la medición del uso o un enfoque de “pay as you
go”. Al contrario que los servicios de suscripción, los servicios a demanda se basan en las
tarifas del uso real.
Tradicionalmente, los servicios se han utilizado para servicios esenciales (electricidad,

agua, servicios de llamadas de larga distancia,..). Los proveedores de servicios de Internet
en ciertas partes del mundo operan como empresas de servicio público, cobrando a los
clientes por los minutos de conexión. Podemos encontrar los siguientes modelos:
• Pago por uso: mide y factura a los usuarios basándose en el uso real / consumos
de un servicio.
• Suscripciones medidas: Permite a los abonados comprar acceso a contenido en

porciones medidas como número de páginas visitadas, Kb descargados, etc.
Modelos de referencia
Los modelos de referencia para los negocios electrónicos crean un marco de desarrollo de
los modelos de negocio electrónico. Sirven como base para definir las actividades concep-
tuales en los negocios electrónicos y para identificar oportunidades de mejora.
Estos modelos consisten en cuatro capas agrupadas en dos bloques principales:
• El bloque superior se centra en la naturaleza del negocio y los procesos que pro-
porcionan los servicios ofrecidos por el sitio de negocio electrónico.
• El bloque inferior se concentra en la manera en la que los clientes interactúan

con el sitio y la demanda que colocan sobre los recursos de la infraestructura del
mismo.
• Cada capa del modelo de referencia está asociada con dos extensas clases de des-
criptores y métricas utilizadas para proporcionar una caracterización cuantitativa
de la capa.
Tanto las métricas externas como los descriptores se ocupan de la naturaleza del negocio
y son visibles por la dirección y los clientes.
20
Modelo de referencia para el negocio electrónico
Estas métricas se emplean para evaluar el rendimiento de los procesos de negocio. Por
ejemplo, uno podría usar una métrica para el e-business que refleje al mismo tiempo el
comportamiento de una tienda online y sus clientes. Una métrica de ese tipo es el rendi-
miento de los ingresos, medido en unidades monetarias por segundo, generado por las
transacciones online completadas.
Otras métricas externas podrían ser la disponibilidad, tiempo medio de descarga, visitas
diarias a las páginas y visitantes únicos diarios.
21
Los descriptores externos proporcionan una visión general cuantitativa del negocio. Por
ejemplo, los descriptores externos incluyen información como el número de clientes re-
gistrados, número de potenciales clientes, máximo número de clientes simultáneos en la
tienda, número de elementos a la venta, coste operacional estimado y servicios disponi-
bles a los clientes.
Los descriptores internos y las métricas caracterizan la infraestructura del sitio Web y la
forma en la que los servicios y recursos son usados por los clientes.
Las métricas internas están orientadas hacia la medida del rendimiento de las aplica-
ciones y la infraestructura de tecnologías de la Información. Como ejemplos de estas
métricas podemos nombrar el número de peticiones HTTP por segundo, transacciones
de Bases de datos por segundo, tiempo de respuesta de servidores, tiempo de respuesta
de transacción o tasa de utilización de procesador, disco y red.
Los descriptores internos también incluyen la información de aplicación y arquitectura

como la estructura de navegación, patrones de navegación de los clientes y las caracterís-
ticas de los componentes que componen el sitio Web.
Modelos funcionales
Cualquiera que pretenda montar un tipo de negocio en la Internet o la Web en concreto

debería poder contestar entre otras a una serie de preguntas básicas como las siguientes:
• ¿Cuál es el propósito o misión del negocio?
• ¿Cuáles son sus objetivos de negocio? ¿Cuáles de ellos son cuantificables?
• ¿Está el mercado electrónico en concreto abierto o restringido a determinados gru-

pos?
• ¿Cuál es el tamaño potencial del mercado? ¿qué políticas siguen los participantes
en él?
• ¿Cuáles son los modelos de ingresos?
• ¿Qué servicios de valor añadido que se ofrecen a los consumidores pueden consi-
derarse como factores críticos de éxito?
Un modelo funcional representa los procesos comerciales que entregan servicios a los
clientes de una empresa de negocio electrónico. Los procesos son conjuntos de activida-
des relacionadas que entregan directamente resultados de negocio.
22
Los modelos funcionales pueden ser obtenidos del análisis “top-down” de un negocio
electrónico. Se pueden representar por medio de muchas técnicas, tales como mode-
los de flujo de procesos, modelos de actividad jerárquica, diagramas de flujo de datos
y modelos de entidad-relación.
Dentro del contexto de un negocio electrónico, las actividades de un proceso se pueden

descomponer más aún en servicios que un cliente puede solicitar desde el sitio Web. Ade-
más, un modelo funcional proporciona el marco para identificar la estructura de navega-
ción de un sitio Web y para analizar los diferentes caminos seleccionados por los clientes.
El diagrama siguiente muestra un ejemplo ilustrativo de un sitio de subastas en la Web y

su modelo funcional asociado.
Ejemplo de modelo funcional de un sitio Web de subastas en Internet
23
1.2. Sistemas de Comercio Electrónico y la Arquitectura Empresarial

Los sistemas de comercio electrónico son el soporte del e-business. En el proceso que
comprende las etapas de concepción, diseño, implementación y operación de los mismos
es imprescindible que no se pierda de vista el objetivo principal que es que dichos siste-
mas se encuentren alineados en todo momento con las expectativas y necesidades del
negocio al que sirven.
A lo largo de los años se han propuesto diversos enfoques, metodologías y marcos de

referencia que han permitido un acercamiento a estas etapas de la manera más racional y
sistemática conocida. Así pues podemos citar la aparición del concepto de Calidad Total
que permitía centrarse en el diseño de procesos aislados, cuyo acercamiento está basado
en continua medición, análisis y corrección gradual hasta conseguir el resultado espera-
do.
Más adelante apareció el Lean Manufacturing, que se centra en dar ciertos privilegios a
los procesos productivos para así eliminar los defectos o desperdicios. Después podemos
encontrar la Reingeniería de Procesos de Negocio, la cual a diferencia de la Calidad To-
tal propugna un diseño integral con cambios sustanciales en los procesos de una empresa
con el ánimo de generar mejoras fundamentales, aunque sin disponer de una metodo-
logía que ayude a cumplir los objetivos. Un paso más adelante se encuentra Six Sigma,
como una mejora de la Calidad Total, perfeccionando los métodos de análisis aunque
manteniendo su enfoque en problemas aislados de una empresa.
Después nos podemos encontrar con BPM (Business Process Management), como re-
fundación de la Reingeniería de Procesos que proporcionaba fundamentos metodológi-
cos y conceptuales que permiten diseñar los procesos de una empresa aunque sin una
relación clara con el diseño de aplicativos IT que apoyen los procesos y estructura orga-
nizativa de la empresa.
A consecuencia de toda esta evolución descrita anteriormente se entrevió la necesidad

de disponer de unas bases conceptuales sólidas para diseñar de manera integral un ne-
gocio. Dentro de este plan están incluidas tanto la definición de la estrategia, modelo
de negocio, arquitectura de procesos, estructura de la organización y la arquitectura de
tecnologías de la información.
La Arquitectura empresarial trata de proporcionar este enfoque sistémico de diseño

de empresas.
La Arquitectura Empresarial suele representarse en forma de modelo gráfico que eng-

loba los componentes y relaciones, a forma de maqueta de la empresa. Los componentes
de la misma son:
24
• Arquitectura de negocio
• Arquitectura de Sistemas de Información, que se subdivide en:
• Arquitectura de Datos / Información
• Arquitectura Aplicativa / Integración
• Arquitectura Tecnológica / Infraestructura
En los siguientes capítulos nos dispondremos a profundizar en los dominios de arquitec-

tura de los Sistemas de Información y sus interrelaciones con el ánimo de comprender
sus fundamentos y cómo responde cada uno a un propósito de evolución sistemática e
integral en pos de lograr la eficiencia y eficacia de las estrategias empresariales.
Dominios de la arquitectura emprearial
25
1.3. Conclusiones
Centrándonos en el exponencial crecimiento del negocio electrónico podemos observar
cómo crecen de igual manera los problemas asociados. Las consecuencias de los repenti-
nos aumentos de demanda de las transacciones de e-business son la ocurrencia de retar-
dos y apagones causados porque los sistemas y las redes se sobrecargan.
Por medio de encuestas de opinión y estudios se confirma que una demora excesiva en las
descargas de un sitio Web es una de las razones más citadas para motivar que un cliente
lo abandone y se dirija al sitio Web de la competencia.
Dado que el negocio de las empresas online depende enteramente del comportamiento
de sus sitios Web los largos tiempos de espera e indisponibilidad pueden resultar de-
sastrosos. Las empresas online deben ofrecer continuamente un servicio electrónico de
buena calidad para evitar perder ventas y clientes.
En cualquier sitio de e-business ya se trate de un servicio de correduría, mercantil o

de subastas es necesario garantizar la calidad del servicio, representada por elemen-
tos clave como son la seguridad, rendimiento y disponibilidad.
Es habitual no obstante encontrarse con noticias de empresas online que han sufrido
problemas tremendos de rendimiento (lentitud de acceso y procesado) y disponibilidad
(servicio caído). Los clientes en la Web están reclamando de manera creciente tiempos de
respuesta más rápidos y mayores disponibilidades de los sitios de e-business.
El hecho de no conseguir proporcionar servicios de calidad resulta en la pérdida de “aten-

ción ocular”. Como ejemplo de esto podemos comentar que los sitios de e-business in-
tentar conseguir la regla de los 8 segundos, que no es más que una creencia bastante
extendida que después esperar ese tiempo frente a un sitio Web el cliente se impacienta
y probablemente abandonará el sitio.
Por ello para la mayoría de negocios electrónicos un rendimiento pobre y una baja dispo-
nibilidad implican casi siempre una pérdida de ingresos, mala prensa, mala percepción
pública y una caída del valor de las acciones de la empresa.
El negocio electrónico aporta un conjunto único de desafíos a la infraestructura tecnoló-

gica. Algunos de los más importantes problemas de la infraestructura de e-business son
una adecuada capacidad, escalabilidad y tolerancia ante fallos del sitio Web. La viabilidad
del negocio electrónico depende de la habilidad de los sistemas subyacentes para ofrecer
servicios fiables y oportunos.
26
A medida que las computadoras/ordenadores se vuelven más omnipresentes los proble-

mas de disponibilidad tienden a agravarse. La pléyade de dispositivos conectados que ya
no se centra únicamente en computadoras sino dispositivos móviles e incluso electrodo-
mésticos añade al menos un orden de magnitud al número y tipo de fuentes de tráfico y
cambia las características e intensidad del tráfico de Internet.
Incluso más, nuevas tecnologías como los “Agentes Software” en la Web pueden ser usa-
dos para automatizar muchas de más tediosas fases del proceso de negociación, tanto
para compras como para ventas de productos. Como consecuencia, la popularidad de los
agentes generará más transacciones comerciales y mayor carga en las redes y sistemas
de e-business.
Entender el impacto de estos cambios en términos de comportamiento del cliente, ca-

racterísticas de la carga de trabajo y rendimiento de los sistemas supone un desafío. Las
técnicas de modelado del rendimiento, disponibilidad y capacidad nos pueden ayudar a
anticiparnos y resolver los problemas.
Tanto los proveedores de servicios de Internet (ISP), proveedores de red y negocios elec-
trónicos necesitarán entender los impactos de las nuevas cargas de trabajo para diseñar y
operar apropiadamente sus sistemas.
Dato importante
Internet y la WWW (o simplemente “la Web” permiten a las empresas implementar

de forma eficiente estos procesos del comercio.
27
2. Arquitectura empresarial
“A pesar de que existen distintas visiones o marcos de referencia
vigentes (véanse Zachman, TOGAF, FEA o Gartner) puede resumir-
se que los dominios principales son la Arquitectura de Negocio y la
Arquitectura de Sistemas de Información, a menudo subdividida en
Arquitectura de Datos o Información, Arquitectura de Aplicaciones o
Integración y Arquitectura técnica o de Infraestructuras.”
Según la definición de Gartner, la Arquitectura Empresarial (Enterprise Architectu-

re, EA) es el proceso de traducción de la visión y estrategia del negocio en cambios
efectivos en la empresa por medio de la creación, comunicación y mejora de los ele-
mentos clave, principios y modelos que describen el futuro estado de la empresa y
permita su evolución. El alcance de la EA incluye la gente, procesos, información y la
tecnología de la empresa, y sus relaciones entre sí y hacia el entorno exterior.
Los arquitectos empresariales construyen soluciones holísticas que dirigen los desafíos
de negocio de la empresa y mantienen la gobernanza necesaria para implementarlos.
Los arquitectos empresariales utilizan el proceso EA para descubrir el estado objetivo en

el que la organización desea invertir y le ayuda a entender su progreso hacia el mismo.
En 1987 el campo de la Arquitectura Empresarial nacía de la mano de la publicación por

parte de John Zachman de un artículo en el IBM Systems Journal titulado “A Framework
for Information Systems Architecture”. Este campo comenzó a atacar a los dos proble-
mas principales presentes:
• Complejidad de los sistemas: Las organizaciones estaban gastando más y más

dinero en construir sistemas de TI.
• Pobre alineamiento con el negocio: Las organizaciones encontraban cada vez

más difícil mantener esos costosos sistemas de TI alineados con las necesidades
del negocio.
28
En definitiva, mayores costes y menor valor añadido. Estos problemas ya reconocidos

entonces han alcanzado un punto crítico. El coste y la complejidad de los sistemas de TI
han crecido de manera exponencial mientras que las probabilidades de extraer verdadero
valor añadido de esos sistemas han disminuido de manera drástica.
En conclusión, hoy en día supone incluso mayores costes y menor valor añadido. Las or-
ganizaciones no se pueden permitir ignorar por más tiempo estos problemas. El campo
del EA resulta una herramienta realmente poderosa.
A lo largo de estos años han aparecido y desaparecido numerosas metodologías que tra-
taban de abordar la EA.
Hoy en día podemos afirmar que la mayor parte de organizaciones emplean alguna de las
siguientes cuatro metodologías:
• Zachman Framework for Enterprise Architectures: Aunque se autodescribe

como un marco de referencia es más una especie de Taxonomía.
• TOGAF: The Open Group Architectural Framework: Puede describirse mejor

como un proceso.
• The Federal Enterprise Architecture (FEA): Puede verso tanto como una arqui-
tectura empresarial implementada o una metodología preceptiva para crear una
EA.
• Gartner Methodology: se puede describir como una práctica de EA.
2.1. Dominios arquitectura empresarial

Tal y como introdujimos en el capítulo anterior, la llamada Enterprise Architecture com-
prende un conjunto de dominios que aglutinan una visión particular de una parte del
sistema completo.
A pesar de que existen distintas visiones o marcos de referencia vigentes (véanse Za-
chman, TOGAF, FEA o Gartner) puede resumirse que los dominios principales son la
Arquitectura de Negocio y la Arquitectura de Sistemas de Información, a menudo
subdividida en Arquitectura de Datos o Información, Arquitectura de Aplicaciones o
Integración y Arquitectura técnica o de Infraestructuras.
29
Pirámide de los dominios de la arquitectura empresarial
2.1.1. Arquitectura de negocio

La arquitectura de negocio define la estructura de la empresa en términos de la estructura
de su gobierno, los procesos y la información de negocio.
Al definir la estructura de la empresa la arquitectura de negocio se considera a los clien-

tes, las finanzas y el siempre volátil mercado para alinear las metas y objetivos estraté-
gicos con las decisiones con respecto a los productos y servicios, socios y proveedores,
organización, capacidades e iniciativas clave.
La arquitectura de negocio se centra principalmente en las motivaciones del negocio, las

operaciones del negocio y los marcos de análisis de negocio y redes relacionadas que
unen estos aspectos de la empresa entre sí.
Con el objetivo de desarrollar una visión integrada de la empresa se desarrollan típica-

mente una variedad de vistas de la organización. Dentro de la arquitectura de negocio,
las vistas clave son:
1. Vista de Estrategia de Negocio Dato importante

2. Vista de Capacidades de Negocio El pilar de la Arquitectura de datos
es la definición o proyecto original
3. Vista del Flujo de Valor
del diseño de datos que será em-
4. Vista del Conocimiento de Negocio pleado para lograr la implementa-
ción de una base de datos física.
5. Vista de Organización
30
Además de las vistas anteriores de la empresa, las relaciones que conectan las mismas
conforman los cimientos de la arquitectura de negocio. Estos cimientos proporcionan el
marco que mantiene el logro de los objetivos clave, planifica y ejecuta distintos escenarios
de negocio y entrega el resultado final del valor del negocio.
2.1.1.1. Vista de estrategia de negocio

Esta vista captura los objetivos estratégicos y tácticos que impulsan a la organización.
Los objetivos se descomponen en varios enfoques tácticos que permiten conseguirlos y
para proporcionar trazabilidad a lo largo de la organización. Estos objetivos estratégicos
y tácticos se mapean a métricas que proporcionan una evaluación continua del logro de
los mismos.
2.1.1.2. Vista de capacidades de negocio

Esta vista describe las principales funciones del negocio de una empresa y las partes de la
organización que tienen que realizar tales funciones. Esta vista distingue entre funciones
de cara al cliente, funciones relacionadas con proveedores, ejecución de negocio y funcio-
nes de gestión del negocio.
2.1.1.3. Vista del flujo de valor

Esta vista define el conjunto de actividades extremo a extremo que proporciona valor tan-
to a los interesados internos como a los externos, trascendiendo los límites de la organi-
zación. Los flujos de valor son el vehículo para observar el negocio “en movimiento” y son
el aspecto clave de la arquitectura de negocio que permite la alineación de los procesos
de negocio con la arquitectura de negocio.
2.1.1.4. Vista del conocimiento de negocio

Esta vista establece las semánticas compartidas dentro de la organización y las relaciones
entre esas semánticas. Estas semánticas conforman el vocabulario en el que la organiza-
ción depende para comunicar y estructurar el entendimiento de las áreas dentro de las
que opera.
2.1.1.5. Vista de organización

Esta vista captura las relaciones entre los roles, capacidades y unidades de negocio, la
descomposición de esas unidades de negocio en subunidades y la gestión interna o ex-
terna de las mismas.
31
2.1.2. Arquitectura de datos o información

La arquitectura de Datos básicamente trata del diseño y construcción de los recursos de
datos. La arquitectura de datos proporciona métodos para diseñar, construir e implemen-
tar un recurso de datos totalmente integrado y enfocado al negocio que incluya objetos
y eventos del mundo real en los entornos operativos más apropiados. La arquitectura de
datos también se encarga de los componentes de los recursos de datos.
El pilar de la Arquitectura de datos es la definición o proyecto original del diseño de datos

que será empleado para lograr la implementación de una base de datos física.
La arquitectura de datos se puede comparar al diseño de una casa donde todas las des-
cripciones de la estructura de una casa que va a ser construida, desde la elección de ma-
teriales, tamaños y estilos de las habitaciones y techos, la distribución de las tuberías e
instalaciones eléctricas están descritas en el proyecto original.
De la misma manera, la arquitectura de datos describe la forma en la que los datos serán
procesados, almacenados y usados por la organización que la use. Establece los criterios
para procesar las operaciones incluyendo el flujo completo del sistema.
La arquitectura de datos recae en el mundo del trabajo de los arquitectos de datos. Estos
profesionales definen el estado objetivo, realizan alineamientos del desarrollo y una vez
que la arquitectura de datos está implementada realizan las mejoras que sean necesarias
para ajustarse a las necesidades y el espíritu original del proyecto original.
Diseñar una arquitectura de datos es un proceso complejo porque implica relacionar mo-
delos de datos abstractos con las actividades y entidades de negocio del mundo real antes
de que se implemente el diseño de la base de datos y finalmente se configure la infraes-
tructura de soporte físico (Hardware) de TI.
Si la arquitectura de datos no se estable o lo suficientemente robusta, un fallo en un punto

puede desencadenar una ola de fallos que terminen causando que el sistema completo se
averíe y resulte finalmente en una pérdida monetaria para la organización.
La arquitectura de datos desglosa las materias hasta su nivel atómico y es entonces cuan-
do las reconstruye en la forma ideada durante la fase de definición del estado deseado.
Durante este desglose existen tres procesos de arquitectura tradicionales que han de con-
siderarse:
• Aspecto Conceptual: Representa todas las entidades de negocio y sus atributos

relacionados.
• Aspecto Lógico: Representa la lógica completa de las relaciones entre entidades.
• Aspecto Físico: Son los mecanismos de datos reales para tipos particulares de
funcionalidades.
32
El marco general de la arquitectura de datos tiene en cuenta tres amplios aspectos del
sistema de información completo, que si son considerados permiten guiar de manera
efectiva la implementación de un almacén de datos de cualquier sistema de información:
• Arquitectura de datos física: Está centrada en elementos de Hardware reales y

tangibles. Dependiendo de lo masivo de los datos que deben ser procesados y el
número de consumidores de los mismos que puedan estar accediendo al almacén
de datos simultáneamente, la inversión en la arquitectura de datos física puede
incluir la adquisición de servidores de alta gama, enrutadores y otros elementos
de red.
• Elementos de la arquitectura de datos: Por ejemplo, la estructura de la sección

administrativa de la compañía y cómo se emplean los datos dentro de la sección
deberían estar descritos en la arquitectura de datos para llegar a ser la base de los
modelos de datos.
• Fuerzas o tensiones del trabajo: Aquellas que pueden tener varias influencias o
representar restricciones que puedan afectar potencialmente al diseño. Se pueden
incluir como tales la economía, políticas de negocio, requisitos de la empresa, con-
troladores de tecnología y las necesidades de proceso de datos.
2.1.3. Arquitectura de aplicaciones o integración

La arquitectura de aplicaciones o de Integración es el diseño organizativo de las aplica-
ciones de una empresa y las relaciones que mantienen entre sí y con los usuarios, con el
objetivo de sostener los datos y procesos/funciones clave de negocio.
La arquitectura de aplicaciones está compuesta por:
• Lista de Procesos de negocio
• Modelo proceso de negocio
• Arquitectura aplicativa
• Diseño del sistema
Un posible método para desarrollar el escenario deseado de la arquitectura de aplicacio-

nes de una empresa puede ser el siguiente:
• Listar las aplicaciones candidatas: Esta tarea comprende identificar todas las po-
sibles aplicaciones necesarias para gestionar los datos y soportar el negocio. En
esta etapa se le suele dar nombres apropiados a las aplicaciones que describan su
propósito y función. También se debe identificar aquellas aplicaciones que pueden
mejorar el negocio o proporcionar una ventaja competitiva así como aquellas que
33
permitan la introducción de una nueva tecnología. Se ha de considerar las aplica-

ciones en tres niveles: estratégico, táctico y operativo; y subdividir la lista acorde
a esta clasificación.
• Definir las aplicaciones: Proporcionar una definición estándar para cada aplica-
ción dentro de la arquitectura. Dividir las aplicaciones en grupos de aplicaciones
relacionadas. Las aplicaciones pueden estar relacionadas porque procesan los mis-
mos tipos de información y/o porque sostienen las mismas funciones de negocio.
Las descripciones deben describir qué es lo que hace una aplicación y no cómo
funciona.
• Relacionar las aplicaciones con funciones de negocio: Identificar las funciones

de negocio que están directamente sostenidos o realizados por cada una de las
aplicaciones en la arquitectura de aplicaciones. Aplicar el principio 80/20, identifi-
cando sólo aquellas funciones de negocio para las cuales la aplicación proporciona
información o para la cual la aplicación automatiza la función.
• Analizar el impacto en los sistemas actuales: Determinar el impacto del con-

junto propuesto de aplicaciones en las aplicaciones actualmente implementadas.
Identificar aplicaciones existentes e indicar si serán remplazadas, actualizadas o
mantenidas.
• Aplicar los principios y estándares de arquitectura más apropiados: Aplicar

los principios de arquitectura y los estándares de aplicación seleccionados para
determinar su afectación en el proceso de transformación desde la arquitectura de
aplicaciones “as-is” hasta el “to-be”. Considerar la estandarización en proveedores
y productos en áreas donde los estándares no son prevalentes. La selección de es-
tándares corporativos para procesamiento de textos u hojas de cálculo por ejemplo
puede sostener tales principios de arquitectura como inter-operatividad o facilidad
de transferencia de datos.
• Formular las decisiones estratégicas de arquitectura de aplicaciones: Formu-

lar las decisiones que comprendan la estrategia de arquitectura de aplicaciones.
Incluir las decisiones sobre cuales de las actuales aplicaciones deben mantenerse,
actualizarse o remplazarse. Desarrollar esquemas descriptivos de la arquitectura.
2.1.4. Arquitectura técnica o de infraestructuras

El dominio de la arquitectura técnica o de infraestructuras es un conjunto de abstraccio-
nes empleado para modelar el conjunto de elementos básicos de computación (hardware/
software) que sostienen las aplicaciones del negocio así como las interacciones entre di-
chos elementos.
34
Por lo tanto, se incluye en este dominio la arquitectura de servidores, redes, telecomunica-

ciones, sistemas operativos, estaciones de trabajo, middleware, infraestructura de BBDD,
seguridad (gestión accesos e identidades), almacenamiento y otros dispositivos hardware.
Por otro lado, el dominio de la arquitectura técnica o de infraestructuras no incluye nada

que tenga que ver con procesos operativos o diseño de Software.
Tampoco incluye otros elementos del negocio sino que es un subconjunto principal de la
arquitectura empresarial y la plataforma para una arquitectura orientada al servicio (Ser-
vice Oriented Arquitecture, SOA), aunque sí que incluye la Infraestructura orientada al
Servicio (Service Oriented Infrastructure, SOI) y la computación en malla (Grid).
En el campo de la arquitectura empresarial tradicionalmente se ha prestado una gran

atención a las arquitecturas de información y de aplicaciones. Sin embargo, recientes de-
sarrollos tecnológicos han promovido un creciente impulso de la arquitectura de infraes-
tructuras.
Históricamente los servicios de infraestructura han sido “simples” durante las primeras
décadas del desarrollo de las TI. Mientas que las aplicaciones avanzaban en funcionalida-
des y complejidad, el Hardware sólo se hacía más rápido.
Sin embargo, el punto de inflexión vino durante el estallido de Internet cuando los provee-
dores de infraestructura innovaron como nunca. Las infraestructuras de TI se volvieron
“inteligentes” a la par que aparecieron una multitud de soluciones de conectividad. Esto
coincidió con el rápido desarrollo y despliegue de nuevos tipos de aplicaciones (como e-
marketing, e-commerce, ERP, data warehousing,…) que demandaban nuevos servicios
de infraestructura.
Así pues, dentro del campo de trabajo de la infraestructura de TI se produjo una revo-
lución silenciosa. Muchos nuevos y complejos tipos de servicios de infraestructura se
añadieron al campo, mientras que los servicios tradicionales ganaron multitud de funcio-
nalidades.
Dominios tradicionalmente separados como telefonía y el video están siendo integra-

dos dentro del dominio de infraestructura mientras que aplicaciones más generales y
estandarizadas como servicios de correo electrónico o aplicaciones de colaboración están
siendo añadidas al dominio de infraestructuras.
Todo esto resulta en complejos entornos de infraestructura que resultan difíciles de ges-
tionar y expandir. De hecho, la mayoría de los actuales entornos de infraestructura son el
resultado de una historia de proyectos de implementación de aplicaciones que trajeron
sus propias piezas de hardware.
35
A través de la fusiones y adquisiciones se complicó aún más la situación, dejando a mu-

chas empresas con distintos conjuntos de servicios similares aunque difícilmente conec-
tables, por no hablar de integrar y consolidar.
Cuando las organizaciones (por necesidad) presten atención a la gestión de la continui-

dad de negocio o deseen ahorrar en costosas plantillas de personal administrativo debe-
rían invertir en la arquitectura de infraestructuras para racionalizar, estandarizar y estruc-
turar sus entornos de infraestructura.
Las organizaciones también se benefician de la arquitectura de infraestructuras cuan-

do desean ser flexibles y ágiles, porque una infraestructura sólida, escalable de manera
natural y modular proporciona unos cimientos sólidos para rápidas adaptaciones en los
niveles más altos.
Los mercados actuales demandan un alto grado de flexibilidad que no puede ser soste-
nido por más tiempo por infraestructuras inconsistentes y difíciles de expandir. Estos
mercados necesitan infraestructuras que están construidas con componentes modulares
estándar.
Sin embargo, no sólo los entornos de infraestructura se benefician de una apropiada ar-
quitectura de infraestructura. Para ser capaces de traducir las arquitecturas de negocio,
información y aplicación en soluciones que funcionen en el mundo real la infraestructura
que sostiene los servicios debería estar alineada.
El resultado haría a la arquitectura más robusta como un todo y le permitiría entregar

soluciones consistentes de principio a fin.
2.2. Conclusiones
En este capítulo hemos realizado una breve introducción al concepto de arquitectura em-
presarial y a los dominios que la componen con el ánimo de situarnos en el contexto
apropiado e introducir los capítulos siguientes.
Es importante la secuencia en la que introducimos los dominios de la arquitectura empre-

sarial, pues esto denota el enfoque que pretendemos en modo arriba-abajo o “top-down”,
es decir, desde la visión de negocio como lo más importante hasta llegar al plano técnico.
Dado que los dominios de Arquitectura de Negocio y la Arquitectura de aplicaciones o

Integración están más ligados a la parte de negocio propiamente dicha nuestro objetivo
se centra en profundizar en los dominios de la Arquitectura Técnica o de Infraestructuras
y el de Información o Datos enfocados a los sistemas de negocio electrónico. Es precisa-
mente aquí donde encontramos el interés para el objetivo de este manual.
36
3. Arquitectura técnica o de
infraestructuras (Sistemas de
negocio electrónico)
“Desde su nacimiento hasta la evolución que ha sufrido Internet hasta
el día de hoy el único principio que parece haberse mantenido invaria-
ble es el cambio constante. ”
Tal y como describimos en el capítulo anterior, este dominio de la arquitectura técnica o

de Infraestructura está relacionado con todos los elementos físicos (Hardware) y lógicos
(Software) que conforman lo que llamamos la infraestructura de los sistemas.
En las siguientes secciones nos centraremos en introducir las propiedades que deben
cumplir los sistemas de negocio electrónico, repasaremos los distintos modelos de com-
putación existentes, centrándonos en los modelos para Internet y revisaremos la arquitec-
tura aplicativa por niveles más extendida.
Por último echaremos un vistazo a distintas modalidades actuales de alojamiento y explo-

tación de los sistemas de negocio electrónico, destacando las ventajas e inconvenientes
que presenta cada una de las opciones enfocado a las necesidades propias del negocio.
3.1. Propiedades de los sistemas

Los sistemas poseen una serie de propiedades para cumplir con las funciones para los
que han sido concebidos. Estas propiedades las podemos situar dentro de los llamados
“Requisitos No funcionales” de un sistema porque no se hacen cargo de ninguna de las
funciones de negocio esperadas del sistema.
Además, no son características directamente visibles por el usuario y resulta bastante

difícil validarlas en un entorno simulado. Algunas de ellas pueden resultar más impor-
tantes para un sistema que otras. Como propiedades principales están las siguientes, que
posteriormente desarrollaremos:
• Fiabilidad
• Disponibilidad
37
• Escalabilidad
• Seguridad (datos y sistemas)
• Eficiencia / Rendimiento
• Capacidad
Aunque algunas fuentes citan otros requisitos no funcionales como Usabilidad, Sosteni-
bilidad, Reusabilidad, Inter-operatividad, flexibilidad, Portabilidad,… nosotros hemos pre-
ferido centrarnos en los principales referidos al sistema de los que luego se derivan otros
como los nombrados que tienen más implicaciones con la experiencia de los usuarios, los
procesos y los ingenieros que operan los sistemas. También sería conveniente nombrar a
los requisitos de Auditoría dentro de los no funcionales.
3.1.1. Fiabilidad
Constituye definitivamente una de las más esperadas ventajas de una solución distribui-
da (lo veremos en la siguiente unidad), basado en la suposición de que un componente
puede ser siempre remplazado por otro sin afectar al nivel del servicio.
Por ejemplo, un requisito habitual de los sitios Web de cierto nivel es que una transacción
de usuario nunca se cancele por el fallo de una máquina en particular que esté ejecutando
esa transacción. Una consecuencia inmediata y obvia es que la fiabilidad depende de la
redundancia de tanto los componentes Software como de los datos.
Si llevamos las cosas al límite, en el caso de que la totalidad del centro de datos fuese des-
truido por un terremoto, debería ser remplazado por otro que tuviera una réplica exacta
de los carros de compra del usuario.
Claramente esto tiene un coste y dependiendo de la aplicación una organización puede

decidir si cumple en mayor o menor medida tal robustez de sus servicios, por medio de la
eliminación de cada punto único de fallo (Single Point of Failure, SPOF).
Las medidas de fiabilidad de sistemas normalmente se emplean para calcular la proba-

bilidad de fallo de un componente único de la solución completa. Una medida empleada
para definir la fiabilidad de tanto un componente como un sistema completo es el tiempo
medio entre fallos (Mean Time Between Failures, MTBF). El MTBF es el intervalo de
tiempo promedio, normalmente expresado en miles o decenas de miles de horas (algunas
veces llamadas horas en activo (power-on hous, POH)), que transcurre antes de que un
componente falla y necesita una revisión.
38
El MTBF se calcula por medio de la siguiente ecuación:
Una medida relacionada es el tiempo medio de reparación (Mean Time To Repair, MTTR).
MTTR es el intervalo de tiempo promedio (normalmente expresado en horas) que toma el
reparar un componente fallido.
La fiabilidad de todos los componentes de la solución, por ejemplo del hardware de un

servidor, sistema operativo, aplicación software y red, puede afectar a la disponibilidad de
la solución del sistema completo.
Un sistema es más fiable si es tolerante a fallos. La tolerancia a fallos es la habilidad de

un sistema para continuar funcionando cuando una parte del sistema falla (compo-
nentes hardware o software).
La tolerancia a fallos se consigue diseñando el sistema con un alto grado de redundan-

cia de componentes hardware. Si un único componente falla, el componente redundante
toma su lugar sin un tiempo apreciable de inactividad.
3.1.2. Disponibilidad
La disponibilidad se puede definir como la capacidad del sistema para limitar en la medi-
da de lo posible la latencia que transcurre desde que se detecta el problema hasta que se
dé por solucionado y el sistema se encuentre de vuelta a la normalidad. Esto asume que el
sistema es fiable, o con otras palabras que es posible detectar los fallos lo antes posible y
que se pueden iniciar las acciones correctivas.
Algunas fuentes consideran que dentro del requisito de la disponibilidad también se

encuentra el parámetro de la localización de la operación como medida de dónde geo-
gráficamente debería estar disponible el sistema/servicio y cuáles son los requisitos de
conexión al mismo, pues pueden determinar la experiencia del usuario (por ejemplo, mala
calidad de los accesos de usuarios en determinados países o regiones).
En el entorno de TI, la métrica empleada para medir la disponibilidad de un sistema es el

porcentaje de tiempo que un sistema es capaz de servir a la función que tiene encomenda-
da. Se emplea la siguiente fórmula para calcular los niveles de disponibilidad:
39
La disponibilidad se suele medir en “nueves”. Por ejemplo, una solución con un nivel de
disponibilidad de “3 nueves” es capaz de sostener su función prevista durante el 99.9 %
del tiempo, o lo que es equivalente a un tiempo de fuera de servicio de 8.76 horas al año
en un servicio 24x7x365 (24 horas al día / 7 días de la semana / 365 días al año).
La siguiente tabla ilustra los niveles de disponibilidad más comunes que la mayoría de
organizaciones tratar de lograr.
Porcentaje de
Día de 24 horas Día de 8 horas
disponibilidad
90% 876 horas (36.5 días) 291.2 horas (12.13 días)
95% 438 horas (18.25 días) 145.6 horas (6.07 días)
99% 87.6 horas (3.65 días) 29.12 horas (1.21 días)
99.9% 8.76 horas 2.91 horas
99.99% 52.56 minutos 17.47 minutos
99.999%
5.256 minutos 1.747 minutos
(“5 nueves”)
99.9999% 31.536 segundos 10.483 segundos
Porcentajes de disponibilidad y tiempo de inactividad (fuera de servicio) anual
Desafortunadamente la medida de disponibilidad no resulta tan simple como seleccionar

uno de los porcentajes mostrados en la tabla anterior.
Lo primero que uno tiene que decidir es qué métrica que quiere emplear para calificar el
tiempo de inactividad.
Por ejemplo, una organización puede considerar como tiempo de inactividad cuando una
base de datos no está montada (un tipo de estado lógico de la Base de datos que permite
al sistema y usuarios autorizados acceder a su contenido (realizar consultas, añadir/mo-
dificar/borrar elementos) si se encuentra montada o simplemente operaciones de mante-
nimiento (ordenación de índices, compactación, desfragmentación, copiado del fichero…)
en estado desmontado.).
Por otro lado, otras organizaciones pueden considerar que sólo se produce la indisponibi-
lidad del sistema cuando la mitad de los usuarios están afectados por un corte de servicio.
40
Además, los requisitos de disponibilidad deben ser determinados en el contexto del ser-
vicio y la organización que emplea el mismo.
Por ejemplo, se les puede establecer menores requisitos de disponibilidad a los servidores
que alojan los datos de carpetas públicas no críticas que a los que alojan bases de datos
de buzones de correo críticos.
Para conseguir una requerida disponibilidad existen dos mecanismos principales: la de-
tección temprana del fallo y la iniciación de un procedimiento de recuperación ágil.
3.1.2.1. Detección temprana del fallo

El primer mecanismo se gestiona por medio de una monitorización periódica del estatus
de cada nodo o servidor (el llamado Heartbeat). Se asigna normalmente al nodo maestro
o principal que realiza las tareas administrativas en arquitecturas cliente-servidor (lo vere-
mos la unidad siguiente). La implementación de este mecanismo de una forma totalmen-
te distribuida resulta más dificultosa debido a la ausencia de un gestor bien identificado.
Las redes entre pares, red de pares o entre iguales (Peer-to-Peer, P2P) estructuradas pro-
mocionan a uno de los nodos como un “super-nodo” con el objetivo de que asuma esta
función de control de vigilancia en segundo plano. Destacar que algunos enfoques de
P2P suponen que un nodo puede informar convenientemente a sus compañeros cuando
necesita abandonar la red, suposición ésta que facilita el diseño.
Esto puede ser posible para algunas clases de fallos pero es irrealista en la mayoría de las
ocasiones como por ejemplo con los errores de Hardware.
3.1.2.2. Inicio del procedimiento de recuperación

Este mecanismo se logra por medio de la replicación (cada dato se almacena en varios
servidores) y la redundancia (por ejemplo, debería haber más de una conexión entre servi-
dores). Proporcionar gestión de fallos en el nivel de infraestructura no es suficiente. Como
se ha podido observar, un servicio que funciona en tal entorno debe también preocuparse
de adoptar técnicas de recuperación para preservar el contenido de su almacenamiento
volátil.
3.1.3. Escalabilidad
El concepto de escalabilidad se refiere a la habilidad de un sistema para evolucionar con-
tinuamente con el objeto de sostener un creciente número de tareas. Por ejemplo, un sis-
tema puede necesitar escalado por un aumento de volumen de datos o de número de
transacciones a procesar.
41
Es una situación habitual que aunque se reivindique un sistema como escalable su ren-
dimiento descienda con el aumento de su tamaño, debido a los costes de gestión o del
entorno.
Por ejemplo, los intercambios de red se pueden ralentizar debido a que las máquinas tien-
den a estar muy separadas unas de otras.
De manera más general, puede darse el caso de que algunas tareas no estén distribuidas
debido a su naturaleza atómica o por algún defecto en el diseño del sistema. A cierto lí-
mite, estar tareas limitan el acelerón obtenido por la distribución de tareas (un fenómeno
conocido como la ley de Amdahl’s en el contexto de la computación paralela).
Una arquitectura escalable evita estas situaciones e intenta equilibrar equitativamente la

carga en todos los nodos participantes.
Es deseable conseguir este escalado sin sufrir una pérdida de rendimiento. Existen dos
estrategias que se pueden implementar para lograr esto: el escalado vertical (Scaling
up) y el escalado horizontal (Scaling out).
3.1.3.1. Escalado vertical

El escalado vertical implica incrementar los recursos del sistema (tales como procesado-
res, memoria, discos y adaptadores de red) al hardware existente con recursos de mayor
capacidad, velocidad o rendimiento.
El escalado vertical resulta apropiado cuando se desea mejorar el tiempo de respuesta del
cliente, como por ejemplo en una configuración de balanceo de carga de red. Por ejemplo
si el actual hardware no proporciona el rendimiento adecuado a los usuarios se puede
considerar el añadir memoria principal (Random Access Memory, RAM) o unidades cen-
trales de proceso (Central Processing Units, CPU) a los servidores para satisfacer así la
demanda.
3.1.3.2. Escalado horizontal

El escalado horizontal implica añadir más número de servidores o nodos de procesamien-
to para satisfacer las demandas. Esta estrategia también resulta apropiada cuando se de-
sea mejorar los tiempos de respuesta de los clientes.
3.1.4. Seguridad
Esta característica supone una de las propiedades clave de todo sistema y un elemento
muy importante hoy en día dado el conjunto de amenazas que se presentan así como los
desafíos que se presentan por la introducción y auge de nuevas tecnologías (por ejemplo,
la computación en la nube (Cloud Computing) como IaaS, PaaS, SaaS, RaaS…).
42
Tradicionalmente se la ha denominado Seguridad Informática o tecnológica, centrada en

la seguridad de los dispositivos y sistemas informáticos (Hardware y Software) así como
los datos, posteriormente seguridad TIC, que englobaba también a la parte de comunica-
ciones aportándole así una concepción más integral y debido a la creciente integración
entre ambos mundos.
Más adelante se empezó a hablar de la Información o Datos como activo principal (aun-
que el término Información resulte más completo), pues es precisamente ése el más pre-
ciado de todo lo que custodian o procesan los sistemas y que engloba no sólo a tecnología
y datos sino a procesos, normativas o principios y personas.
Por lo tanto podemos concluir que la seguridad de los sistemas o informática es sólo una
parte de un término más global e integral que se denomina Seguridad de la Información
que se entiende como un proceso continuo, más que una característica o meta.
Todo esto nos lleva a establecer que los objetivos de la Seguridad de la Información y de la
seguridad de los Sistemas de Información son proteger la Confidencialidad, Integridad y
Disponibilidad de la Información (la tríada CIA, Confidenciality-Integrity-Availability):
• Confidencialidad: Se trata de un principio ético de discreción que en el contex-

to de los negocios resulta básico aplicado a la Información. Se fundamenta en el
principio de acceso a la información únicamente por aquellos a los que por alguna
razón tengan que tener permiso o derecho a la misma, ya sea por ser imperativo
para la realización de sus funciones o como mera información.
• Integridad: Se refiere a la fiabilidad/fidelidad de los datos o Información a lo largo

de todo su ciclo de vida. Puede definirse como la condición que existe cuando los
datos no son modificados desde su origen y no han sido accidentalmente o mali-
ciosamente modificados, alterados o destruidos.
Otras definiciones se refieren a la condición en la cual los datos se mantienen de

manera idéntica durante cualquier operación como pueda ser una transferencia,
almacenamiento o recuperación.
• Disponibilidad: Si se refiere a los sistemas de información, se puede definir como

el grado al cual un sistema, subsistema o equipamiento está operable y en un esta-
do confiable para el comienzo de una misión, cuando la misma puede ser invocada
en un momento indeterminado y desconocido.
En un contexto más técnico puede definirse como el ratio de tiempo total que una
unidad funcional es capaz de ser usado durante un intervalo de tiempo dado.
43
Refiriéndonos a la información o datos se refiere a que los mismos estén accesibles

para el usuario o propietario en todo momento con las mismas condiciones. Mate-
máticamente se puede expresar como:
D=1-{Indisponibilidad}
Tríada CIA Seguridad: Confidencialidad – Integridad - Disponibilidad
A grandes rasgos podemos distinguir dos tipos de seguridad:
• Seguridad lógica: medidas de seguridad y aplicaciones para el control de accesos

a los sistemas de información.
• Seguridad física: Se trata de todos aquellos controles que previenen y protegen a

los sistemas frente a las amenazas físicas del mundo exterior.
44
Por otro lado, las amenazas a las que se enfrentan tanto los sistemas de información como
la información que protegen pueden ser de dos tipos, intencionadas o no intencionadas:
• Intencionadas: como pueden ser robos, sabotajes, intentos de penetración, su-

plantación de identidad, destrucción o falseado de información. Estas amenazas
pueden venir en forma de ataques no personales por medio de virus, troyanos,
ataques de denegación de servicio o intrusiones físicas a las instalaciones (robos,
incendios o inundaciones intencionadas, cortes de suministros,..)
• No intencionadas: En esta categoría se incluirían los fenómenos o cataclismos

naturales (terremotos, tsunamis, huracanes,..) o fortuitos (como puede ser la caída
suministros eléctricos, accidentes nucleares,…)
Para hacer frente a las amenazas debe haber activa una “política de seguridad” que realice
una exhaustiva “gestión del riesgo” como un proceso de mejora continua.
Cabe mencionar que la Seguridad tanto de los sistemas como de la Información se rige
por unos principios establecidos en base a la experiencia y estudios que constituyen las
buenas prácticas (principio del menor privilegio, separación de tareas,…) y la aplicación
de las medidas de mitigación debe venir por una correcta clasificación de la información
sensible y la aplicación una serie de controles de seguridad bajo una estrategia integral
denominada “Defensa en Profundidad”.
Esta estrategia en varios niveles comprende desde los datos en su parte central, las aplica-
ciones que los gestionan, los servidores y sistemas que ejecutan las aplicaciones y alojan
los datos y la redes de comunicaciones por medio de las cuales se intercambia la informa-
ción para pasar a elementos de defensa perimetral y traspasar hacia la seguridad física y
las políticas y procedimiento de seguridad.
Dato importante
Un sistema es más fiable si es tolerante a fallos. La tolerancia a fallos es la habili-

dad de un sistema para continuar funcionando cuando una parte del sistema falla
(componentes hardware o software).
45
Capas de Seguridad del principio de Defensa en Profundidad
3.1.5. Eficiencia / Rendimiento

¿Cómo podríamos estimar la eficiencia de un sistema distribuido? Supongamos una ope-
ración que se ejecuta de manera distribuida y que presenta una serie de elementos como
resultado. Dos medidas típicas referidas a la eficiencia de un sistema son:
• Tiempo de respuesta, TR (o latencia): que denota el retardo para obtener el pri-

mer elemento. Por ejemplo, cuánto tarda en cargar o refrescar la página Web o en
abrirse la aplicación.
• Tasa de transferencia, TTR (o ancho de banda): que denota el número de ele-

mentos entregados en una unidad de tiempo dada (por ejemplo segundos).
• Tiempo de proceso, TP: referido al tiempo que el sistema tarda en realizar una
operación como devolver el valor de una función, cálculos matemáticos, importa-
ciones o exportaciones de datos, etc.
• Tiempo de consulta y reporte: Referido al que se tarda en cargas iniciales y sub-

siguientes.
46
Estas medidas resultan útiles para calificar el comportamiento práctico de un sistema a

un nivel analítico, expresado como una función del tráfico de red.
Desarrollar un modelo de costes que tenga en cuenta de manera precisa todos estos fac-
tores de rendimiento no es tarea fácil y al final se ha de convivir con estimaciones aproxi-
madas aunque bastante sólidas sobre el comportamiento del sistema.
3.1.6. Capacidad
Esta propiedad de los sistemas de información es la medida que determina el volumen
máximo de operaciones o transacciones que el sistema es capaz de procesar potencial-
mente en un tiempo dado.
Por ejemplo, si tras observar un sistema durante un período de tiempo obtenemos una
medida de una TTR de 50 Mb/s de media y el sistema dispone de una capacidad de 100
Mb/s (valor máximo) entonces diríamos que nuestro sistema está a la mitad de su capaci-
dad o con una tasa de utilización del 50%.
Esta propiedad se puede definir para cada componente (servidores, líneas de comunica-
ción,…) o para cada característica en particular del sistema, como por ejemplo en número
máximo de compras online o solicitudes de acceso a páginas Web que el sistema es capaz
de procesar eficazmente por segundo.
Si se refiere a los datos por ejemplo hablamos entonces del máximo número de unidades
de almacenamiento (xBytes: Mb, Gb, Tb…) que el sistema tiene disponible para albergar-
los.
En general dentro del requisito de la capacidad se tienen en cuenta también las necesida-
des de crecimiento anuales (Capacity Planning).
3.2. Modelos de computación

La industria de lo que llamamos Tecnología de Información y Comunicaciones (TIC) tie-
ne una divertida manera de reinventarse a sí misma casi cada década. Nos encontrába-
mos trabajando con virtualización allá por los años de las computadoras centrales (main-
frames) de IBM y hoy parece que hemos hecho el descubrimiento del siglo con la nueva
oleada de virtualización.
Hemos redistribuido el poder de las TI desde estas computadoras centrales a cada escri-
torio de usuario por medio del modelo cliente/servidor y hoy nos encontramos ocupados
re-centralizando todas las TIC por medio del equivalente arquitectónico de las computa-
doras centrales o superordenadores en la “nube”.
47
Después de todo, qué es la nube sino un simple nuevo paradigma para entregar un servi-
cio desde algún distante computador. Las computadoras centrales en la nube de hoy en
día sólo se diferencian en que proporcionan características de escalabilidad, rendimiento
y robustez de distinta manera y a un coste menor por transacción de lo que aquellos de
antaño lograron jamás.
Pero comencemos por el principio revisando qué es la computación centralizada, cuál fue
su nacimiento y usos tradicionales así como su evolución y pervivencia actual. A la par
iremos viendo la evolución hacia sistemas descentralizados en mayor o menor medida
y el nacimiento del concepto de la computación distribuida, en qué principios se funda-
menta, usos y las tendencias actuales.
Por último podremos observar un breve cuadro de ventajas e inconvenientes de cada uno
de los modelos.
3.2.1. Computación centralizada

Son el principio de los tiempos de la computación, basada en grandes computadoras cen-
trales o mainframes (llamados superordenadores si se encontraban en la élite de la capa-
cidad y rendimiento) que ocupaban salas o edificios enteros.
Estos sistemas monolíticos controlan directamente la operación de las unidades indivi-

duales y el flujo de información desde un centro único. Todos los nodos dependen direc-
tamente de la unidad central para enviar y recibir información y para recibir órdenes y no
pueden colaborar entre ellos de manera independiente.
El acceso al control de la unidad central para dar instrucciones o cargar programas (tipo
procesamiento por lotes, batch processing) se realizó inicialmente desde tarjetas perfo-
radas o cintas magnéticas evolucionando a dispositivos de teletipo y posteriormente a
formados por teclado y pantalla que permitían una modo interactivo desde una consola
central o de terminales (o emuladores de terminal actualmente).
El uso que se ha dado a los ordenadores centrales ha sido principalmente por parte de
grandes corporaciones o administraciones públicas para gestionar procesos masivos y
aplicaciones críticas como pueden el procesamiento de datos sobre la población, estadís-
ticas públicas, almacenamiento y procesamiento de datos y cálculos científicos, sistemas
de gestión empresarial y sistemas transaccionales.
El claro dominador del mercado de mainframes ha sido IBM®, aunque ha venido acompa-
ñado de otros fabricantes como son Burroughs & UNIVAC (Unisys), NCR, Control Data,
Honeywell (Bull) (todos los anteriores conocidos como BUNCH), y otros como General
Electric, RCA, Fujitsu, Hitachi, Siemens, OKI, ICL, NEC, Telefunken y Olivetti.
48
3.2.2. Computación distribuida

Este modelo se refiere a la capacidad de realizar una serie de tareas coordinadas, ya sea
procesar datos, intercambiar información o realizar cálculos desde distintos dispositivos
autónomos (nodos) que se encuentran distribuidos en distintas localizaciones utilizando
algún tipo de jerarquía entre los mismos y comunicándose por medio de una red infor-
mática.
El modelo surgió inicialmente propuesto con fines de investigación para la resolución de

problemas de análisis de datos masivos o simulaciones complejas que con la evolución y
abaratamiento de la tecnología de computadoras (en términos miniaturización de com-
ponentes aumento de velocidad de proceso y capacidad) permitieron el nacimiento de las
computadoras personales con sus propias unidades de proceso y almacenamiento con
capacidad para ejecutar programas.
Este cambio de modelo, donde se descargaba de tareas de procesamiento al computador

central, junto con el nacimiento de las redes informáticas, locales primero y luego de ám-
bito ancho (WAN, MAN,..) así como la extensión de la red de redes (Internet) resultaron
clave en el desarrollo exponencial sufrido experimentado por los sistemas distribuidos.
Existen una serie de arquitecturas dentro de los sistemas distribuidos que dan lugar a
una serie de modelos, algunos de ellos híbridos entre la computación centralizada y dis-
tribuida que suponen gran parte de la actual tendencia como ya comentamos en la intro-
ducción de esta unidad y que son adoptados por las organizaciones y empresas según las
necesidades y beneficios que cada cual puede reportar a su negocio o actividad.
3.2.3. Ventajas e inconvenientes centralizada vs distribuida

Pero, ¿por qué necesitamos los sistemas distribuidos? Es necesario señalar que algunas
de las supuestas ventajas supongan en realidad desventajas para según qué tipo de or-
ganización, empresa o actividad en concreto. De hecho, las características que suponen
ventajas de un modelo suponen las desventajas del otro y viceversa.
Ventajas centralizada / Desventajas distribuida
• Poseen componentes no autónomos
• Compatibilidad: normalmente se construyen con tecnología homogénea
• Economía de operaciones
• Economía de escala de Hardware
• Control unificado (manejabilidad, seguridad) y punto único de fallo, no dependen-

cia de una red
49
• Facilidad de comunicación entre ficheros
• Facilidad de actualización y recuperación de datos
• En todo momento múltiples usuarios comparten los recursos de un sistema cen-

tralizado
Ventajas distribuida / Desventajas centralizada
• Poseen componentes autónomos
• Pueden construirse con elementos heterogéneos
• Tolerante a fallos con respecto a las capacidades de comunicación y con respecto

a un sitio principal: mejora en fiabilidad y disponibilidad
• Menor tasa de comunicación de datos y costes asociados
• Flexibilidad de configuración
• Rendimiento de alta velocidad (rápida respuesta y alta tasa de transacciones)
• Actualización modular
• Los componentes de los sistemas distribuidos pueden ser usados en exclusividad
• Los sistemas distribuidos se ejecutan en procesos concurrentes: aumento en velo-

cidad
• Los sistemas distribuidos tienen múltiples posibles puntos de fallo
3.3. Arquitectura Internet

Desde su nacimiento hasta la evolución que ha sufrido Internet hasta el día de hoy el úni-
co principio que parece haberse mantenido invariable es el cambio constante.
No es extraño pues que las arquitecturas que han seguido los sistemas que operan en la
red hayan ido evolucionando también según evolucionaban la tecnología, convenios y
estándares a todos los niveles.
En los primeros sistemas conectados a las redes precursoras de Internet (con ARPANET
como principal) la arquitectura única era la de los grandes computadoras o sistemas cen-
trales de los centros de investigación, académicos y militares que comenzaban a estaban
conectados entre sí.
50
Con la irrupción de las estaciones de trabajo, ordenadores o computadores personales se

abrió la puerta a un modelo distinto (computación distribuida) donde el proceso podía
estar más repartido entre la unidad central de proceso y el computador personal o incluso
residir completamente en él como una unidad de proceso independiente.
Así pues la primera arquitectura de computación distribuida que nació fue aquella en la
que los procesos se dividían en dos grupos (clientes y servidores), dando lugar a la arqui-
tectura Cliente-Servidor (C/S).
3.3.1. Arquitectura cliente servidor (c/s)

La arquitectura cliente-servidor es un modelo de computación distribuida en el cual las
aplicaciones “cliente” solicitan servicios de los procesos del “servidor” por medio de una
comunicación síncrona (protocolo de petición-respuesta). Tanto los clientes como los ser-
vidores normalmente ejecutan en computadoras distintas conectadas a través de una red
informática:
• Una aplicación “cliente” es un proceso o programa que envía mensajes a un “ser-

vidor” a través de la red. Estos mensajes solicitan al servidor que realice una tarea
específica, tal como buscar un registro de un cliente en una base de datos o retor-
nar una parte de un fichero desde el disco duro de un servidor.
• Un proceso o programa “servidor” escucha las solicitudes de clientes que están

siendo transmitidas por la red. Los servidores reciben esas solicitudes y realizan
acciones como consultas a bases de datos y lectura de ficheros.
Protocolo Petición/Respuesta del Modelo C/S a 2 niveles
51
Dentro de esta arquitectura existen distintos grados según sea el peso del proceso y da-
tos que mantiene tanto el cliente como el servidor. Esto nos lleva a clasificar los tipos de
clientes en las siguientes categorías principales, con distintos grados de por medio:
• Cliente ligero (“Thin-Client”): El servidor proporciona la gestión y el procesa-

miento de los datos y el cliente simplemente muestra los resultados gráficamente.
Se percibe una pérdida de rendimiento en el cliente aunque resulta más fácil de
gestionar, más fiable y las máquinas cliente no necesitan ser tan potentes.
• Cliente pesado (“Fat-Client”): En el otro extremo donde todo el procesamiento

aplicativo e incluso algunos datos residen en el cliente. Tienen la ventaja de que
reducen la carga de trabajo del servidor y resultan más escalables, aunque por otro
lado resultan más difíciles de gestionar por el administrador del sistema y menos
seguros en general.
Tipos graduales arquitectura C/S
52
En referencia a la cercanía en la comunicación del cliente con el servidor que finalmente

realiza la tarea encomendada, solemos referirnos a arquitecturas en niveles o siguiendo
una distribución vertical, con cada nivel sirviendo a un propósito distinto del sistema de
manera jerárquica.
Aunque lo más común es que se establezca la separación de máquinas para cada uno de
los niveles puede darse el caso de que varios niveles/funciones se encuentren implemen-
tados y operativos dentro de una misma máquina.
3.3.2. Arquitectura de 2 niveles

Es la arquitectura más básica, normalmente presente en entornos corporativos o redes
de área local. En esta situación el cliente “habla” directamente con el servidor que realiza
la tarea sin mediar ningún elemento entre ambos. Predomina con clientes pesados que
realizan peticiones directas a servidores de bases de datos o de aplicación.
Arquitectura C/S de 2 niveles
53
3.3.3. Arquitectura de 3 o N niveles

Puede haber una infinidad de interacciones asociadas con la ejecución de una función de
e-business. Una interacción C/S comienza cuando un proceso cliente realiza una petición
al proceso servidor, llamado servidor primario y termina cuando el proceso cliente recibe
una respuesta desde el servidor primario.
El servidor primario puede necesitar la ayuda de otros servidores, llamados servidores

secundarios, para ejecutar la petición proveniente del cliente. En este caso, el servidor
primario actúa como un cliente de los servidores secundarios.
Arquitectura C/S de 3 niveles
Esto lleva a distribuir la funcionalidad a través de tres niveles de máquinas/servicios en

vez de dos.
Se puede observar un ejemplo de interacción C/S donde un cliente envía una petición a
un servidor Web el cual remite la petición a un servidor de aplicación que a su vez solicita
datos a un servidor de base de datos. El servidor de aplicación recibe los datos del servi-
dor de base de datos y construye la página HTML que se devuelve al servidor Web que es
el encargado de responder al cliente.
54
Protocolo Petición/Respuesta del Modelo C/S a 3 niveles
Se suele hacer corresponder cada uno de los tres niveles de arquitectura con la siguiente
descripción en capas de la funcionalidad de la aplicación:
• Capa 1 o de “Nivel de Interfaz de Usuario”: normalmente las interfaces gráficas

de usuario (GUI) para interactuar con el usuario final.
• Capa 2 o de “Nivel de procesamiento”: Las aplicaciones de proceso de datos que

suponen la funcionalidad núcleo.
• Capa 3 o de “Nivel de datos”: interactúa con la base de datos o el sistema de fi-

cheros.
Dato importante
La industria de lo que llamamos Tecnología de Información y Comunicaciones

(TIC) tiene una divertida manera de reinventarse a sí misma casi cada década.
Nos encontrábamos trabajando con virtualización allá por los años de las compu-
tadoras centrales (mainframes) de IBM y hoy parece que hemos hecho el descubri-
miento del siglo con la nueva oleada de virtualización.
55
Capas o niveles funcionales aplicativos
Entre los motivos por los cuales puede resultar conveniente separar en más de 2 niveles la
arquitectura entre el cliente y el servidor podemos distinguir los siguientes:
• Almacenar en una memoria intermedia del intermediario los datos de servidor más
frecuentemente accedidos para asegurar un mejor rendimiento y escalabilidad.
• El rendimiento se puede incrementar haciendo que el proceso intermediario dis-

tribuya las peticiones del cliente a distintos servidores para que esas peticiones se
ejecuten en paralelo (balanceo de carga de red).
• El intermediario puede también actuar como un servicio de traducción mediante

la conversión de las peticiones y respuestas desde y hacia un formato mainframe
(Middleware), o como un servicio de seguridad (Proxy, Firewall), que permite el
acceso al servidor sólo a los clientes autorizados o de confianza.
56
3.3.4. Arquitectura de Redes entre Pares (P2P)

En este tipo de arquitectura los nodos (llamados “pares”) siguen una distribución horizon-
tal pudiendo actuar tanto de cliente como de servidor por lo que la interacción es simétri-
ca. Cada par actúa como un servidor para parte de la totalidad de los datos del sistema y
suelen disponer de la misma capacidad de proceso.
Las redes P2P funcionan como redes “superpuestas” (Overlay Networks), esto es, son re-
des lógicas o virtuales que se crean por encima de las redes existentes con el propósito de
implementar un servicio de red que no está disponible en la red actual (un ejemplo claro
de red superpuesta es Internet, formada por redes locales y enlaces nacionales).
Por ejemplo, un enlace entre pares en estas redes puede consistir en varios enlaces físicos
de la red real subyacente y un mensaje en estas redes se envía a direcciones lógicas y no
físicas (refiriéndonos al direccionamiento IP).
En cada nodo debe haber instalado un Software en la Capa de Aplicación (Application

Layer) que se encuentra por encima de la topología de red física existente y que gestiona
la comunicación entre los pares:
• Los pares utilizan su propio sistema de direccionamiento para almacenar y recu-

perar datos del sistema.
• Los pares pueden encaminar las solicitudes hacia localizaciones que puede que no
sean conocidas por el solicitante.
Dentro de esta clasificación de las redes P2P podemos incluso distinguir diversos tipos
de modelos arquitectónicos P2P en el siguiente cuadro. A continuación veremos una des-
cripción de las más importantes.
Modelos
Subtipos P2P Ejemplo
Arquitecturas P2P
Centralizado Napster
Descentralizado
No estructuradas Gnutella
Estructuradas Chord
Jerárquico MBone
Híbrido EDonkey
Categoría de redes P2P
57
3.3.4.1. P2P no estructuradas (P2P puras)

Son aquellas en las que los pares se establecen de manera arbitraria/aleatoria y no existe
ningún servidor ni enrutador central y además todos los pares actúan como iguales.
Cada nodo/par conoce sólo un subconjunto de nodos, sus “vecinos” que se escogen por
diversas razones, ya sea porque están conectados físicamente, porque se unieron a la red
a la vez, etc.
Los objetos de datos se mapean de manera aleatoria a algún nodo/par del sistema. De
igual modo una consulta de un nodo/par se tiene que lanzar (se emplea el término inun-
dación (flooding) a cuantos más pares le sea posible con la posibilidad de que no se
obtenga respuesta.
Ejemplos: EDonkey, Gnutella, Freenet.
3.3.4.2. P2P estructuradas

Los pares se conectan entre sí mediante algún tipo de diseño que simplifica las búsque-
das. Un enfoque típico es el emplear una tabla de distribución Hash (Distribution Hash
Table, DHT) donde a cada nodo/par y a cada objeto de datos se le asigna una clave que
se corresponde con un número aleatorio único y una función de mapeado asigna objetos
a nodos basándose en el valor de la función hash.
A diferencia de las no estructuradas, una búsqueda (también basada en el valor de la

función hash) devuelve en un tiempo razonable la dirección de red del nodo/par que al-
macena el objeto solicitado, si el mismo se encuentra en la red.
Ejemplos: Kad Network.
3.3.4.3. P2P híbridas

Estas redes combinan características de ambas arquitecturas. Por ejemplos existen redes
donde la indexación está centralizada y el intercambio de archivos distribuido (Napster)
o aquellas donde existen nodos/pares dentro de la red con funciones especiales (Super-
peers).
Ejemplos pueden ser los sistemas de servidores frontera (Edge-Server systems) como
los proveedores de servicios de Internet (ISPs) que actúan como servidores para sus
clientes pero cooperan con otros servidores frontera para alojar contenido compartido.
Otros ejemplos pueden ser los sistemas distribuidos colaborativos, como Bittorrent que
soporta paralelamente las descargas y las subidas de pedazos de un fichero, interactuando
primero con un sistema C/S y operando después de manera descentralizada.
58
Modelo de arquitectura de red P2P centralizado
Modelo de arquitectura de red P2P descentralizado
59
3.4. Modelos de explotación

Con los modelos de explotación nos referimos a las posibilidades existentes hoy en día
para disponer de los servicios de una infraestructura de sistemas que sostenga nuestro
negocio electrónico o más concretamente nuestros sistemas de comercio electrónico.
Desde una estrategia totalmente “internalizada”, donde la empresa es dueña y operadora

de toda la infraestructura, hasta el modelo opuesto de una “externalización total” de los
servicios TIC, existen una serie de estados intermedios donde se posicionan la mayoría
de los negocios electrónicos, atendiendo a sus necesidades, evolución, restricciones y po-
siblemente a razones históricas.
En primer lugar vamos a tratar de entender los conceptos relativos a los modelos de ex-
plotación o gestión de los servicios TIC. Así pues, primeramente debemos hacer referen-
cia a los conceptos más amplios como son los de internalización (In-House) y externali-
zación (Outsourcing).
Por gestión interna o servicios internalizados TIC nos referimos a aquellos en los que
es la propia empresa quien gestiona sus servicios de TIC, adquiriendo y operando sus
propias infraestructuras y sistemas. No obstante, hoy en día resulta bastante común en-
contrar que esto no es siempre así para ciertos sistemas o servicios. Por ejemplo, este
modelo híbrido se daría con el manteniendo la administración de los servidores de apli-
caciones por parte del personal interno, pero contratando el soporte de las máquinas y
sus componentes al fabricante a través de un acuerdo de soporte 24x7x365 (24 horas/día,
7 días/semana, 365 días/año) a cambio de una tarifa mensual o pago único por un número
de x años.
Esto nos lleva a la definición de externalización o gestión delegada de servicios TIC,

que conlleva en distinto grados la contratación con un proveedor externo de parte o la
totalidad de los servicios TIC (o un proceso de negocio) a cambio de una cuota bajo un
acuerdo de soporte o de nivel de servicio (Service Level Agreement, SLA) que incluye
entre otros aspectos los tiempos esperados de disponibilidad del servicio, matriz de es-
calado, tiempos de respuesta ante incidencias o problemas, mecanismos de respuesta o
asunciones y penalizaciones.
Las razones por las que se apuesta por uno u otro modelo son de diversa índole y deben
ser considerados atendiendo al contexto de cada negocio y su situación (pequeña, media-
na o gran corporación/multinacional) así como otros factores internos o externos.
60
Ambos modelos sufren de inconvenientes y tienen también sus ventajas. En general la

norma y experiencia indica que todo aquello que nos suponga el núcleo duro del negocio
(Business Core) debería externalizarse para permitir a la empresa emplear sus recursos
y energías en centrarse en buscar la eficiencia y efectividad de las actividades clave o que
más impactan en su cadena de valor (Value Chain) y el retorno de la inversión (Return
of Investment, ROI), aunque como ya comentamos existen otros factores que pueden
inclinar esta política en uno u otro sentido.
3.4.1. Gestión interna de servicios

Para las empresas que decidan continuar operando sus propias instalaciones, el hecho
de que el coste de la energía continúe creciendo en proporción directa al gasto en los
centros de datos es importante por una serie de razones como son la potencia eléctrica
y capacidad de refrigeración, costes de electricidad y las llamadas TICs “verdes”. A
continuación comentamos algunos detalles de las mismas.
3.4.1.1. Potencia eléctrica y refrigeración

Los avances en la tecnología han colocado a las instalaciones que alojan centros de datos
bajo una tensión importante desde la perspectiva de la potencia eléctrica y refrigeración
necesaria.
En la mayoría de las ocasiones la capacidad de potencia representa ahora el mayor inhibi-

dor para el despliegue de nuevas aplicaciones en el centro de datos y por lo tanto tiene un
impacto significativo en la habilidad de una organización para impulsar el crecimiento y
el aumento en productividad.
Desde esta perspectiva otro elemento de preocupación es la continuidad de negocio, dado

que la incapacidad para provisionar suficiente potencia eléctrica y refrigeración resulta
en tiempos de inactividad de los sistemas.
El coste de proporcionar potencia eléctrica a la infraestructura de los centros de datos, en

especial a la infraestructura de servidores juega un papel esencial.
3.4.1.2. Costes de electricidad

Las dudas que se ciernen sobre la seguridad de la energía continúan alzando lo costes
de la electricidad, hasta el punto que la empresas pueden gastar tanto en la alimentación
eléctrica de un servidor durante un ciclo de 3 o 4 años como el coste de adquirir el propio
servidor.
Hasta la fecha, el coste del consumo eléctrico ha sido asumido por los departamentos de
instalaciones como tal no ha impactado en los presupuestos de TIC.
61
Sin embargo esta tendencia está cambiando rápidamente y en un número creciente de

casos este coste se está imputando a la dirección de TIC.
El impacto de este hecho no debería subestimarse dado que el coste de la potencia eléc-
trica puede consumir una parte significativa del presupuesto anual de TIC, si no igualarlo
o superarlo en algunas ocasiones.
3.4.1.3. TIC Verde (Green IT)

La actual tendencia hacia las Tecnologías de Información “verdes” no hace sino ejercer
más presión sobre los directores de TIC desde el punto de vista de la eficiencia de los
centros de datos.
Los máximos mandatarios están conduciendo a sus organizaciones a tomar en conside-

ración el impacto de sus operaciones desde todos los niveles con un énfasis particular en
las TIC.
Con respecto a este punto, la ineficiencia del centro de datos supone una importante falla
por lo que las iniciativas de consolidación y virtualización por motivos económicos se
encuentran en auge.
3.4.2. Externalización de servicios TIC

Entre los factores principales que influyen en la decisión de las empresas de externalizar
servicios TIC se encuentran la regulación, el control de costes y optimización, la ges-
tión de riesgos y la fiabilidad y tiempo de disponibilidad.
A continuación repasamos algunos detalles de cada una de ellas.
3.4.2.1. Regulación
Algunas industrias, sobre todo del sector financiero o de manufactura, se han enfrentado
con una oleada de regulación en los años recientes, motivadas por razones tan diversas
como la corrupción y fraude corporativo, terrorismo, problemas ambientales y protección
del consumidor.
Podemos encontrar por ejemplo Solvencia, Sarbanes-Oxley (SOX), Basilea, IFRS, WEEE,
RoHS,…. Cada nueva directiva trae sus propios desafíos a los departamentos TIC y la in-
fraestructura, normalmente centrada alrededor del almacenamiento, redundancia, cadena
de suministros y en el caso del entorno, la eficiencia TIC.
Por ejemplo, la falta de instalaciones y recursos para gestionar las necesidades de TIC
provenientes de los crecientes requisitos regulatorios es la principal razón de que las cor-
poraciones financieras, de sobra conocidas por su interés en mantener su propia infraes-
tructura de TIC, hayan buscado espacio en centros de datos externos y hayan aumentado
su adquisición de servicios gestionado durante los últimos años.
62
3.4.2.2. Control de costes y optimización

Existen numerosos argumentos y contrargumentos alrededor del coste total de la propie-
dad (Total Cost of Ownership, TCO) de la gestión interna de los servicios TIC frente a
emplear un servicio gestionado o externalizado. Cada organización posee sus propias es-
tructuras de costes operacionales y de capital y su propio umbral de rentabilidad (break-
even point) aunque está bastante extendida la creencia de que la mayoría de las empresas
con despliegues TIC y Web relativamente estándares son capaces de lograr un menor
TCO si emplean un servicio gestionado de alojamiento (Hosting) frente al alojamiento
en instalaciones propias y auto-gestionadas.
Sin embargo, normalmente no es posible realizar una simple comparación de costes entre
un alojamiento interno frente al externalizado debido a un sinfín de costes ocultos que
afectan a las operaciones internas (In-house) y que normalmente no se han tenido en
cuenta. Entre los costes In-house se incluyen los siguientes:
• Instalaciones de centro de datos físico: Costes de alquiler y otras tarifas apli-

cadas por el propietario, mantenimiento del edificio, limpieza, reparación, man-
tenimiento de las salas técnicas, amueblado, enlaces de fibra al edificio, potencia
eléctrica, generadores de respaldo, almacenamiento de combustible, refrigeración,
sistemas de seguridad física (control de acceso, circuito cerrado de TV, detectores
de presencia,…), extinción de incendios, armarios, cableado, etc. Además habría
que añadir una cierta redundancia para todos los elementos anteriores y contratos
de seguros para todos ellos y posiblemente instalaciones para continuidad de ne-
gocio y recuperación ante desastres.
• Servidores: Inversiones de capital o coste de alquiler, depreciación, remplazo

planificado del ciclo de vida, remplazo no planificado, inventario de piezas de re-
cambio o sustitución (disponibles en las instalaciones o por el proveedor), costes
de alimentación y refrigeración, licencias Software, sistemas de monitorización,
sistemas de seguridad (previsión de intrusión, seguridad de emails, sistemas de
mitigación de denegación de servicio (DDoS), etc.
• Plantilla (Recursos humanos): Los salarios y demás costes indirectos de la plan-

tilla de instalaciones y de seguridad para operar el centro de datos así como el de
la plantilla de TI para gestionar el entrono técnico, suplir las ausencias de perso-
nal, costes de desgaste, formación, instalaciones de la plantilla. Este es sólo un
subconjunto de los costes que una empresa incurre en operar sus propias opera-
ciones de alojamiento de sistemas. Mientras que muchas empresas dependiendo
del tamaño de sus operaciones podrían pasar sin alguno de estos elementos, están
normalmente incurriendo en un riesgo a cambio del ahorro de costes (por ejemplo,
ahorrando en redundancia de sistemas o no desplegando la funcionalidad frente
a ataques DDoS o por provisión insuficiente de recursos de personal). Una empre-
sa que utilice un servicio de alojamiento gestionado sigue pagando estos costes
63
pero compartidos con otros clientes del proveedor de servicios y, por medio de las
economías de escala que el proveedor del alojamiento es capaz de lograr, pagar
únicamente una fracción de la cantidad equivalente por las operaciones internas
equivalentes.
3.4.2.3. Gestión de riesgos

Para la mayoría de las organizaciones, el alojamiento externalizado reduce el riesgo. Los
elementos de coste resumidos anteriormente presentan riesgos así como un coste para
una organización en términos de tiempo potencial de indisponibilidad, pedidos perdidos
(no procesados), interrupción del servicio, etc.
La mayor parte de las empresas mantienen acuerdos de nivel de servicio internos o SLAs
pero en el caso de que un evento significativo afecte a las operaciones de alojamiento
estos quedan sin valor efectivo.
Un SLA de un proveedor de servicios externo normalmente no cubre los cotes de negocio

perdido o la insatisfacción del cliente pero puede hacer algo para mitigar el impacto fi-
nanciero. Es más, si es lo suficientemente estricto, actúa como un poderoso incentivo para
que el proveedor de servicios arregle los problemas rápidamente y bien. Un SLA fuerte
no anula el riesgo, pero lo reduce asegurando una rápida resolución y un cierto nivel de
amortiguación financiera.
3.4.2.4. Fiabilidad y tiempo de disponibilidad

Además del coste, el mayor problema que se presenta es la fiabilidad y tiempo de dis-
ponibilidad de la red y de los servicios de alojamiento de sistemas. Sorprendentemente
nos encontramos que las empresas reportan niveles muy bajos de fiabilidad tanto para
los servicios de gestión interna de la casa como para aquellos que son adquiridos a un
proveedor.
La razón se encuentra principalmente en las inversiones que se realizan, tanto si se dedica

un presupuesto exiguo para las operaciones internas como si se adquiere el servicio del
proveedor más barato (con la infraestructura más barata y menores recursos), aunque
esto no es así en todos los casos.
Algunos reputados proveedores de servicios obtienen sorprendentemente unos niveles

de fiabilidad bastante pobres, lo que indica que hay que seleccionar con cuidado el pro-
veedor de servicios externo. El nivel de habilidades del personal disponible resulta crítico
para asegurar la fiabilidad así como las formas en la cual esas habilidades se desplieguen,
desarrollan, motivan y premian. Resulta pues necesario que los clientes de los servicios de
alojamiento tengan especial cuidado con la verificación de la calidad de los proveedores
seleccionados con medidas como el entendimiento del nivel de redundancia desplegado,
hablando con otros clientes, comprobando las estadísticas publicadas o consultando las
encuestas de fiabilidad o de satisfacción de clientes.
64
3.5. Conclusiones
Resulta muy importante destacar que las funciones del e-business se implementan ma-
yoritariamente por medio del modelo cliente – servidor (C/S), aunque el modelo P2P está
emergiendo como una alternativa y va más allá de aplicaciones de intercambio de fiche-
ros (Napster, Kazaa, eDonkey, eMule, Bittorrent…).
Son cada vez más populares otras aplicaciones que empleen este modelo como las de
comunicación personal (Skype, ICQ,…) y de medios de difusión como P2PTV o P2PRadio
(Joost, Zattoo, PPView, SopCast, Spotify (parcialmente)…) aunque se emplee P2P de
manera parcial en un modelo híbrido.
Si bien la mayoría de los proyectos aún no han despuntado claramente en su esfera co-
mercial, salvo excepciones (Skype) y algunas iniciativas enfocadas a los mercados B2B
(MS Sharepoint Workspace , antes Groove Workspaces) se está avanzando mucho en
los sistemas distribuidos como la llamada computación en malla (Grid Computing) para
fines no solo científicos sino empresariales. Es precisamente en el campo B2B y sobre
todo en el C2C donde existen grandes posibilidades de crecimiento según nuestra opi-
nión y un gran reto el desarrollar sistemas que permitan desarrollar este mercado electró-
nico P2P (P2P e-MarketPlace).
Las ventajas del modelo P2P incluyen la descentralización, menores costes, anonimato,
comportamiento ad hoc, escalabilidad, tolerancia a fallos y auto-organización. Por otro
lado se tiene que trabajar intensamente para mitigar las amenazas inherentes a esta filo-
sofía y conseguir que dichos sistemas cuenten con las más elevadas garantías en Seguri-
dad de la Información que ofrezcan protección tanto a las transacciones electrónicas que
se produzcan como a los mismos participantes.
Respecto a los modelos explotación hemos visto que no existe una única recomendación
en este respecto pues la solución debe adaptarse a la estrategia y procesos de negocio
actuales y previstos de la empresa.
Otros factores que pueden determinar si se realiza una gestión interna de los servicios
TIC pueden ser restricciones de tipo laboral, legislativo, histórico o cultural o también por
temas de cumplimiento de estándares del mercado o mejores prácticas (este factor puede
ser una razón tanto para mantenerla como para externalizarla).
En favor de la externalización se encuentran factores como la reducción de costes, el ac-

ceso a mejores conocimientos y experiencia técnica o distintos objetivos estratégicos y
como en otros procesos se pueden distinguir distintos niveles de madurez, según cual sea
el grado de externalización existente en la empresa.
65
4. Arquitectura de la información
“En términos más específicos y como un subdominio de la Arquitectu-
ra de Información Empresarial y de acuerdo al Instituto de Arquitec-
tura de la Información (IA Institute) la disciplina de la Arquitectura
de la Información se define como…el arte y la ciencia de organizar y
etiquetar sitios Web, Intranets, comunidades online y Software para
sustentar la usabilidad.”
Las industrias y la sociedad en general han experimentado un número creciente de movi-

mientos “tectónicos” a lo largo de los siglos precedentes. El ritmo que toman los negocios
hoy en día demandan un alto nivel de agilidad de tanto las TIC como del negocio para
lograr superar a los competidores.
Las empresas se encuentran bajo una presión continua para volverse más competitivas
y colmar las expectativas de sus clientes con más excelencia operacional, por medio de
mejor entendimiento y visibilidad de sus clientes, por medio de más procesos internos
eficientes y por medio de una mejor gestión del riesgo.
Todo esto requiere de unos datos de calidad, pero ¿cómo se colman estas demandas? Por
parte de las cúpulas directivas, el hecho de poder tomar decisiones precisas y a tiempo
se considera al mismo nivel que la capacidad de liderazgo ejecutivo e innovación como
medio vital para la creación de una ventaja competitiva.
Sin embargo, esta tarea resulta efectiva más en teoría que en la práctica ya que se ha
comprobado que un porcentaje muy bajo de los máximos responsables de las empresas
consideran a sus organizaciones como expertas en el empleo de datos de negocio como
medio para tomar mejores decisiones.
En otras palabras, mientras que todos nos damos cuenta de la importancia de nuestros
activos de datos, su valor está lejos de verse materializado y esto tiene un serio impacto
en nuestra habilidad de alcanzar el éxito táctico y estratégico.
4.1. El impacto en el negocio de la arquitectura de información empresarial

El éxito de los negocios depende de una arquitectura de la información efectiva. A conti-
nuación describimos algunas de las implicaciones más comunes entre las estrategias de
negocio y las capacidades de información:
66
• Fusiones y adquisiciones: La integración rápida de lo procesos organizativos de

una adquisición corporativa resulta crítica para el éxito del negocio. Minimizar la
fricción requiere de capacidades de información que minimicen la complejidad,
tales como lo modelos de datos empresariales, servicios de integración de datos,
gestión de datos maestros y gobernanza de datos.
• Toma de decisiones estratégica: Las organizaciones complejas a menudo care-

cen de una visión unitaria de las métricas clave de sus clientes, productos u opera-
ciones. Esto dificulta las decisiones necesarias para conducir al crecimiento de los
ingresos y los márgenes. Permitiendo la visibilidad a través de la empresa requiere
de inversiones en gobernabilidad y modelos de datos comunes. A los decisores se
les debe investir de herramientas robustas para evaluar rápidamente la informa-
ción, implementar lo cambios y monitorizar los resultados.
• Innovación de producto: La evaluación de nuevas fuentes de datos, tales como los

datos de las redes sociales o datos instrumentales pueden descubrir nuevos requi-
sitos y tendencias. Para hacer esto, las organizaciones deben capturar, gestionar y
analizar estos nuevos flujos de datos.
Las organizaciones pueden también agrupar los productos existentes en nuevas

formas o a través de nuevos canales. Esto puede requerir de la coordinación del
producto y la información de clientes a través de organizaciones complejas lo que
está habilitado por la scapacidades de información existentes como son los mode-
los de datos comunes, gobierno de los datos y los servicios de integración.
• Alianzas dinámicas: Muchas organizaciones necesitan la capacidad de establecer

o cambiar rápidamente de socios de negocio. La rápida provisión de estos nuevos
socios resulta crítica y la fidelidad a los estándares de datos y tecnológicos acelera
el proceso. Además, una capacidad de seguridad centralizada, flexible y robusta
asegura que la información se comparte de manera rápida pero segura.
• Mejorada experiencia del cliente o usuario: Los usuarios finales de hoy en día
tienen unas expectativas mucho más altas sobre los tipos de información que en-
cuentran en su día a día, como los datos transaccionales, resúmenes financieros,
datos de localización y geoespaciales, etc.
También desean ver la información combinada desde diversas fuentes y que les
sea presentada visualmente por distintos medios informativos. Esto incrementa
drásticamente el ámbito de los datos y la flexibilidad con la que son gestionados.
Simplemente hay que pararse a pensar: “Sin datos de calidad, ¿somos capaces de
tomar decisiones informadas y predecir los resultados futuros?”
67
4.2. Un posible marco de referencia de la arquitectura de información

empresarial
Posible marco de referencia de la Arquitectura de la Información
68
Podemos distinguir un marco de la Arquitectura de Información Empresarial compuesto

por los siguientes elementos:
• Dominios de los datos
• Modelo de capacidad de la arquitectura de la información
4.2.1. Dominios de datos

Existen distintos tipos y estructuras de datos dentro de una organización. Podemos cate-
gorizar los datos hasta en siete dominios diferentes:
• Datos transaccionales: Son aquellas transacciones de negocio que se capturan

durante las operaciones y procesos de negocio, como registros de compras, peti-
ciones y pagos.
• Metadatos: Definidos como “datos de los datos”, es la descripción de los datos.

Ejemplos son los nombres de datos, unidades o dimensiones de los datos, defini-
ciones de entidades de datos o una fórmula de cálculo de métricas.
• Datos maestros: Se refiere las entidades de datos a nivel de empresa que suponen
un valor estratégico para una organización. Son normalmente no volátiles y no
transaccionales por naturaleza. Típicas entidades de datos maestros son cliente,
producto, proveedor y localización.
• Datos de referencia: Son aquellos hechos de fuentes internas o externas que

mantienen la habilidad de una organización para procesar de manera efectiva las
transacciones, gestionar datos maestros y proporcionar capacidades de ayuda a
la decisión. Ejemplos típicos son por ejemplo los datos geográficos y los datos de
mercado.
• Datos sin estructurar: Componen hasta el 70% de los datos y activos de informa-
ción de una organización. Aquí se incluyen los documentos, imágenes digitales,
datos geo espaciales y archivos multimedia.
• Datos analíticos: Son derivaciones de los datos transaccionales y de operaciones

de negocio que se emplean para satisfacer las necesidades analíticas y de reporte.
Estos datos residen en almacenes de datos (Data Warehouses) y otras aplicacio-
nes de toma de decisiones.
• Datos masivos (Big Data): Se refiere a grandes volúmenes de datos para los que
supone un desafío su almacenamiento, búsqueda, compartición, visualización y
análisis. El crecimiento de tales datos es principalmente por el resultado del creci-
miento de los canales de datos en el mundo actual.
69
Como ejemplos podemos poner los contenidos generados por usuarios en medios
sociales, los registros Web y de aplicaciones, de dispositivos móviles y cámaras,
registros médicos, equipos de medición, etc.
4.2.2. Modelo de capacidad de la arquitectura de la información

Se necesitan distintas habilidades para poder gestionar los distintos tipos de datos y para
procesar diferentes estructuras de datos o la falta de las mismas. Una habilidad está for-
mada por las siguientes dimensiones:
• Objetivos: Las metas y el resultado deseado.
• Métricas: Indicadores clave de rendimiento (Key Performance Indicators, KPI)

y los criterios de éxito para medir la madurez y la efectividad.
• Procesos: Actividades, entradas, salidas y entregables.
• Personas: Roles y conjunto de habilidades necesarios.
A continuación se presentan las habilidades clave más importantes que necesita una or-
ganización para gestionar sus activos de datos e información.
4.2.2.1. Entrega e intercambio de información empresarial

La entrega e intercambio de información empresarial dirige cómo se propaga la informa-
ción directamente a los consumidores de la misma dentro de una organización. Se puede
entregar por medio de diversos canales y dispositivos incluyendo la integración de escri-
torios, alertas y dispositivos móviles.
Los recientes desarrollos con tecnologías colaborativas han permitido el incremento de

las interacciones usuario a usuario y la necesidad de mayor control de accesos a los recur-
sos compartidos.
4.2.2.2. Inteligencia del negocio y almacenes de datos

La inteligencia de negocio y los almacenes de datos proporcionan a los usuarios y las
partes interesadas pistas sobre la salud del negocio.
Más que producir una salida rígida o fija con información desfasada estos sistemas pro-
porcionan la capacidad de que el usuario final cree los portales de información y cuadros
de mando que necesita para acelerar los procesos de toma de decisiones tácticas y estra-
tégicas.
70
Otras capacidades menores de este espacio incluyen lo cimientos de la inteligencia de

negocio (Business Intelligence, BI), los almacenes y mercados de datos tradicionales
(DataWarehouses, DataMarts), analíticas predictivas, minería de datos y la gestión del
rendimiento empresarial.
4.2.2.3. Integración de datos

Las organizaciones se están volviendo cada vez más dependientes de la integración de
datos para unir en una solución cohesionada a los sistemas de aplicaciones y los almace-
nes de datos.
Las fuentes heredadas, las actividades de fusiones y adquisiciones y las soluciones SaaS/
COTS necesitan la integración de sistemas para dar respuesta a las necesidades de ne-
gocio.
Existe un espectro muy amplio de capacidades de integración de datos que cubren desde
los sistemas de proceso de lotes (Batch) a las necesidades en tiempo real que incluyen
operaciones de extracción, transformación y carga (Extract, Transform, Load, ETL), cap-
tura de datos de cambios, integración basada en eventos, en mensajes y en tiempo real.
Para gestionar el volumen, velocidad y variedad de datos masivos se cuenta con capacida-
des recientes de procesamiento de datos distribuidos y de medios sociales.
4.2.2.4. Gestión de datos maestros

La gestión de datos maestros consiste en un número de sub-capacidades únicas para la
gestión de los datos maestros de una empresa. Entre ellas se encuentran:
• Habilidad para especificar una definición de registro de oro.
• Funciones para gestionar los permisos de pervivencia por encima de las reglas
para las fusiones y ajuste.
• Centros maestros como centros de datos de clientes, centros de datos de productos,

centros de datos de localización y centros de datos de proveedores con modelos
específicos de datos para cada uno de los centros y datos de referencia relevante.
• Capacidades de gestión de dimensión y jerarquía.
71
4.2.2.5. Modelo de datos empresarial

Los silos de datos representan un desafío significativo para muchos de nuestros clientes.
La carencia de un modelo empresarial de datos y la habilidad para conectar y realizar la
correlación de los datos a través de las distintas áreas (p.e. clientes con productos) reduce
la eficacia de la inversión de una organización en su información. Se pierden muchas
oportunidades por la incapacidad para recolectar nuevas percepciones de los clientes y
las actividades del negocio.
El modelo de datos empresarial es una disciplina clave para inculcar dentro de la organi-
zación y asegurar que no existe ninguna solución que conduzca el modelo de datos sino
que sea las necesidades de datos empresariales.
El análisis de la cadena de valor de los procesos y funciones de negocio clave puede

ayudar a dibujar los límites del dominio de datos empresariales y a identificar lo áreas
temáticas clave. El modelo de datos conceptual y el modelo lógico de datos compensan
las siguientes capas del modelo de datos empresarial.
4.2.2.6. Gestión de contenidos

Dentro de una organización, la gran mayoría de los activos de información se encuentran
desestructurados o como mucho semi-estructurados. Por lo tanto, reconocemos dentro de
nuestro marco de trabajo la gestión de contenidos como una capacidad clave de máximo
nivel para gestionar el contenido, registros, multimedia y las capturas de imágenes.
Se requieren también mecanismos adecuados de flujo de trabajo (Workflow) y de bús-

queda para permitir una rápida recuperación de información pertinente para la toma y
mantenimiento de decisiones.
4.2.2.7. Gobierno, calidad y gestión del ciclo de vida de los datos

Ninguna disciplina de arquitectura, sin tener en cuenta el dominio o subdominio, estaría
completa sin un adecuado gobierno, aseguramiento de calidad y gestión del ciclo de vida.
Los procesos y políticas son necesarios para hacer cumplir una disciplina sólida y las me-
jores prácticas dentro de una organización.
De igual manera que los sistemas aplicativos y otros activos arquitectónicos, la gestión de
ciclo de vida asegura que nuestra organización sólo retiene la información necesaria para
su tiempo de vida y el cumplimiento legal.
72
4.2.2.8. Gestión de seguridad de los datos

La seguridad de los datos controla si las personas adecuadas tienen acceso a la informa-
ción adecuada en el tiempo correcto. Los datos se protegen mientras se encuentran en
tránsito así como cuando se están almacenados. Además, se emplea una monitorización
continua para asegurar que cualquier violación de los estándares y políticas se detecta y
gestionan inmediatamente y de forma proactiva.
Dentro de la ingente cantidad de información que se genera hoy en día, las organizacio-
nes se enfrentan a numerosos desafíos relativos a la seguridad de los datos. La informa-
ción normalmente se distribuye a lo largo de múltiples aplicaciones y las bases de datos
haciendo que la disponibilidad y accesibilidad a la misma constituya todo un desafío.
El aseguramiento de que la información está conectada, disponible, segura y fiable a tra-

vés variadas fuentes y destinos es clave para las empresas para obtener un retorno de su
inversión en la información.
4.2.2.9. Gestión de tecnología de los datos

Las organizaciones necesitarán desarrollar o contratar las habilidades clave de gestión
de tecnología de datos para manejar la creciente cantidad de información en bruto que
existe en las empresas hoy en día.
Las organizaciones están acumulando día tras día Gigas o Terabytes de datos y se hace
necesaria una gestión deliberada de dichos recursos para controlar los costes y asegurar
la agilidad para continuar adelante. Una infraestructura de datos sólida resulta una capa-
cidad crítica dentro de la arquitectura de la información.
El núcleo de este fundamento es la habilidad del sistema de gestión de bases de datos

para almacenar y recuperar de manera efectiva diferentes estilos y estructuras de datos e
información. La habilidad para gestionar y operar otros componentes de infraestructura
de manera altamente disponible y recuperable es esencial también para asegurar la dis-
ponibilidad de los datos en todo momento..
73
Razón
Nombre Declaración Implicaciones
fundamental
Información Es necesario que la in- Debemos medir y docu- La información debe ser acce-
como activo formación se gestione y mentar el actual valor, sible para sus usuarios finales
procese de igual mane- riesgo y coste del acti- sin malgastar recursos. La ar-
ra que un activo físico vo como lo haríamos con quitectura de la información
cualquier otro activo físico debe forzar la gestión y com-
de la empresa como equi- partición de información para
pos o propiedades. Este maximizar su valor con el me-
principio nos fuerza a de- nor coste para el negocio.
jar de tratar la información
como una mercancía gra- El valor de la información
tuita e infinitamente dis- debe ser empleado sin tener
ponible porque no lo es. en cuenta su estructura, for-
La facilidad de movimiento mato o semántica. Esto nos
y réplica de información lleva de vuelta a la noción de
es una causa oculta de in- convergencia donde el nego-
eficiencias significativas y cio debe ser capaz de apalan-
coste en términos de ges- car el valor de la información
tión de la información. tanto i está almacenado den-
tro de un fichero digital deses-
tructurado o en un registro de
una base de datos relacional.
Clasificación de La clasificación del valor Un entendimiento fun- La gestión y seguridad de la

valor y riesgo y riesgo de una activo damental del valor de un información puede ser costo-
de información debe- activo de información para sa. Lo recursos han de prio-
ría estar basado en sus el negocio y del riesgo de rizarse hacia la protección
fundamento de gobier- negocio que supone la de la calidad, disponibilidad,
no y gestión exposición, corrupción o accesibilidad y seguridad, de
pérdida es esencial para acuerdo con el valor y riesgo
determinar las estrategias del negocio. Un programa ex-
más apropiadas y las in- haustivo de gestión del riesgo
versiones a realizar para del negocio debe estar funda-
protegerlo y gestionarlo. mentado en un entendimiento
del valor y riesgo de los acti-
vos de información clave.
Versión única Los dato deberían ser Los datos, gestionados a La gestión de los datos y la
de la verdad recogidos una única vez nivel de aplicación, requie- información será vista desde
de manera electrónica ren ser replicados, alma- una perspectiva empresarial.
por medio de un único cenado y gestionados en La gestión local de los datos
interfaz y compartidos distintos sistemas, crean- podría resultar útil hasta cier-
entre los distintos sis- do versiones localizadas to punto, pero su efectividad
temas en contenido y estructura. está muy limitada. Se nece-
Como resultado, resulta sita adoptar e implementar
difícil integrar la informa- el enfoque de gestión de da-
ción de negocio a través tos maestros para gestionar
de la líneas de negocio y el ciclo de vida de los datos
suelen aparecer discre- compartidos a través de la or-
pancia en los datos ganización.
74
Razón
fundamental
Calidad de la Se necesita establecer Esto obliga a todas nues- La calidad de los datos se de-
Información los requisitos de calidad tras decisiones de diseño bería medir en las siguientes
de los activos de infor- a estar sujetas a un están- dimensiones:
mación dar básico y por lo tanto
elimina el almacenamien- -Completitud: % del modelo
to de largas pilas de datos de datos lógico que se rellena
inservibles. con datos reales
-Precisión: El mismo valor que

la fuente de verdad dentro del
período de actualización
-Oportunidad: Una métrica

definida que compromete la
precisión dentro de un inter-
valo de tiempo dado (p.e. ac-
tualizado en las últimas 24h,
en tiempo real,etc)
-Accesibilidad: La habilidad
del usuario u otra aplicación
para consumir los datos me-
dida en métricas cualitativas
(p.e. entendible por usuario,
capaz de integrarse con otro
sistema, etc)
La información Es necesario que todos Poseer una fuente autori- Este principio normalmente
posee fuente los datos de negocio zada para todos los datos rige a una solución de gestión
autorizadas posean una fuente au- posibilita que toda gestión de datos maestros que desig-
torizada de datos sea responsable, na a sistema a ser fuente de
porque es posible sepa- verdad alrededor de distintos
rar las responsabilidades tipos de datos de negocio.
de propiedad y adminis-
tración y por lo tanto mi-
nimizar el resigo de una
violación de la privacidad
y confidencialidad de lo
datos. Este principio tiene
también un impacto direc-
to en asegurar una mejor
calidad de lo datos porque
la fuente autorizada pue-
de actuar como el punto
central de integración para
cualquiera que necesite
los datos.
75
Razón
fundamental
Seguridad de la Es necesario asegurar Se debe encontrar un Tradicionalmente las solucio-

Información la información durante equilibrio entre la com- nes de seguridad de los datos
todo su ciclo de vida partición abierta de in- se han centrado en lo datos
formación y liberación de en tiempo de ejecución dentro
información por medio de de una base de datos activa.
legislaciones y por otro Sin embargo, existen muchos
lado la necesidad de res- riesgos en los datos fuera de
tringir la disponibilidad este entorno de tiempo de
de información sensible, ejecución. Por lo tanto, las
propietaria y confidencial. soluciones de seguridad de
La violación de los datos los datos necesitan tratar to-
resulta muy costosa para das las áreas del ciclo de vida
cualquier organización. de la información: entrada,
Asegurar a lo socio y da- almacenamiento, acceso y re-
tos corporativos es crítico tención.
para reducir el riesgo re-
gulatorio y de cumplimien-
to.
Accesibilidad de La información debe ser El sencillo acceso a los da- Es necesario clasificar la in-
la información accesible para que los tos favorece procesos de formación de acuerdo con los
usuarios puedan reali- tomas de decisión efecti- principios de seguridad de la
zar sus funciones vos y eficientes y permite organización que determi-
una respuesta oportuna narán el nivel de acceso de
a las solicitudes de infor- los empleados, contratistas,
mación y la entrega del fabricantes, proveedores, so-
servicio. cios, clientes, acceso general,
etc. Las definiciones de segu-
ridad de datos subyacentes
pueden diferir de los aspectos
de seguridad de la informa-
ción, particularmente una vez
que los datos se combinan y
se les dota de contexto, donde
pueden llegar a tener nuevos
niveles de sensibilidad.
Administración Cada dato posee una El establecimiento de la Cada elemento de dato re-
de datos persona o rol como úl- administración asegurar la quiere una única y final pro-
timo custodio calidad de lo datos que se piedad por un rol o persona
comparte única. Esto no implica que
todos los clientes, productos u
otros elementos de datos ten-
gan una propiedad común. En
vez de eso se maneja una ma-
triz de responsabilidades que
asegura que los problemas o
conflictos siempre tienen un
último punto de escalado.
76
Razón
fundamental
Impulso por Es necesario que la ar- Un enfoque integral para La empresa debe establecer
metadatos quitectura de la infor- la gestión de lo metadatos el vocabulario inicial del ne-
mación sea impulsada es la clave para reducir la gocio. Las definiciones se usa-
por los metadatos complejidad y promover la rán uniformemente por toda
reusabilidad a través de la empresa. En el momento
la infraestructura. Un en- en el que una nueva defini-
foque impulsado por me- ción de datos sea necesaria,
tadatos hace más sencillo el esfuerzo de definición será
a los usuarios entender el coordinado y reconciliado con-
significado y el linaje de tra el “glosario” corporativo
los datos en su entorno de descripciones de datos. El
administrador de datos de la
empresa realizará esta coor-
dinación. Las ambigüedades
que resulten de definiciones
múltiples y dispares deben
dar lugar a definiciones em-
presariales aceptadas. Se ne-
cesitan coordinar las múltiples
iniciativas de estandarización
de datos y asignar las respon-
sabilidades de administración
de datos funcionales
Medición de la Se medirá la calidad de La calidad de los datos es Los problemas de calidad de los
calidad los datos relativa al propósito para el datos resultan el factor limitan-
cual se aplica. Los deciso- te más crítico para el apalanca-
res no sólo necesitan tener miento de los activo de informa-
acceso a los datos. Tam- ción. La mayoría de empresas
bién necesitan comprender subestiman la extensión, severi-
los tiempos, reconciliación, dad e implicaciones de negocio
completitud y precisión de de estos problemas. Se necesita
esos datos. La calidad de los realizar un esfuerzo de pragma-
datos no resulta ni abstracta tismo para apreciar los tipos de
ni cualitativa. Por el contra- problemas que pueden existir
rio, debería ser medida en y revelarlos antes de lanzarse
términos absolutos. a esfuerzos de limpieza e inte-
gración de datos. Las investiga-
ciones muestran que la calidad
de la información resulta más
importante que el volumen de la
información.
Principios rectores de la Arquitectura de la Información
Dato importante
Dentro del ámbito de la arquitectura de la información se escuchan con frecuencia

los términos Usuarios, Contenido y Contexto. Los tres conforman la base de nuestro
modelo para la práctica de un diseño efectivo de la arquitectura de información.
77
4.3. Distinción entre EIA y IA

Existen dos elementos clave que distinguen entre la EIA y la IA básica:
• El papel que la EIA juega en el diseño, desarrollo y mantenimiento de la infraes-

tructura semántica de una empresa: Esto se refiere en grandes trazos a cómo las
habilidades y herramientas de la IA son capaces de sostener una investigación
sobre las necesidades de información y comportamientos de los usuarios, el dibujo
del mapa de los diferentes grupos de una organización, estudios etnográficos, etc.
• El segundo es el alcance y tipo de proyectos en la que la EIA puede estar involu-

crada, dado que desarrollan aplicaciones que emplean y se construyen sobre esta
infraestructura semántica: En proyectos típicos de información como portales y
búsquedas e incluso proyectos individuales de Intranets es importante enfocarlos
con una perspectiva empresarial. Uno de los motivos por los que suelen fallar estos
proyectos es porque no se tiene en cuenta a la empresa en su totalidad.
Por otro lado, los arquitectos de información empresariales trabajan en un rango más am-
plio de proyectos y no sólo proyectos típicos de información como gestión de contenidos
y búsquedas. Estos proyectos incluyen el añadir un énfasis importante en cómo la organi-
zación y presentación de la información impacta a todas las actividades de negocio (sin
llegar a decir a los otros grupos como llevar sus actividades de negocio).
Además, los arquitectos empresariales de información deberían estar implicados en pro-

yectos de gestión de conocimiento como programas de innovación, comunidades de co-
laboración o práctica.
Por último, los EIA deberían estar implicados en la arquitectura de la información de la

empresa (no sólo en la arquitectura de información empresarial), aplicando sus habilida-
des y conocimiento para entender, modelar y sostener cómo la información y el conoci-
miento fluyen dentro de la empresa.
Esto puede incluir el estudio y desarrollo de nuevas arquitecturas de información para

definir cómo la gente realiza su trabajo del día a día, como los escritorios y sitio Web están
configurados, cómo esos diseños pueden impedir el uso diario de la información y cómo
mejorarlos.
Podría también emplear un análisis extendido de red social de quién obtiene la informa-
ción y de qué personas o repositorios de contenido y que tipo de información no llega a
las audiencias consideradas críticas.
En otras palabras, en vez de centrarse en el diseño de la Intranet, un EIA puede hacerlo

en las personas de la organización y dar soporte a las estrategias de búsqueda de informa-
ción y comportamientos que son parte de su rutina diaria.
78
4.4. Definiendo la arquitectura de la información en el entorno web

En términos más específicos y como un subdominio de la Arquitectura de Información
Empresarial y de acuerdo al Instituto de Arquitectura de la Información (IA Institute)
la disciplina de la Arquitectura de la Información se define como “…el arte y la ciencia
de organizar y etiquetar sitios Web, Intranets, comunidades online y Software para
sustentar la usabilidad”.
Dado que la información crece de manera exponencial, la usabilidad se está convirtiendo

en el factor crítico de éxito para los sitios Web y las aplicaciones de Software. Una buena
IA establece un trabajo de campo necesario para que un sistema de información tenga
sentido para sus usuarios.
Otras posibles definiciones que se manejan para definir la IA son:
• El diseño estructurado de entornos de información compartidos.
• La combinación de la organización, etiquetado, búsqueda y sistemas de navega-

ción dentro de los sitios Web e Intranets.
• El arte y ciencia de dar forma a productos de información y experiencias para sos-

tener la usabilidad y encontrabilidad (findability) (facilidad de encontrar algo).
• Una disciplina emergente y comunidad de práctica centrada en llevar los princi-

pios del diseño y la arquitectura al entorno digital.
Si profundizamos un poco en la definición podemos apreciar con mayor detalle los prin-
cipios de la IA:
• Información: Empleamos el término información para distinguir entre la arqui-

tectura de información de los datos y la gestión del conocimiento. Los datos son
hechos y cifras. Las bases de datos relacionales están altamente estructuradas y
proporcionan respuestas específicas a preguntas específicas. El conocimiento es lo
que está en la mente de la gente. Lo gerentes del conocimiento desarrollan herra-
mientas, procesos e incentivos para alentar a la gente a compartir el conocimiento.
La información reside precisamente en ese caótico lugar intermedio. Con los siste-
mas de información encontramos con frecuencia que no existe una única respues-
ta correcta para una pregunta en particular.
En general nos encontramos preocupados por la información de toda forma y ta-

maño: sitios Web, documentos, aplicaciones Software, imágenes y demás. Además
también estamos preocupados por los metadatos (Metadata), término usado para
describir y representar el contenido de los objetos tales como documentos, perso-
nas, procesos y organizaciones.
79
• Estructuración, organización y etiquetado: Se refiere a lo que los arquitectos de

información hacen mejor. La estructuración implica determinar los niveles apro-
piados de granularidad para los átomos de información (por ejemplo en tu sitio
Web) y decidir cómo están relacionados entre sí.
La organización implica la agrupación de esos componentes en categorías distinti-

vas y que tengan sentido. Por último, el etiquetado significa aclarar cómo nombrar
a esas categorías y a la serie de enlaces de navegación que nos conducen a ellas.
• Encontrar y gestionar: La facilidad para encontrar algo (“encontrabilidad”) es un

factor crítico de éxito para la usabilidad global. Si los usuarios no son capaces de
encontrar lo que necesitan por medio de una combinación de navegación, búsque-
da y preguntas, entonces el sitio falla.
Pero el diseño centrado en el usuario no es suficiente. Las organizaciones y las

personas que gestionan la información son también importantes. Un arquitecto
de la información debe equilibrar las necesidades de los usuarios con los objetivos
del negocio. La gestión eficaz del contenido y las políticas y procedimientos claros
son esenciales.
• Arte y Ciencia: Disciplinas tales como la ingeniería de la usabilidad y la etnogra-

fía están ayudando a atraer el rigor del método científico para el análisis de las
necesidades de los usuarios y los comportamientos de búsqueda de información.
Estamos siendo cada vez más capaces de estudiar los patrones de uso y subsecuen-
temente realizar mejoras a nuestros sitios Web.
Pero la práctica de la arquitectura de la información nunca será reducida a nú-

meros dado que existe demasiada ambigüedad y complejidad. Los arquitectos de
información deben confiar en su experiencia, intuición y creatividad. Debemos ser
capaces de asumir riesgos y confiar en nuestra intuición. Este es el “arte” de la ar-
quitectura de la información.
4.5. Qué no es la arquitectura de la información

Una de las formas más efectivas de definir algo es identificar sus límites. Todo el mundo
hace esto constantemente: ésta es mi propiedad, ésa es tu propiedad, esto es España, eso
es Francia, ella es cirujano, él es oftalmólogo,… Algunas veces es muy fácil explicar las
diferencias: los perros, gatos, delfines y humanos son todos claramente mamíferos. Los
peces viven en el agua y respiran a través de sus agallas y ponen huevos...
En cualquier caso, por muchas clasificaciones que se tengan enseguida nos encontramos
con problemas.
80
¿Qué pasa con los peces que tienen pulmones? ¿Qué pasa con los peces que no parecen
peces? ¿En qué lugar los clasificamos?
Las taxonomías biológicas han estado discutiendo estos problemas de clasificación du-
rante decenios. El trazado de los límites de la arquitectura de información resulta incluso
más escurridizo. Algunas disciplinas claramente no son Arquitectura de Información:
• El diseño gráfico NO es Arquitectura de Información
• El desarrollo de Software NO es Arquitectura de Información
• La ingeniería de la Usabilidad NO es Arquitectura de Información
Parece claro, ¿verdad? Sin embargo, una vez que uno comienza a trabajar en la caótica
realidad del diseño y construcción de sitios Web se encuentra con esas áreas grises que
se encuentran entre las distintas disciplinas.
4.6. Funciones e importancia de la arquitectura de la información

La pregunta más obvia que podemos hacernos es ¿por qué es necesaria la Arquitectura
de la Información? Hoy en día, todo negocio tiene un problema de información. Tanto
si una empresa se encuentra peleando con la manera de manejar una miríada de datos
históricos o el cómo crear taxonomías dentro de un nuevo producto, la arquitectura de la
información resulta una parte importante de la solución.
Algunas organizaciones han creado puestos de arquitecto de información, que ejercitan

papeles de liderazgo en el desarrollo de procesos para todo, desde los sistemas de ficheros
a la arquitectura de productos.
Otras organizaciones no poseen esas posiciones tan formales pero cuentan con la Arqui-
tectura de la Información como una competencia crítica que deben poseer tanto sus es-
trategas de Internet, diseñadores de interacción como sus arquitectos del conocimiento.
En ambos tipos de organizaciones se emplean las mejores prácticas en la Arquitectura de

Información para el desarrollo de los interfaces que facilitan el flujo de información útil y
relevante hacia el usuario.
Una organización necesita la Arquitectura de la Información por los siguientes motivos:
• Los objetivos de negocio dictan el diseño o un rediseño significativo de un interfaz

de usuario o sitio Web.
• La inaccesibilidad de la información hacia sus clientes y empleados hace aumentar

los costes, incluyendo los de los centros de servicio telefónico de atención al clien-
te (Call-Center) y de soporte técnico (Help-Desk).
81
• Las iniciativas de gestión del conocimiento están migrando la información desde

los escritorios hasta un sistema central de fichero o Intranet.
Pero, ¿por qué es importante la IA? ¿Por qué deberíamos preocuparnos? ¿Por qué una
empresa o sus clientes deberían invertir tiempo y dinero en el diseño de sus Arquitec-
turas de Información? ¿Cuál es el retorno de la inversión (ROI)? Cuando se calcula la
importancia de la IA para nuestra empresa se deberían considerar los siguientes costes y
proposiciones de valor:
• Costes de encontrar información: ¿Qué coste tiene que cada empleado en tu em-
presa gaste cinco minutos extra al día peleando para encontrar respuestas en la
Intranet? ¿Cuál es el coste de frustrar a tus clientes con un sitio Web organizado
pobremente?
• Costes de NO encontrar información: ¿Cuántas malas decisiones se toman al día

en tu empresa porque los empleados no encontraron la información que necesita-
ron? ¿Cuántas duplicidades de esfuerzos se produjeron por este motivo? ¿Cuántos
clientes se perdieron porque no pudieron encontrar el producto que deseaban en
tu sitio Web? ¿Cuánto tiempo gastas al día dando soporte telefónico a los actuales
clientes porque detestan tener que navegar en tu base de datos de soporte técnico
en línea?
• El valor de la educación: ¿Cuál es el valor de educar a tus clientes sobre nuevos

productos y servicios relacionados con los que ya están buscando de manera acti-
va en tu sitio Web?
• Coste de la construcción: ¿Cuál es el coste del diseño y construcción de un sitio

Web? ¿Cuánto cuesta rehacerlo seis meses después porque no soporta la “encon-
trabilidad” o no es escalable?
• Costes de mantenimiento: De manera similar, ¿qué cuesta asegurar que los bue-
nos diseños no se desmoronen con el tiempo? ¿Sabrá la gente que mantiene tu
sitio Web dónde poner los nuevos contenidos y cuándo retirar los que estén des-
fasados?
• Costes de formación: Por ejemplo, para los sistemas de información internos de

misión crítica que soportan centros de atención telefónica ¿qué cuesta formar a
los empleados para que usen el sistema? ¿Cuánto se podría ahorrar si no fuese tan
complicado su uso?
• El valor de la marca: No importa lo bonito que pueda resultar ser tu sitio Web, si
los clientes no son capaces de encontrar lo que necesitan tu marca pierde valor
ante sus ojos. ¿Cuánto gastaste en los anuncios de TV con el objetivo de construir
tu imagen de marca?
82
La lista anterior podría continuar dependiendo de la situación particular de cada empresa

u organización.
Seguro que existen una infinidad de oportunidades para hacer dinero, ahorrar, mejorar
la satisfacción de los empleados o clientes o simplemente hacer un mundo mejor. El ob-
jetivo es descubrir quiénes son nuestros clientes y comunicarse con ellos lo más clara y
directamente que sea posible.
No se pretende afirmar que esto sea fácil, de hecho, resulta muy difícil calcular un valor
exacto del retorno de la inversión en la Arquitectura de la Información (simplemente por-
que existen muchas variables).
Realmente esto no es muy diferente de otras áreas de actividad dentro del mundo de
los negocios, lo único es que en otras áreas más tradicionales como ventas, marketing,
ingeniería, recursos humanos o administración han tenido más tiempo para ordenar sus
historias.
4.7. Práctica de la arquitectura de la información en el mundo real

Dentro del ámbito de la arquitectura de la información se escuchan con frecuencia los
términos Usuarios, Contenido y Contexto. Los tres conforman la base de nuestro modelo
para la práctica de un diseño efectivo de la arquitectura de información. Subyacente a este
modelo está el reconocimiento de que no se pueden diseñar arquitecturas de información
útiles en el vacío.
Un arquitecto no puede encerrarse en una habitación oscura con un montón de contenido

para organizarlo y emerger con una gran solución. Simplemente no se sostendrá a la luz
del día.
Los sitios Web e Intranets no son construcciones estáticas sin vida. Más bien, existe una
naturaleza orgánica dinámica tanto para los sistemas de información como para los en-
tornos más extensos donde existen.
No estamos hablando del viejo mundo de organización de cartulinas de un catálogo de

biblioteca sino de complejos sistemas adaptativos con capacidades emergentes.
Hablamos de ricos torrentes de información fluyendo dentro y más allá de los límites de
las unidades de negocio, departamentos, instituciones y países. Hablamos de desorden
y errores, ensayo y error, la supervivencia del más preparado. De hecho, se emplea el
concepto de “Ecología de la Información” compuesta de usuarios, contenido y contexto
para dirigir las complejas dependencias que existen. Estas relaciones se pintan sobre el
diagrama de Venn mostrado a continuación para ayudar a la gente a visualizar y entender
estas relaciones.
83
Los 3 círculos de la Arquitectura de la Información
Los tres círculos ilustran la interdependiente naturaleza de usuarios, contenido y contex-

to dentro de una compleja ecología de información adaptativa. En resumen, necesitamos
entender los objetivos de negocio que se esconden detrás del sitio Web y los recursos de
que se disponen para el diseño y la implementación.
Necesitamos estar al tanto de la naturaleza y volumen de contenidos que exista a día de

hoy y que pueda cambiar en un año desde ahora. Y debemos aprender acerca de las nece-
sidades y los comportamientos de búsqueda de información de nuestras audiencias más
importantes.
Un buen diseño de arquitectura de la información recibe información de las tres áreas.
4.7.1. Contexto
Todos los sitios Web e Intranets existen dentro de un contexto organizativo o de negocio
en particular. Tanto si es de manera explícita como implícita, cada organización tiene una
misión, metas, estrategia, plantilla, procesos y procedimientos, infraestructura física y de
tecnología, presupuesto y una cultura.
El conjunto colectivo de capacidades, aspiraciones y recursos es único para cada organi-

zación. ¿Se puede entonces afirmar que la arquitectura de la información deba ser única
para cada organización? Después de todo, las compañías compran muebles de oficina
genéricos, invierten en plataformas de tecnología estándar, e incluso externalizan activi-
dades importantes a proveedores que sirven a sus competidores. Aun así, la respuesta es
un rotundo “Sí”.
Las arquitecturas de información deben estar ajustadas de manera única a sus contextos.
El vocabulario y estructura de tu sitio Web y tu Intranet es un componente principal de la
conversación evolutiva entre tu negocio y tus clientes y empleados.
84
De hecho, influye en cómo piensan sobre tus productos y servicios. Les indica qué esperar
de ti en el futuro. Les invita o limita la interacción entre clientes y empleados.
Tu arquitectura de la información proporciona quizás la más tangible de las instantáneas

de la misión, visión, valores, estrategia y cultura de tu organización. ¿Realmente desea
uno que esa instantánea sea como la de la competencia? El elemento clave del éxito es el
entendimiento y el alineamiento. Primero debes entender el contexto del negocio. ¿Qué
lo hace único? ¿Dónde está hoy el negocio y donde quiere estar mañana?
En la mayoría de las ocasiones se está tratando con un conocimiento tácito y no está escri-
to en ningún sitio. Está en la cabeza de las personas y nunca se ha explicado en palabras.
Existen una variedad de métodos para extraer y organizar este entendimiento del contex-
to. Por lo tanto, se han de encontrar maneras para alinear la arquitectura de la información
con los objetivos, estrategia y cultura del negocio.
4.7.2. Contenido
Definimos contenido de manera muy amplia para incluir tanto a los documentos, aplica-
ciones, servicios, esquemas y metadatos que las personas necesitan para usar o encontrar
en un sitio Web. Para emplear un término técnico, es la materia que constituye tu sitio
Web.
Entre otras cosas, la Web es una poderosa herramienta de comunicación y la comunica-

ción se construye con palabras y frases que tratan de agrupar un significado. Por supues-
to, también reconocemos la Web como una herramienta para tareas y transacciones, una
plataforma tecnológica flexible que permite las compras y ventas, cálculos y configuracio-
nes, ordenación y simulación.
Incluso el sitio Web de comercio electrónico más orientado a tareas tiene contenido que
los clientes deben ser capaces de encontrar. Si se realiza una encuesta sobre el contenido
a través de una variedad de sitios, las siguientes características emergen como factores de
distinción de cada ecología de información.
4.7.2.1. Propiedad
¿Quién crea y es el dueño del contenido? ¿Está la propiedad centralizada dentro de un
grupo de autorización de contenido o distribuida a través de los diversos departamentos
funcionales? Las respuestas a estas preguntas juegan un papel muy importante para in-
fluir sobre el nivel de control que uno tiene sobre el resto de dimensiones.
85
4.7.2.2. Formato
Los sitios Web y las Intranets se están volviendo los medios unificadores para el acceso
a todos los formatos digitales dentro de una organización. Las bases de datos, catálogos
de productos, archivos de discusión de Lotus, reportes técnicos en MS Word, reportes
anuales en formato (Portable Data Format, PDF), aplicaciones de compra de material de
oficina, video-mensajes del consejero delegado…
4.7.2.3. Estructura
Todos los documentos no se crean de igual manera. Un memorándum importante debe
contener menos de 100 palabras. Un manual técnico puede que tenga más de 1000 pági-
nas. Algunos sistemas de información están construidos alrededor del paradigma docu-
mento, siendo éste la mínima unidad discreta.
Otros sistemas por el contrario toman un componente del contenido o un enfoque del
activo digital, por medio del uso de algún lenguaje de marcas (p.e. XML/ SGML) para
permitir la gestión y acceso a un nivel más fino de granularidad.
4.7.2.4. Metadatos
¿Hasta qué punto se han creado los metadatos que describen el contenido y los objetos
que están dentro de tu sitio Web? ¿Se han etiquetado los documentos de manera au-
tomática o manual? ¿Cuál es el nivel de calidad y consistencia? ¿Existe un vocabulario
controlado? ¿Se les ha permitido a los usuarios proporcionar sus propias etiquetas “folk-
sonómicas” del contenido?
Estos factores determinan en cuánto se está comenzando desde cero con respecto a la
recuperación de información y la gestión del contenido.
4.7.2.5. Volumen
¿De cuánto contenido estamos hablando? ¿Cien aplicaciones? ¿Un millar de páginas?
¿Un millón de documentos? ¿Cuánto de grande es tu sitio Web?
4.7.2.6. Dinamismo
¿Cuál es la tasa de crecimiento o facturación? ¿Qué cantidad de nuevo contenido se espe-
ra añadir el año que viene? ¿Cómo de rápido se quedará desfasado?
Todas estas dimensiones anteriores componen un mix único de contenido y aplicaciones

lo que a su vez sugiere la necesidad de contar con una arquitectura de la información
personalizada.
86
4.7.3. Usuarios
Las diferencias en las preferencias de los clientes y comportamientos dentro del mundo
físico se traducen en diferentes necesidades de información y comportamientos de bús-
queda de información en el contexto de los sitios Web e Intranets.
Por ejemplo, los ejecutivos pueden necesitar encontrar unos buenos documentos sobre
un tema en particular de manera muy rápida. Los analistas de investigación pueden ne-
cesitar encontrar todos los documentos relevantes y pueden estar dispuestos a gastar
varias horas en la búsqueda. Los gerentes pueden tener un alto nivel de conocimiento de
la industria pero pocas habilidades de navegación y búsqueda.
Los adolescentes pueden ser nuevos en un área de conocimiento pero realmente conocen
como manejar un gestor de búsqueda.
¿Conoces quién está manejando tu sitio Web? ¿Sabes cómo los están usando? Y lo que es
más importante, ¿sabes qué información quieren de tu sitio Web?
Estas no son preguntas que uno pueda contestar en sesiones de lluvia de ideas o grupo
de trabajo. Lo que realmente se necesita es salir al mundo real y estudiar a tus “usuarios
en la nube”.
4.8. Gestión de datos

Los datos y la información se consideran de manera creciente como activos de la empre-
sa que deben protegerse y mejorarse. Según el Data Management Body of Knowledge
(DMBOK), podemos definir la gestión de datos como “El desarrollo, ejecución y super-
visión de planes, políticas, programas y prácticas que controlan, protegen, entregan
y aumentan el valor de los activos formados por los datos y la información”.
La gestión de datos es una función importante para las empresas en la era de la informa-
ción y supone una responsabilidad compartida entre los administradores de los datos de
negocio y los profesionales de la gestión de datos.
Para ser más precisos, podemos afirmar que el negocio es el fideicomisario o administra-
dor legal de los datos y los profesionales TI los custodios o guardianes de los mismos.
Existen hasta nueve funciones de gestión de datos que comentaremos más adelante:
1. Gobierno de datos
2. Gestión de la arquitectura, análisis y diseño de datos
3. Gestión de bases de datos
87
4. Gestión de seguridad de datos
5. Gestión de la calidad de datos
6. Gestión de datos maestros y de referencia
7. Gestión de inteligencia de negocio y de almacenes de datos
8. Gestión documental, de contenidos y de registros
9. Gestión de metadatos
Gobierno de Datos
Las funciones anteriores se encuentran descompuestas en cuatro tipos de actividades,

cada cual ejecutada por distintos roles y resultando en una serie de entregables. Los tipos
de actividades son:
88
1. Planificación (P): Actividades que establecen el curso táctico y estratégico para

otras actividades de gestión de datos.
2. Desarrollo (D): Actividades que se llevan a cabo dentro de los proyectos y son re-
conocidas como parte del ciclo de vida de desarrollo de sistemas (Software Develo-
pment Life Cycle ,SDLC), creando entregables de datos a través del análisis, diseño,
construcción, pruebas y despliegue.
3. Control (C): Actividades de supervisión ejecutadas de modo continuo.
4. Operación (O): Actividades de soporte y servicio ejecutadas de modo continuo.
La relación entre funciones y actividades podemos verla aquí:
FUNCIONES ACTIVIDADES
Planifica Desarrolla Controla Opera
Gobierno de datos x x
Gestión arquitectura
x
datos
Desarrollo de Datos x x x
Gestión operaciones de
x x x
BBDD
Gestión seguridad datos x x x
Gestión datos maestros

x x x x
y de referencia
Gestión Inteligencia de
negocio y almacenes de x x x x
datos
Gestión contenidos y
x x x
documentos
Gestión metadatos x x x x
Gestión calidad de datos x x x x
Relación entre funciones y actividades
89
Llegados a este punto, podríamos preguntarnos los motivos que podrían impulsar a la
empresa a regir su arquitectura de datos por estos principios. Entre los más importantes
y fácilmente entendibles podemos citar:
• Evitar el riesgo de reputación
• Reducir los costes asociados con la pobre calidad de los datos
• Cumplimiento de obligaciones legales
• Mejora de la productividad a través de la entrega a tiempo de datos de alta calidad
Esto nos lleva a preguntarnos cuáles serían los problemas a los que nos enfrentaríamos
de no seguir una metodología robusta o unas buenas prácticas contrastadas. En este esce-
nario podríamos encontrarnos con las siguientes situaciones:
• Informes imprecisos
• Información fragmentada
• Imposibilidad de desmantelar sistemas antiguos
• Campos de datos usados para varios conceptos
• Definiciones de datos imprecisas
• Seguridad de datos inadecuada
4.8.1. Gobierno de datos

Se define como el ejercicio de la autoridad, control y toma de decisiones compartida
(planificación, monitorización y aplicación) sobre la gestión de los activos de datos.
El gobierno de los datos es una planificación y control de alto nivel sobre la gestión de
los datos.
4.8.1.1. Planificación de la gestión de datos

• Identificación las necesidades estratégicas de datos empresariales
• Desarrollo y mantenimiento de la estrategia de datos
• Establecimiento de las organizaciones profesionales de gestión de datos
• Identificación y designación de los administradores de datos
• Establecimiento de las organizaciones del gobierno y administración de los datos
90
• Desarrollo, revisión y aprobación de los procedimientos, estándares y políticas de

datos
• Revisión y aprobación de la arquitectura de los datos
• Planificación y patrocinio de los proyectos y servicios de gestión de datos
• Estimación del valor de los activos de datos y sus costes asociados
4.8.1.2. Control y supervisión de la gestión de datos

• Supervisión de las organizaciones y personal profesional de gestión de datos
• Coordinación de las actividades de gobierno de los datos
• Gestión y resolución de los problemas relacionados con los datos
• Monitorización y aseguramiento del cumplimiento regulatorio
• Comunicación, monitorización e imposición de la conformidad con las políticas de

datos, estándares, procedimientos y arquitectura
• Supervisión de los proyectos y servicios de gestión de datos
• Comunicación y promoción del valor de los activos de datos
4.8.2. Gestión del diseño, análisis y arquitectura de datos

Podemos definir la gestión de la arquitectura de los datos como el desarrollo y mante-
nimiento de la arquitectura de datos empresariales, dentro del contexto de toda la
arquitectura empresarial y su conexión con las soluciones y proyectos de sistemas
aplicativos que implementa la arquitectura empresarial.
Respecto al desarrollo o diseño de los datos podemos definirlo como las actividades en-
focadas a los datos dentro del ciclo de vida del desarrollo de sistemas (Software Develop-
ment Life Cycle, SDLC), incluyendo el modelado de los datos y el análisis de requisitos de
los datos, diseño, implementación y mantenimiento de los componentes de la solución de
datos contenidos en bases de datos.
4.8.2.1. Arquitectura de datos empresariales

• Desarrollo del modelo de datos empresariales
• Alineamiento con otros modelos de negocio
• Definición de la arquitectura de bases de datos
91
• Definición de la arquitectura de la integración de los datos y MDM
• Definición de la arquitectura de los almacenes de datos e inteligencia de negocio
• Definición de la arquitectura de metadatos
• Definición de las taxonomías y espacios de nombres empresariales
4.8.2.2. Modelado y especificación de datos

• Definición de las necesidades de información
• Desarrollo y mantenimiento de los modelos de datos lógicos
• Desarrollo y mantenimiento de los modelos de datos físicos
4.8.2.3. Gestión de la calidad del modelo de datos

• Desarrollo de los estándares de modelado de datos
• Revisión de la calidad del modelo de datos
• Gestión del versionado e integración del modelo de datos
4.8.3. Gestión de bases de datos

La gestión de las operaciones de bases de datos se define como la planificación, control
y soporte para lo activos de datos estructurados a lo largo del ciclo de vida de los da-
tos, desde la creación y adquisición hasta el archivado y purga.
4.8.3.1. Desarrollo de bases de datos

• Definición de los estándares de diseño de las bases de datos
• Diseño de las bases de datos físicas
• Revisión de la calidad del diseño de bases de datos
• Desarrollo de los servicios de acceso a los datos
• Desarrollo de los productos de información
• Implementación del desarrollo y test de cambios en bases de datos
• Creación y mantenimiento de datos de prueba
92
• Migración y conversión de datos
• Prueba y validación de requisitos de datos
4.8.3.2. Soporte a la producción de la base de datos

• Implementación de los cambios en bases de datos productivas
• Obtención de datos de fuentes externas
• Planificación de la recuperación de datos
• Realización de copias de respaldo y recuperaciones de datos
• Establecimiento de los niveles del servicio de rendimiento de bases de datos
• Monitorización y ajuste del rendimiento de las bases de datos
• Planificación de la retención de datos
• Archivo, recuperación y purgado de datos
• Gestión de bases de datos especializadas
4.8.3.3. Gestión de la tecnología de los datos

• Entendimiento de los requisitos de la tecnología de los datos
• Definición de la arquitectura de la base de datos
• Implementación y mantenimiento de los entornos de bases de datos
• Evaluación de la tecnología de datos
• Instalación y administración de la tecnología de datos
• Inventariado y realización del seguimiento de las licencias de tecnologías de datos
• Soporte al uso y problemas de tecnología de datos
4.8.4. Gestión de la seguridad de los datos

La gestión de la seguridad de los datos se define como las actividades de planificación,
implementación y control necesarias para asegurar la privacidad y confidencialidad
y prevenir accesos, creación o cambios no autorizados en los datos:
93
• Entendimiento de la privacidad de los datos y las necesidades de confidencialidad

y seguridad
• Definición de la privacidad de los datos y los estándares de confidencialidad
• Definición de los estándares y procedimientos de contraseñas
• Implementación de los controles de seguridad de los datos
• Gestión de los usuarios, contraseñas y pertenencia a grupos
• Gestión de las vistas de acceso a los datos
• Gestión de los permisos de acceso a los datos
• Monitorización del comportamiento de la autenticación y accesos de usuario
• Clasificación de confidencialidad de la información
• Auditoría de la seguridad de los datos
4.8.5. Gestión de la calidad de los datos

Se define la gestión de la calidad de los datos (Data Quality Management, DQM) como
las actividades de planificación, implementación y control que aplican técnicas de
gestión de la calidad para medir, evaluar, mejorar y asegurar la aptitud de los datos
para su uso. La gestión de la calidad de los datos comprende las siguientes actividades:
• Desarrollo y promoción de la conciencia de la calidad de los datos
• Definición de las métricas de calidad de los datos
• Definición de las reglas de negocio y requisitos de calidad de los datos
• Análisis, perfilado, medición y monitorización de la calidad de los datos
• Establecimiento de los niveles de servicio de la calidad de los datos
• Certificación de la calidad de los datos
• Identificación, escalado y resolución de las cuestiones de calidad de los datos
• Conducción de campañas de limpieza de datos
• Diseño e implementación de procedimientos operacionales de Gestión de Calidad

de los datos
94
• Monitorización de los procedimientos de DQM
• Prueba y validación de los requisitos de calidad de los datos
• Auditoría de la calidad de los datos
4.8.6. Gestión de datos maestros y de referencia

La gestión de datos maestros (Master Data Management, MDM) y de referencia se defi-
ne como las actividades de planificación, implementación y control que aseguran la
consistencia de los valores de los datos contextuales frente a una “versión de oro” de
esos valores:
• Entendimiento de las necesidades de integración de los datos maestros y de refe-

rencia
• Definición de la arquitectura de la integración de datos / MDM
• Implementación de las soluciones de gestión de datos maestros y de referencia
• Control de los valores de los códigos y otros datos de referencia
• Integración de datos maestros
• Replicación de datos maestros y de referencia
• Mantenimiento de jerarquías dimensionales.
4.8.7. Gestión de inteligencia de negocio y almacenes de datos

La gestión de la inteligencia de negocio y almacenes de datos se define como los pro-
cesos de planificación, implementación y control que proporcionan datos de apoyo
a la decisión y ayudar a los trabajadores experimentados que están involucrados en
actividades de consultas, análisis y reporte:
• Entendimiento de las necesidades de datos de inteligencia de negocio
• Definición de la arquitectura de los almacenes de datos y de la inteligencia de

negocio
• Implementación de los mercados y almacenes de datos
• Implementación de las herramientas de inteligencia de negocio e interfaces de

usuario
• Implementación del reporte empresarial
95
• Implementación de los paneles de control y cuadros de mando integrales
• Implementación de aplicaciones analíticas
• Formación a los profesionales del negocio
• Replicación y transformación de los datos para la inteligencia de negocio
• Monitorización y afinamiento de los procesos de almacenes de datos
• Apoyo a las actividades de inteligencia de negocio
• Monitorización y afinamiento las actividades de inteligencia de negocio y rendi-

miento
4.8.8. Gestión documental, de contenidos y de registros

La gestión documental, de contenidos y de registros se define como las actividades de
planificación, implementación y control para almacenar, proteger y acceder a los da-
tos encontrados dentro de los archivos electrónicos y registros físicos:
• Gestión de los documentos electrónicos (texto, gráficos, imágenes, audio y video)
• Gestión de los registros físicos (papel, fichas)
• Gestión del contenido de la información (índices de motores de búsqueda, taxono-

mías, espacios de nombres XML, reportes y estándares de formatos de documen-
tos)
4.8.9. Gestión de metadatos

La gestión de metadatos se define como las actividades de planificación, implementa-
ción y control que permiten un acceso fácil a los metadatos integrados de alta calidad:
• Entendimiento de los requisitos de los metadatos
• Definición la arquitectura de lo metadatos
• Desarrollo y mantenimiento de los estándares de metadatos
• Implementación de un entorno gestionado de metadatos
• Creación, captura, almacenamiento y mantenimiento de los metadatos
• Mantenimiento de los almacenamientos de datos fuentes de metadatos
96
• Extracción, reconciliación, integración y reparto de metadatos
• Gestión de la distribución de los metadatos y entrega a los glosarios, directorios y

otros mercados de metadatos
4.9. Conclusiones
A lo largo de esta unidad hemos comprobado cómo el dominio de la Arquitectura de la
Información resulta vital las empresas. Se trata pues de tener gestionado apropiadamente
un activo crítico para la supervivencia y desarrollo de cualquier negocio.
Esto supone una clara ventaja competitiva para todas aquellas empresas que sean capa-
ces de gestionar eficientemente la ingente cantidad de información que les llega o gene-
ran así como de extraer valor útil de la misma y en tiempo real.
En esta ardua tarea, las tecnologías nos ayudan cada vez con mejores sistemas, más ca-
paces y rápidos y a la vez más inteligentes. De esta manera somos capaces ahora de des-
cubrir incluso información oculta por medio del cruce de datos de diversas fuentes o
procedencias.
Esto último resulta muy valioso para cuestiones como procesos de mejora de la produc-
tividad, eficiencia y eficacia, descubrimiento de oportunidades de negocio, detección del
fraude, análisis de hábitos y tendencias de cliente y consumidores, detección y elimi-
nación de defectos en productos o servicios, mejora de la satisfacción de los clientes o
usuarios.
Dato importante
Según el Data Management Body of Knowledge (DMBOK), podemos definir la ges-

tión de datos como “El desarrollo, ejecución y supervisión de planes, políticas, pro-
gramas y prácticas que controlan, protegen, entregan y aumentan el valor de los
activos formados por los datos y la información”.
97
5. Desarrollo de sistemas de
e-business
“El Software de código abierto (Open Source Software, OSS) es un soft-
ware distribuido bajo una licencia que permite el acceso a su código
fuente, libre distribución, la creación de trabajos derivados y uso sin
restricciones.”
Ante la necesidad de disponer de una herramienta que nos ayude en nuestro negocio se
presentan una serie de alternativas cuya elección dependerá de las características de la
empresa (tamaño, volumen de negocio, tipo de negocio y clientes, etc.), la coyuntura de
su actual entorno tecnológico y de la visión y plan estratégico que diseñen sus directivos
acorde los siempre apretados presupuestos de TIC.
En la presente unidad se presentan los distintos enfoques existentes, desde el de cons-

truir nuestras propias soluciones hasta el adquirir soluciones de terceros (productos co-
merciales o propietarios) o la alternativa de utilizar Software libre.
Por último, nos centraremos en mostrar los distintos enfoques en la elaboración de nuestra
propia solución (Ingeniería del Software) con una introducción a los distintos enfoques o
metodologías existentes que nos permitan adaptarnos a nuestras necesidades concretas.
5.1. Alternativas: Construir, comprar, SW libre

La decisión entre construir nuestro propio Software o adquirir una solución o producto
comercial (Commercial off-the-shelf, COTS) libre va ligada a diversos factores intrínse-
cos a la propia empresa, cultura, situación financiera u objetivos. La realidad es que no
existe una única respuesta correcta para todos los casos dado lo complejo del asunto.
No obstante, un entendimiento sólido de las diferencias entre ambas y un enfoque es-

tructurado puede eliminar tanto la incertidumbre como el riesgo de esta decisión crítica.
A medida que la tecnología avanza, las opiniones al respecto han tendido a inclinar la
balanza a uno u otro lado de la decisión.
El surgimiento de sofisticadas aplicaciones altamente configurables en áreas como ERP,

recursos humanos, finanzas y administración, CAD, CRM, Inteligencia de Negocio y al-
macenes de datos han estimulado la popularidad de las soluciones comerciales (“paque-
tizadas”).
98
Recientemente, el grupo Gartner ha reportado una tendencia creciente hacia la construc-

ción de herramientas Software. Esto es debido a diversas razones:
• El impacto que tienen las nuevas tecnologías y la disponibilidad de expertos desa-

rrolladores en el mercado
• El reconocimiento de que las soluciones comerciales son demasiado pesadas, es-

tán infladas y resultan caras
• La necesidad de adaptar los modelos exclusivos del negocio y las idiosincrasias

propias de las organizaciones
Para multitud de aplicaciones la línea entre construir y comprar ha resultado ser muy
borrosa. A menudo, las aplicaciones a medida se crean por medio de la integración de
componentes estándares y las aplicaciones comerciales necesitan de una completa confi-
guración y una posterior integración.
La construcción de aplicaciones a medida es hoy en día más un proceso de ensamblaje

que de construcción. La distinción es a menudo una cuestión de grado.
En esta sección vamos a tratar de presentar un paradigma para la toma de decisión es-
tructurada que tome en cuenta tanto la naturaleza de la organización, sus procesos, el
entorno tecnológico y el estado de las soluciones comerciales y sus fabricantes.
Con todas estas variables creemos que supone disponer de bastante información para
permitir tomar una decisión informada a la dirección.
A continuación presentaremos un conjunto de criterios de decisión, discutiremos las dife-

rencias intrínsecas entre las soluciones comerciales y las “a medida” y finalmente presen-
taremos un proceso estructurado de decisión.
5.1.1. Criterios de decisión

Cualquier modelo que podamos tener en cuenta para la decisión entre la construcción o
la compra ha de tener en cuenta los siguientes factores:
• Principal (Core) vs Contexto
• Cobertura
• Dirección
• Coste Total de la propiedad (Total Cost of Ownership, TCO)
• Escala
99
• Tiempos
• Estándares
5.1.1.1. Principal vs Contexto

El primer criterio es la significancia estratégica de la aplicación. Las aplicaciones que no
impactan la naturaleza única del negocio raramente garantizan la atención que las solu-
ciones a medida demandan.
Muy pocas organizaciones considerarían soluciones de Software a medida para recursos

humanos, contabilidad, gestión de nóminas o impuestos o de gestión de la cadena de
suministro por nombrar algunas actividades generales.
No obstante, cabe decir que algunas de las actividades generales anteriormente expuestas
resultan ser de hecho el núcleo central de las actividades de negocio de otras empresas.
Esto es, las actividades principales o nucleares son aquellas que contribuyen directamen-
te a la diferenciación de la organización y a la creación de valor. El contexto es el resto de
actividades.
Es precisamente en las áreas básicas donde una organización obtiene la ventaja compe-
titiva y donde los sistemas de información deben adaptarse a los procesos de negocio y
no al revés.
El siguiente cuadro nos indica dónde obtienen las organizaciones el mayor efecto palanca
y la ventaja competitiva por medio de la inversión de recursos financieros e intelectuales.
Principal Contexto
(Comprometerse) (Desentenderse)
Misión Crítica (Controlar) Construir Externalizar
Soporte (Confiar) Asociarse Contratar
Matriz de decisión Construir vs Comprar
Las actividades básicas de misión crítica son las que tienen mayor prioridad y merecen
la mayor atención. Cuando se evalúa la decisión de construir frente a comprar, el conoci-
miento de si una actividad en particular es principal o de contexto nos sugiere si es apro-
piado considerar el modificar las prácticas de negocio para ajustaros a las restricciones
de un paquete comercial o si por el contrario es necesario mantener un control directo.
100
5.1.1.2. Cobertura
La cobertura evalúa cómo de cercano está el ajuste entre lo que el negocio requiere y lo
que la solución empaquetada proporciona.
La tradicional regla de oro es que las soluciones comerciales deben cumplir un mínimo
de un 80% de las funcionalidades requeridas. Desafortunadamente esto supone ser una
simplificación exagerada.
No es suficiente determinar sólo si un paquete cumple todos los requisitos. Es igualmente

importante determinar si el paquete proporciona las capacidades que están fuera de los
requisitos.
Cada característica, cada función, cada capacidad representa un coste y complejidad adi-
cional y se traducen inevitablemente en costes y complicaciones futuras. Así como no es
muy acertado considerar un paquete que no cubra el 80% de las necesidades conocidas
de manera similar no es inteligente considerar uno en el cual los requisitos conocidos
representan menos del 80% de las capacidades del paquete.
Una trampa habitual en la que se cae es basar la valoración de la solución COTS úni-
camente en las características que ofrece. Este enfoque que utiliza una lista de compro-
bación de características ofrece un mecanismo sencillo de comparación entre distintas
alternativas de soluciones, pero le falta una dimensión clave que es el ajuste al proceso de
negocio. Las listas de características raramente reflejan las características dinámicas del
método y el proceso.
Los requisitos deben compararse desde la perspectiva del proceso de negocio y no exclu-
sivamente desde las características y funciones. Una de las mayores fuentes de problemas
que se encuentra en el camino es la dependencia en la carga de especificaciones técnicas.
Con demasiada frecuencia los paquetes satisfacen los requisitos funcionales pero no pro-
porcionan una solución consistente con los procesos de negocio de las organizaciones. O
al contrario. Una solución potencial se descarta porque no es ajusta a una lista de caracte-
rísticas exhaustiva, pero podría haber sido excelente para el proceso de negocio.
5.1.1.3. Dirección
Durante el proceso de evaluación de la solución comercial o COTS la preocupación debe
ser no sólo lo bien que los requisitos actuales son cubiertos sino también cómo de flexible,
fácil de mantener y extensible será la aplicación a lo largo de su ciclo de vida.
Esto resulta especialmente importante para aplicaciones que están destinadas a tener
una larga vida útil dado que muchos de sus requisitos están pendientes de ser imagina-
dos por no hablar de definidos.
101
Cuando se considera la dirección, se debe tomar en cuenta cuánto control tendrá la orga-
nización sobre la elaboración y la expansión de nuevas características deseadas aunque
todavía desconocidas.
La consideración de la dirección se aplica de igual manera a las funciones de la aplicación

y a las tecnologías de las plataformas. Ambas deben ser consideradas con cuidado.
Tanto la arquitectura, tecnología como los métodos de integración influyen en la direc-

ción a largo plazo y la evolución del paquete. Suponen en fin una serie de indicadores
clave que indican dónde estará el paquete, por cuanto tiempo se espera que continúe me-
jorando y consecuentemente cuál es la probabilidad de que la solución continúe siendo
una buena opción en el futuro.
5.1.1.4. Coste Total de la Propiedad (TCO)

El TCO incluye no sólo el coste de adquisición, configuración y personalización, sino tam-
bién el soporte continuo, mantenimiento y evolución de la aplicación. Resulta habitual
que los costes a lo largo de una vida superen a los costes de adquisición.
Posiblemente podamos afirmar que la determinación más importante en el cálculo del

TCO sea una estimación de la vida económica anticipada de la aplicación. El TCO debe
tomar en cuenta también los costes fijos asociados con dominar la gestión de tanto la
estructura como la tecnología subyacente de una solución empaquetada.
Las soluciones a medida requieren una disponibilidad continua de recursos de desarrollo,

ya sean internos o a través de proveedores para poder responder a los cambiantes requi-
sitos.
De manera similar, las soluciones comerciales requieren recursos para probar, validar,
integrar y soportar las nuevas entregas del fabricante. El grado de esfuerzo es altamente
dependiente de la naturaleza misma de la aplicación.
Normalmente, las soluciones comerciales sufren de una mucha mayor volatilidad, que es
su tendencia a cambiar más frecuentemente y de forma más dramática y a la vez un ciclo
económico mucho más corto.
Comprar una solución que tiene multitud de capacidades que uno no necesita es una
mala idea. De una manera u otra, uno termina pagando por la complejidad, en términos
de formación, integración, configuración, mantenimiento, soporte o cualquiera de una
pléyade de factores influyen sobre los costes a largo plazo.
Más allá del impacto económico, el fabricante estará revisando, mejorando y expandiendo
todas esas características también. Si el paquete hace mucho más de lo que uno quiere y
necesita, entonces es probable que esté enfocado a servir a otra audiencia distinta y que
tus requisitos tienen una alta probabilidad que diverjan con el tiempo.
102
5.1.1.5. Escala
Cuanto más grande sea la escala de la aplicación más importante es que represente las
funciones núcleo del negocio. De manera práctica se ha comprobado que mucha de la
grandes soluciones ERP integradas tienen unos costes fijos de soporte tan grandes que
no resulta razonable o apropiado considerar la implementación únicamente de un peque-
ño conjunto del paquete completo.
Por ello, la escala se vuelve un factor importante en la medida y en última instancia para
la mitigación del riesgo del proyecto. El proceso de decisión debe incluir tanto la compa-
rativa de costes como de riesgos para que se puedan tomar decisiones informadas.
5.1.1.6. Tiempos
La sabiduría popular sostiene que implementar una solución comercial es más rápido que
un desarrollo a medida. Como cabría esperar esto se trata de una simplificación extre-
ma. El proceso de instalación, configuración, personalización y completar la conversión
de datos para las soluciones comerciales de manera rutinaria implica tareas que son tan
complejas y extensas como un desarrollo a medida con mucha menos flexibilidad en las
fases y tiempos disponibles. Los paquetes COTS pueden ofrecer una mayor predictibili-
dad con respecto al tiempo de implementación, pero esa es en gran medida un reflejo de
las restricciones que se imponen en cuanto a capacidades y flexibilidad.
El mayor riesgo de los tiempos en los desarrollos a medida es la dificultad que las organi-
zaciones tienen para controlar el proceso de requisitos y permitir que ocurra una inunda-
ción de características.
Cuanto mayor sea el grado en el cual la organización pueda aceptar un proceso de nego-
cio predefinido, más simple será la implementación. Si un paquete puede ser empleado
como viene sin ninguna adaptación a los procesos y prácticas de negocio de la organiza-
ción entonces tendrá una ventaja sustancial sobre una implementación a medida.
Tan pronto como se necesita una configuración o modificación de un proceso de negocio

la solución comercial deja de tener ninguna ventaja significativa con respecto al tiempo.
Simplemente se produce un intercambio entre tipos de actividades.
5.1.1.7. Estándares
Los estándares puede que sean el criterio más importante de todos. Los fabricantes de
COTS venden la idea de que los costes del desarrollo Software se pueden repartir entre
una gran comunidad de usuarios y por lo tanto reducir el coste para cada cliente indivi-
dual. Para que sea cierta esta promesa se necesita que haya alguna fuerza externa que
asegure la consistencia de una gran porción de los requisitos.
103
Ejemplos habituales de tales fuerza son los estándares legislativos (leyes impositivas,
regulaciones de contabilidad), naturaleza (por ejemplo Software para realizar simulacio-
nes), estándares de la industria (los estándares HTML permiten que los navegadores co-
merciales existan, estándares ISO) o grupos de industria poderosos (FIX para transaccio-
nes financieras, EDI y otros).
Los estándares también pueden surgir directamente desde el éxito de un paquete en par-
ticular en áreas donde las organizaciones probablemente vean la función como “contexto”
y no “núcleo”. Aplicaciones de productividad personal en oficina (procesamiento de tex-
tos, hojas de cálculo, clientes de correo,…) son unos buenos ejemplos.
Las herramientas y componentes también recaen en esta categoría. Por ejemplo, pocas
organizaciones podrían pensar en desarrollar su propia tecnología de bases de datos, sis-
tema de paso de mensajes o sistema operativo.
En ausencia de una poderosa fuerza exterior que defina contenido consistente, es bastan-
te cierto pensar que las soluciones COTS:
• Tenderán a divergir con el tiempo y que la evolución de las funcionalidades dejará

de suponer una buena opción
• El TCO crecerá con el paquete y los requisitos de negocio
• Lo peor de todo es que los usuarios de negocio descubran que no pueden asegurar
que la evolución del Software pueda responder a sus requisitos de procesos de ne-
gocio, en especial para las actividades consideradas principales
5.1.2. Diferencias entre alternativas

Mientras que la decisión nos ayuda a evaluar el ajuste necesitamos considerar también
las diferencias inherentes entre las soluciones a medida y las comerciales. Estas diferen-
cias son las siguientes, de las que desarrollamos las tres primeras:
• Ciclo de vida económico
• Volatilidad
• Procesos de negocio
• Tiempos
• Control
104
5.1.2.1. Ciclo de vida económico

Las soluciones a medida normalmente tienen una vida económica sustancialmente más
larga que los paquetes comerciales o soluciones COTS.
Existen dos factores que contribuyen a que esta diferencia sea hasta tres veces mayor: la
complejidad que conlleva tener que cumplir con requisitos muy dispares y la presión que
sufren de tener que emplear las últimas tecnologías:
• Complejidad: El Software tiene la desafortunada característica que cuanto más

complejo sea, más difícil resulta expandirlo, modificarlo o darle soporte. Las so-
luciones COT son la víctima de su propio éxito, ya que más clientes suponen ma-
yor diversidad de requisitos. La complejidad necesaria para sostener la diversidad
acorta el tiempo en el cual se puede dar respuesta a las necesidades evolutivas
porque se vuelve muy difícil de mejorar. No es raro que las soluciones comerciales
tengan un modelo de datos con muchas más tablas que una solución a medida.
• Tecnología: Los nuevos clientes de paquetes comerciales demandan que esas so-
luciones se implementen usando las más modernas y grandes tecnologías. Esto
no es poco razonable ya que los clientes buscan nueva y avanzadas soluciones.
Sin embargo, las plataformas tecnológicas son útiles por un tiempo mayor de lo
que son populares. Ninguna organización elegiría emplear una aplicación basada
en COBOL y sin embargo los grandes sistemas en distintos sectores continuar
funcionando a la perfección con ellos. El resultado de todo esto es mayor presión
para los fabricantes de COTS para que migren a nuevas tecnologías más rápido de
lo que los sistemas subyacentes lo hacen. Si no lo hacen, se vuelven poco compe-
titivos. Por lo tanto, es el requisito del siguiente cliente el que marca las acciones
de los fabricantes de soluciones comerciales más que las necesidades de su base
de usuarios actual.
La combinación de una complejidad creciente y migración de tecnología resulta en una

vida económica de las soluciones comerciales que es una tercera parte o incluso la mitad
de la que es de esperar para las soluciones a medida. Es bastante frecuente encontrar que
soluciones a medida se mantienen altamente productivas diez, quince o veinte años des-
pués de su implementación.
5.1.2.2. Volatilidad
Por volatilidad entendemos la frecuencia y complejidad de las nuevas entregas de versio-
nes. Una mayor volatilidad significa unos mayores costes de soporte y mantenimiento,
dado que una característica habitual de las soluciones comerciales es que los clientes
deben probar, integrar e instalar cada versión, tanto si contiene mejoras deseadas como
si no.
105
Cada nueva versión presenta un riesgo sustancial de la estabilidad y disponibilidad del

sistema para los usuarios. La carga de validar el contenido, probando las soluciones a
medida por el contrario sólo se ve afectada como respuesta a las peticiones de usuario o
cambios en el entorno del cliente.
5.1.2.3. Procesos de negocio

A pesar de que los fabricantes de soluciones comerciales se afanan en proclamar que sus
productos ofrecen una flexibilidad total en configuración para ajustarse a los procesos de
negocio existentes esto raramente suele ser cierto.
Por el contrario, las organizaciones cliente son urgidas a modificar sus prácticas de nego-
cio para ajustarse al rango de alternativas que el paquete ofrece. Esta restricción resulta
esencial para evitar que el paquete crezca hasta convertirse en inmanejablemente com-
plejo.
En la práctica, esto no supone un problema dado que uno de los factores de elección de
una solución comercial es el deseo de realizar una re-ingeniería de los procesos actuales
de negocio
5.1.3. Proceso de decisión

El proceso de decisión que nos ocupa de decidir si “construir” o “comprar” trata de en-
tender las necesidades de negocio y eliminar las soluciones candidatas que no consigan
cumplir esas necesidades.
Las alternativas que sobrevivan durante este proceso, que son consideradas todas como
aceptables, se comparan en términos de riesgo y coste. Para lograr esto se emplea un
proceso compuesto por seis etapas:
• Evaluar la tendencia o sesgo de la organización
• Determinar lo básico y lo contextual
• Documentar los requisitos basados en escenarios
• Revisar las soluciones comerciales candidatas
• Desarrollar estimaciones TCO para las mejores alternativas
• Preparar matriz de riesgo/mitigación
106
5.1.3.1. Evaluar la tendencia o sesgo de la organización

Se comienza por esta etapa debido a que todas las organizaciones adolecen de una ten-
dencia innata hacia tanto una solución COTS como una a medida. Esa predisposición
debería estar reconocida y estar entendidas sus razones para que éstas puedan ser ges-
tionadas directamente. La posición puede estar bien fundada o estar basada en pasadas
experiencias que puede que hayan perdido su validez.
Si el sesgo organizativo no se entiende ni se hace explícito, el equipo de evaluación puede

malgastar un tiempo y esfuerzo valioso y no ser capaces de proporcionar la información
que se necesita para llegar a una conclusión razonada.
5.1.3.2. Determinar lo básico y lo contextual

Resulta bastante frecuente que las organizaciones no tengan claro esta área o que se con-
fundan los procesos de negocio tradicionales con los estratégicamente significativos.
Dado que la elección de una solución COTS casi con total seguridad resultará en una
transición de los procesos actuales a los que soporte el paquete aplicativo (al menos al
nivel de detalle) es extremadamente importante mejorar en el entendimiento de la impor-
tancia estratégica de los procesos de negocio que la aplicación apoyará.
Existen numerosas evidencias para inclinarnos hacia una solución COTS para activida-
des de contexto y una solución a medida para actividades principales estratégicas.
5.1.3.3. Documentar los requisitos basados en escenarios

Resulta una tendencia muy poderosa del uso de requisitos basados en escenarios propor-
cionados por los requisitos funcionales allá donde sea posible.
Este enfoque (llamado casos de uso en Unified Modelling Language, UML) asegura que
la solución elegida cumplirá con los objetivos de negocio. Los requisitos que están limi-
tados a una especificación funcional pierden todos los aspectos dinámicos del uso de un
sistema.
En esta etapa del proceso resulta útil enfocar el proceso como si se fuera a construir todo,
documentando lo que se quiere y necesita de forma que permita a un equipo de desarrollo
entender qué es lo que van a construir.
Es conveniente evitar las características y funciones de prioridad simple y mantenerse

firme en los requisitos basados en escenarios proporcionados por las necesidades no-
funcionales de alto nivel (como seguridad, disponibilidad, acceso,…).
107
5.1.3.4. Revisar las soluciones comerciales candidatas

En esta etapa es donde el grueso del trabajo se realiza. Es necesario concentrarse tanto
en la cobertura y dirección dado que se necesita estar seguro que el paquete cumplirá no
sólo con las actuales necesidades sino también con las futuras.
Cuando se evalúa la cobertura, se considera la regla del 80% en ambas direcciones tanto lo
que entra como lo que sale. Un paquete se considera no apropiado cuando:
• No cumple con el 80% de tus necesidades
• Tus necesidades representan menos del 80% de lo que ofrece el paquete
Por último, la conveniencia debe ser medida también en los dominios no funcionales. La
tecnología subyacente, prácticas de soporte, frecuencia de versiones y actualizaciones,
herramientas de integración y capacidades son algunas de las que están entre las caracte-
rísticas que merece la pena evaluar.
5.1.3.5. Desarrollar estimaciones TCO para las mejores alternativas

La fase económica de la determinación requiere un entendimiento sólido del coste total
de la propiedad y no simplemente del coste de adquisición, configuración e implementa-
ción.
El cálculo del TCO necesita tomar en consideración los costes iniciales así como la vida
económica y la volatilidad del paquete. Las preguntas sería del orden: ¿Cómo de amplio
es su ciclo de vida? ¿Con qué frecuencia salen a la luz nuevas versiones? ¿Es obligatorio
probar, integrar, instalar y soportar cada una de esas versiones?
Es frecuente que la soluciones comerciales tengan uno costes de soportes fijos muy gran-
des, muchos de los cuales no se tratan durante el ciclo de venta y no son visibles hasta
muy adentrada la fase de implementación.
Por ejemplo, las soluciones que implican una configuración sustancial pueden requerir
unos esfuerzos complejos y costosos para mantener el control de la configuración dado
que evoluciona con el tiempo.
La incertidumbre que a menudo se asocia con el coste de adquisición de una solución a

medida puede ser eclipsada por la incertidumbre y magnitud de los costes de por vida de
una solución comercial.
108
Dato importante
Es frecuente que la soluciones comerciales tengan uno costes de soportes fijos muy
grandes, muchos de los cuales no se tratan durante el ciclo de venta y no son visibles
hasta muy adentrada la fase de implementación.
5.1.3.6. Preparar matriz de riesgo / mitigación

Todos los proyectos implican riesgo, alguno menos y otros más. Cada una de las alterna-
tivas aceptables debería ser el objeto de una revisión detallada del riesgo y la mitigación.
Con este proceso se puede descubrir por ejemplo que la alternativa “construir” puede
ser despiezada en fases más pequeñas que reducirá el riesgo de una implementación en
“Big Bang” y proporcionar a la organización tiempo para adaptarse a los nuevos y más
eficientes procesos.
Las organizaciones se enfrentan al dilema de construir frente a comprar cada vez que se
fijan en las tecnologías de la información para ganar en eficiencia, mejorar la productivi-
dad o mejorar su ventaja competitiva. Entender las diferencias entre los dos enfoques y
abrazando un proceso de toma de decisiones estructurado y disciplinado puede reportar
grandes beneficios.
Comprar (Solución
Construir (Desarrollo
basada en mejores
Elemento de Coste a medida) Escenario
prácticas) Escenario
de riesgo
de riesgo
Licenciamiento y/o
ALTO BAJO
Desarrollo
Configuración inicial /
MODERADO MODERADO
Integración
Configuración inicial /
BAJO A MODERADO BAJO A MODERADO
Formación
Tasas anuales ALTO BAJO
RANKING GLOBAL DEL

MODERADO A ALTO BAJO A MODERADO
RIESGO
Ejemplo de matriz de riesgo para un caso concreto
109
5.1.4. Software Libre: la tercera vía

El Software de código abierto (Open Source Software, OSS) es un software distribuido
bajo una licencia que permite el acceso a su código fuente, libre distribución, la creación
de trabajos derivados y uso sin restricciones.
La historia del OSS se remonta al grupo de usuario compartido de los años 50, la distribu-
ción académica de Unix y el proyecto GNU.
Las aplicaciones OSS abarcan la mayoría de áreas de software de consumo y de negocio.

Áreas destacadas de aplicación incluyen las infraestructuras de sistemas como sistemas
operativos y bases de datos, desarrollo de Software, productividad personal, escritorio, en-
tretenimiento, gráficos, edición, educación, científicas, ingeniería, gestión de contenidos
y Software de negocios.
La organización de los proyectos de desarrollo OSS difiere de los proyectos propietarios

en términos de su estructura organizativa, membresía, liderazgo, políticas de contribu-
ción y control de calidad. Las operaciones rápidas, distribuidas y a menudo informales
hacen más fácil comenzar o participar en un proyecto OSS, sin embargo el aislamiento de
estos proyectos de las presiones del mercado real hace que muchos languidezcan.
Detrás de un proyecto OSS exitoso reside una comunidad. Sus actores van desde desarro-
lladores del núcleo a usuarios pasivos. Aunque la estructura del gobierno de una comu-
nidad es normalmente flexible, muchos procesos y mecanismos de comunicación y coo-
peración son normalmente más importantes que en el desarrollo de Software de negocio.
El elemento clave que define OSS es su licenciamiento, que debe satisfacer una lista im-
portante de requisitos. Existen una multitud de licencias de código abierto y difieren en
cómo tratan el Software resultante: algunas contienen restricciones que obligan a su dis-
ponibilidad en forma de código abierto, mientras que otras permiten mayor flexibilidad.
La selección de una licencia apropiada para un nuevo proyecto OSS resulta importante
antes de incorporarlo en un sistema propietario.
Hoy en día muchos modelos de negocio confían en OSS. Tanto como producto como a
través de la provisión de servicios asociados. Los ingresos se pueden obtener comple-
mentando un producto propietario con uno de código abierto, soporte y formación, sus-
cripciones y publicidad.
Las dimensiones estratégicas detrás de un movimiento hacia OSS incluyen no sólo las
oportunidades relacionadas con el marketing o la innovación, sino también los riesgos
asociados con la pérdida de beneficios y la reducción de barreras a la competencia.
110
A un nivel táctico, un modelo de negocio basado en OSS puede reducir los costes de
desarrollo, permitir la personalización al usuario final pero también demandará nuevas
estructuras organizativas, una inversión a corto plazo mayor y el continuo fomento de un
ecosistema de código abierto.
OSS se puede reusar como un producto (de bajo coste), como un componente adaptable o
como código y otros elementos que se son transformados en otro sistema.
De manera creciente, los sistemas OSS forman completas pilas usadas como infraestruc-
tura por otras aplicaciones. En categorías específicas, tales como aplicaciones Web, el ni-
vel de adopción de OSS es similar o incluso supera a la oferta de soluciones comerciales.
Los impactos y efectos de la adopción de OSS afectan a la línea de flotación de una orga-
nización, su gestión, la calidad del Software y el proceso de desarrollo de Software.
Una cuestión muy repetida se refiere a la motivación que hay detrás de la motivación de
tanto individuos como organizaciones para participar en proyectos OSS. Los incentivos
para los individuos pueden ser sociales, políticos, ideológicos, hedonísticos así como el
atractivo de un entorno tecnológico flexible, libre de estrés y de última generación. Las
empresas parecen ganar de su participación a través de un acceso privilegiado a un pro-
ducto de alta calidad y su proceso de desarrollo así como la exposición a la innovación
dirigida por usuarios, mayor reputación y visibilidad, mejora del capital humano y mejora
de la moral de los empleados.
La aparición de OSS está impulsando la economía en su conjunto por medio de su amplia

aceptación como una alternativa barata a los caros productos comerciales y como con-
ductor detrás de muchos proyectos exitosos de e-business.
El OSS está también afectando directamente sectores específicos:
• La industria de desarrollo de Software a través de la competencia y nuevas oportu-

nidades de negocio.
• El desarrollo de Hardware por medio de menores costes y barreras de entrada.
• La innovación dirigida por el consumidor y las dificultades de aplicación de polí-

ticas.
• El mundo académico a través de valiosas oportunidades para investigación y la

implicación de los estudiantes en aplicaciones del mundo real así como la disponi-
bilidad de herramientas de Software y la posibilidad de prestar de cursos pioneros.
El futuro de OSS parece ser tan excitante como su pasado. Puede llevar a nuevos modelos
de diseño, producción, publicidad y negocio así como a formas de desarrollar grandes y
complejos sistemas Software de manera orgánica.
111
Los desafíos están ahí delante y los problemas aun por superar por lo que el potencial
para la investigación futura sobre OSS es enorme.
Por ejemplo, la comparación entre los productos comerciales y OSS es todavía un área
que adolece de una falta de evidencias empíricas. Resulta más importante es la habilidad
de los modelos de desarrollo OSS para democratizar la tecnología y la innovación.
5.1.4.1. OSS vs Propietario (soluciones comerciales)

Existen varios factores que destacan las diferencias entre proyectos de software comercia-
les y OSS. A continuación comparamos los dos desde las siguientes perspectivas:
• Comunidad: Los temas importantes para las comunidades que se forman alrede-
dor de los proyectos, los diferentes actores, la motivación y afiliación y los procesos
de decisión.
• Producción de Software: Cómo se gestionan los cambios de código, los procesos

de pruebas que se siguen, los enfoques de gestión de entregas y el entorno técnico
y de infraestructuras.
• Temas de Negocio: Los relevantes a licenciamiento, modelos de negocio y deci-

siones y cómo se fomenta la reutilización de objetos del proyecto.
Las tres siguientes tablas resumen a nivel general algunos factores diferenciadores que
están bajo alguna de las categorías comentadas, aunque hay que comentar que existen
excepciones que no tienen por qué estar representadas en las mismas.
TABLA 1: Comunidades
Proyectos OSS Proyectos Propietario
Participación voluntaria sustancial Plantilla de pago
Alto número Nº limitado
Afiliación Abierto a todos, voluntario Cerrado (empresa)
Límites virtuales Fluidez Independencia Limitado por contratos
Comunidad Pertenencia a la compañía
Desarrolladores principales o líder de

proyectos Compañía / Organización
Toma de decisiones Sin estructura formal, votaciones Estructura rígida y estricta

consensuadas
Control centralizado
Meritocracia distribuída
112
Intrínseca y extrínseca
Motivación Recompensa monetaria o de carrera
Social / política
Empleados de empresa
Altamente formados y motivados
Ocupación principal a tiempo com-
Sacrifican parte de su tiempo a pleto
Actores proyectos
No hay usuarios involucrados
Desarrolladores y usuarios
Diferencias encontradas entre proyectos OSS y propietarios de SW: Comunidades
TABLA 2: Producción de Software
Mayormente centralizado en una o pocas

Descentralizado y geográficamente distribuído localizaciones
Infrecuentes comunicaciones cara a cara, Frecuentes comunicaciones y reuniones cara

medios asíncronos a cara
Escasez de planes de proyecto o planificaciones Plan del proyecto y cronograma
Trabajos y tareas sin asignar, participación y Asignación de trabajo y coordinación por

selección voluntaria líderes de proyecto
Entorno Desarrollos paralelos masivos Equipos de menor tamaño
No eixste diseño explícito de nivel de sistema Procesos de diseño rigurosos
No existe lista de entregables Estrictas guías de desarrollo
Proceso y código abierto a todos Comunicaciones cerradas
Selección de tareas basada en la experiencia e Desarrolladores formados y asignados

intereses de los desarrolladores determinadas tareas
Implementación y envío de parches antes de la Cambios a nivel de documentación y revisión

Gestión del Cambio revisión final antes de implementación
Formal, informes
Informal
Por medio de probadores, ingenieros de

Revisión de pares asegurameinto de calidad (QA)
Proceso de pruebas
Participación de la comunidad y usuarios Dentro de la compañía u organización
Fuerte implicación de la comunidad después de Casi completo antes de la versión (o durante

la entrega las pruebas beta)
Versiones frecuentes de pequeñas mejoras, sin

fechas fijas Pocas versiones grandes en fechas fijas
Gestión de versiones Promoción y publicidad mínimos Promocion y publicidad
Escasez de documetación y soporte técnico Domuntación y soporte técnico formal

basado en la comunidad
Diferencias encontradas entre proyectos OSS y propietarios de SW: Producción de SW

113
TABLA 3: Negocio

Algunas versiones de licenciamiento Licencia propietaria, copyright
Copyleft
Licenciamiento
SW vendido a un coste
Sin coste de adquisición de SW
Empaquetado de valor añadido
Servicios y Soporte
Artículo cebo Producto, servicio o híbrido

Modelos de negocio
Componente embebido Licenciamiento, royalties, mantenimiento
Complemento con accesorios
Licenciamiento dual
Adopción / Permitido a todos los niveles, basa- Incorporación y soporte de elementos de

Reutilización do en una licencia específica procesos de producción reutilizados
Diferencias encontradas entre proyectos OSS y propietarios de SW: Negocio
El Software propietario (comercial) y el OSS son los dos extremos de un amplio abanico
de enfoques potenciales. El resultado es que han surgido una variedad de modelos hí-
bridos que abarcan elementos de ambos. El objetivo de estos modelos es capitalizar los
puntos fuertes que cada perspectiva ofrece.
Normalmente, los proyectos de Software comercial propietarios se caracterizan por:
• Un fuerte énfasis en la obtención de requisitos de los usuarios
• Diseño de fases
• Documentación rigurosa
• Estrictos procesos de planificación y valoración
• Soporte técnico de alto nivel a la base de usuarios
• Mecanismos de negocio que facilitan una adecuada rentabilidad
114
Por otro lado, los proyectos OSS están mayormente caracterizados por:
• Procesos abiertos
• Comunidades fluidas y auto-organizadas basadas en comunicación abierta
• Cultura de desarrollo que rezuma colaboración, auto asignación de áreas y revisión

entre pares, participación de la base de usuarios en el proyecto y versiones frecuen-
tes para reflejar los resultados de diferentes tareas de desarrollo llevadas a cabo por
grupos independientes de desarrolladores.
Ciclo de desarrollo de SW típico de un proyecto OSS
5.1.4.2. Licenciamiento
El Software de código abierto puede ser usado libremente, modificado o distribuido, si
bien existen ciertas restricciones con respecto a los derechos de autor (Copyright) y la
protección de su estatus como OSS.
Estos derechos y restricciones se expresan a través de la licencia de Software, por ejemplo

mediante un contrato entre el propietario de un Software y sus posibles usuarios. Las
licencias OSS tienen distintas variedades, pero normalmente permiten la disponibilidad
del código fuente del Software y permiten la creación de trabajos derivados así como la
explotación comercial no exclusiva de tanto el original como sus derivados.
El emisor de la licencia de un Software OSS (normalmente el propietario o el autor) pue-

de ser un desarrollador independiente, un grupo de desarrolladores o una organización
y mantiene los derechos de autor del Software. Evaluando y combinando factores tales
115
como las motivaciones detrás del trabajo, las características del proyecto, su público obje-
tivo y su probabilidad de éxito el emisor de licencia decide si pone su trabajo disponible
bajo una licencia de código abierto y el tipo de licencia a emplear.
El titular de la licencia por otro lado es o un usuario del OSS o alguien que lo ha embebido
en su producto o aplicación que es después distribuida o licenciada.
Conceptos y Definiciones
Antes de repasar los distintos tipos de licencias OSS, es necesario introducir una serie de
conceptos de fondo que delimitan los grados de libertad disponibles cuando se distribuye
un producto de cualquier actividad intelectual, incluido el Software.
1. Propiedad Intelectual, Derechos de autor y patentes
• Propiedad Intelectual: Este término se emplea para abarcar un amplio rango de

áreas de la ley, incluyendo derechos de autor, patentes e incluso marcas. Todos
estos son medios que se emplean para fomentar las inversiones privadas en in-
vestigación, tecnología e innovación por medio de asegurar que los innovadores
podrán obtener beneficios de su trabajo.
• Derechos de autor: Es una forma de protección legal que se puede aplicar a una
amplia gama de trabajos intelectuales, incluido el Software. A menudo el Software
protegido de esta manera no permite acceso al código fuente y se distribuye con
un acuerdo de licencia que restringe su copia, modificación o su posterior distri-
bución. No obstante, los autores del Software pueden decidir publicar el código
fuente por medio de una licencia de Software que transmite los derechos a quienes
acceden al mismo.
• Patentes: Son descripciones por escrito de invenciones, usadas como reclamos de

propiedad de las ideas principales y su uso, para que solamente los inventores pue-
dan obtener un retorno económico por ellas. Las patentes constituyen permisos de
uso de una idea, concedidos a los autores por un período limitado de tiempo. La
solicitud de una patente es un proceso que puede llevar años e implica una inver-
sión financiera significativa.
Dado que el código Software se puede copiar y reproducir fácilmente, muchas empresas
abogan fuertemente por la protección sus derechos de autor y patentes.
Sin embargo, otros expresan sus preocupaciones sobre tales protecciones, afirmando que
la comunidad de Software y la sociedad en general se beneficia en menor medida con este
enfoque restrictivo, con respecto a mantener el conocimiento que los innovadores han
creado de manera gratuita y disponible para todos.
116
En particular, la fundación para el Software Libre (Free Software Foundation, FSF), una
organización sin ánimo de lucro, afirma que el uso de patentes socava severamente el
movimiento de Software libre. La preocupación del FSF y de otros miembros de la comu-
nidad OSS es que los proyectos OSS carecen de los recursos financieros e institucionales
necesarios para investigar posibles obras anteriormente patentadas que puedan ser inva-
didas su trabajo y para defenderse de contra litigios de patentes, que son notoriamente
costosos.
Más aún, existen diferencias más que significativas entre los distintos países en materia
de ley sobre patentes, especialmente para Software lo que implica una dificultad adicional
para un proyecto OSS global típico.
En general se critica una excesiva protección en materia de patentes a través de muchos

campos científicos y tecnológicos ya que puede impedir el desarrollo de la investigación
científica y hacer que el acceso a recursos críticos (como medicinas) sea más difícil o
costoso.
2. Dominio Público
En contraposición al Software patentado, los modelos colaborativos permiten que varios

miembros participen en un proyecto o un esfuerzo de desarrollo. Los proyectos OSS son
ejemplos característicos de esto. Se renuncia al control del conocimiento, innovación o en
este caso el código fuente y se convierten en bienes de dominio público.
Etiquetar el Software como de dominio público por parte del propietario o autor significa
que se declara que no existe una protección de derechos de autor y que no existen tampo-
co restricciones de licenciamiento o distribución.
Cualquiera es libre de copiar, modificar, distribuir o vender el Software, sin necesidad de

permisos. Incluso si hay partes de un Software de dominio público que se incorporan en
un trabajo protegido por derechos de autor, entonces las copias del material estará cubier-
ta por los derechos de autor pero el trabajo original permanece de dominio público, libre
y disponible por todos.
Existe un concepto erróneo de equiparar OSS con Software de dominio público. OSS no
es Software de dominio público. OSS tiene los derechos de autor protegidos y es distribui-
do bajo una licencia, lo único es que la misma concede a los usuarios mayores permisos
de los que normalmente están acostumbrados.
3. Código abierto y Libertad de derechos de autor (Copyleft)
El código abierto reside entre el permitir que un Software sea totalmente de dominio
público (y por lo tanto renunciando a cualquier noción de propiedad) y el protegerlo bajo
derechos de autor y una ley de patentes. Todas las licencias OSS comparten dos caracte-
rísticas:
117
• Renuncian a los derechos de licencias por la distribución del Software.
• Incorporan la condición de que el código fuente se pondrá a disposición de los

titulares de licencias.
La libertad de derechos de autor o Copyleft es una forma de licenciamiento del código

abierto que concede el derecho a reproducir, adaptar o distribuir el Software. No obstante,
impone la restricción de que cualquier trabajo derivado sea liberado bajo la misma licen-
cia. De esta manera tanto el Software como la libertad que se le ha otorgado se vuelven
inseparables.
Las licencias Copyleft son por lo tanto un subconjunto de las licencias OSS que incluso
pueden estar más restringidas con etiquetas como Copyleft-fuerte o Copyleft-débil.
Movimientos dentro del OSS
Existen dos movimientos principales y organizaciones que promueven el OSS y certifi-

can licencias como Software de código abierto o libre. Son la Fundación para el Software
Libre (Free Software Foundation, FSF) y la Iniciativa de Código Abierto (Open Source
Initiative, OSI).
La FSF se fundó en 1984 por Richard Stallman del proyecto GNU e introdujo la Licencia
Pública General GNU (General Public License, GPL) así como el término de Copyleft. La
FSF defiende que el Software libre es un asunto de usuarios, libertad para ejecutar, copiar,
distribuir, estudiar, cambiar y mejorar el Software. En efecto, el principal objetivo de la
FSF es mantener gratuito el Software permitiendo que otros construyan sobre el código
de uno y devolver sus cambios a la comunidad.
El término de Código Abierto fue acuñado en 1997 por Eric Raymond y Bruce Perens,
quien también escribió la definición de Código Abierto, consistente en diez criterios para
determinar si una licencia es OSS o no.
El OSI se formó en 1998 ya que Netscape decidió liberar el código fuente de su navegador
al público. Esta decisión creó cierta preocupación entre la comunidad de desarrolladores
ya que su trabajo de creación podría circular libremente y no estaba claro qué quería decir
la palabra “free”, si bien Stallman comentó que pensaría en “free” como libertad y no como
gratuidad.
5.1.4.3. Modelos de negocio

La decisión de una organización de dirigirse al dominio del OSS debe estar fundamen-
tada no sólo en consideraciones sociales y tecnológicas sino también en una profunda
evaluación de la perspectiva de negocio y del impacto de dicha decisión.
118
El modelo de negocio de OSS y en particular la lógica de ingresos detrás del desarrollo y

distribución de OSS no resulta uno de los más obvios a percibir. Sin embargo, tal y como
varios de los marcos de análisis de modelos de negocio indican la lógica de ingresos es
sólo una parte de la foto total.
La estrategia de negocio y del producto, incluyendo los tipos de servicios que se ofrecen,
el desarrollo de las competencias principales y las ventajas competitivas, el enfoque de
mercado de la empresa, la creación deposiciones de la cadena de valor o la explotación de
comunidades de consumidores específicas resultan igual de importantes.
Por lo tanto, un desplazamiento hacia el OSS debe ser considerado como una maniobra
estratégica más que simplemente como la formación de un nuevo flujo de ingresos.
A continuación nos centraremos en los distintos tipos de ventajas competitivas que pue-
de ofrecer la adopción de OSS y el impacto que puedan tener al nivel de negocio.
Más adelante repasaremos qué pre-requisitos son necesarios para que este traslado sea
exitoso y algunas de las preocupaciones que deberían ser tenidas en cuenta y sopesadas.
Por último describiremos elementos específicos y características de los distintos modelos
de negocio OSS y los ecosistemas de compañías, organizaciones y otros participantes que
se encuentran cercanos.
Ventajas Competitivas y el Impacto de Migrar a OSS
La adopción de las prácticas de OSS puede ofrecer varias ventajas estratégicas y puede
impactar el modelo de negocio de una empresa u organización de varias formas.
El cambio de la venta de Software comercial a la distribución de OSS se puede realizar

parcialmente o en etapas. Las posibles estrategias incluyen el ofrecer el código fuente
con una licencia cerrada que tiene una fecha de expiración, o convertir versiones previas
de un producto a OSS mientras que se vende la última versión como una fuente cerrada.
Así pues, el Software se puede ofrecer como una solución parcialmente abierta, y así pro-
porcionar valor a los consumidores y poniéndoselo difícil a los competidores. Una forma
de conseguir esto es por medio de una licencia restringida.
Otra forma sería que sólo ciertas partes del Software fueran OSS, mientras que se retiene
el control total de las capas más críticas. El grado y forma en la cual un fabricante de Soft-
ware decide liberar su código puede depender de su posicionamiento en el mercado y con
respecto a otros productos.
119
La siguiente tabla resume las ventajas estratégicas y de negocio de cambiar a OSS. Se

encuentran agrupadas en tres categorías: ventajas resultantes de la base de usuarios y co-
munidad que se forma alrededor de los productos OSS, ventajas resultantes del mercado
especial y el posicionamiento de los competidores que ofrece el OSS y finalmente las ven-
tajas más directamente relacionadas con los costes de producción y los flujos de ingresos.
Base de usuarios y Posicionamiento en el Flujo de ingresos y

comunidad mercado y competidores finanzas
Desarrollo de base de
usuarios
Acercamiento a mercados Permitir nuevos
Información sobre
restringidos servicios
mercados
Mejora de la reputación Mejorar la
Diseminación de
demanda de servicios
Innovación
Ataque a los competidores complementarios
Mejora de productividad
Adelantarse al desarrollo de Reducir los costes de
estándares cerrados desarrollo
Acceso a las
necesidades de los
Adoptar la mentalidad de Rebajar los puntos de
clientes
víctima ruptura
Uso de desarrolladores
Escapar del bloqueo del Introducir nuevos
externos
fabricante flujos de ingresos
Acceso a nuevas
habilidades y prácticas
Resumen de ventajas estratégicas y de negocio de migrar a OSS
Comunidad y Base de Usuarios
Existen casos donde se pueden construir grandes comunidades de usuarios rápidamente

por medio de la conversión a OSS, frecuentemente con gastos mínimos de ventas y pu-
blicidad. Los mercados existentes se pueden forzar o reconfigurar y se pueden obtener
ganancias significativas.
Un ejemplo es la compañía Netscape, que liberó el código fuente de su navegador para

incrementar su base de usuarios con respecto a sus competidores. A través del desarrollo
OSS se recoge información dinámicamente sobre productos, servicios, necesidades del
cliente y en última instancia del propio mercado.
120
También ocurre que el desarrollo OSS crea oportunidades para establecer estándares de
la industria y permitir la compatibilidad con otros productos o sistemas. Al mismo tiempo,
ofrece un medio poderoso de diseminar los resultados de la innovación e investigación a
través de la comunidad. Liberando el código fuente de un producto disponible se espera
que lleve a mayor innovación, tomando en cuenta que una masa crítica de desarrolladores
se encontrará atraída por este hecho.
La productividad del desarrollo también puede verse incrementada significativamente

por el apalancamiento de talento y experiencia que se encuentra en la comunidad OSS. La
cercana interacción del proceso de desarrollo OSS con la base de usuarios y consumido-
res a menudo permite que se tome en cuenta las necesidades del consumidor en el diseño
y personalización de procesos.
Esto último proporciona una ventaja competitiva con respecto al enfoque del desarrollo
de Software propietario.
Por último, un cambio a OSS permite a pequeñas compañías, que emplean un número
limitado de desarrolladores, que se beneficien de un largo grupo de desarrolladores ex-
ternos y sus habilidades técnicas y experiencia para participar en prácticas como revisión
entre pares que resultan en mejores productos Software y estar expuestos a la innovación,
que de otra forma no se podrían permitir crear de manera interna.
Posicionamiento en el Mercado y Competencia
OSS puede suponer una manera efectiva de abordar comunidades limitadas o restringi-
das donde las estrategias de mercado tradicionales no funcionan. Las personalizaciones
y adaptaciones de las necesidades particulares de estos mercados nicho proporcionan
fuentes adiciones de ingresos.
Además, el enfoque OSS se puede usar para atacar a los competidores por medio de ofre-
cer productos similares y a coste sustancialmente menor (o completamente gratis). Un
ejemplo de esto es el paquete OpenOffice (frente a MS-Word). Se ha observado que esta
práctica puede adelantarse al desarrollo de estándares cerrados propietarios por parte de
los competidores.
Con frecuencia los productos OSS compiten con productos no OSS ofreciendo soluciones
y funcionalidades similares. Los productos no OSS tienen la ventaja de mayores recursos,
publicidad y relaciones públicas y por contra la ayuda de la comunidad de desarrolladores
puede impulsar al producto OSS de manera considerable.
Por último, los consumidores también aprecian el hecho de que con OSS no están atrapa-
dos por el fabricante. Se ha encontrado que esto afecta de manera positiva a la lealtad del
usuario y consumidor a través de encuestas y entrevistas.
121
Flujos de Ingresos y Financieros
Cuando se libera el código de un Software propietario, existen efectos indirectos que in-
cluyen una demanda creciente por otros productos y servicios que complementen o so-
porten la oferta principal. Esto puede llevar a mejorar tanto la rentabilidad de la empresa
como su posicionamiento en el mercado y reputación debido a una mejor calidad, nivel
de soporte y posibilidades de personalización.
El ratio entre los costes de desarrollos fijos y totales se reduce, reduciendo los puntos de
ruptura para nuevas iniciativas y reduciendo el riesgo global. El coste total de desarrollo
también se reduce por medio de los procesos distribuidos que implican el soporte de
desarrollo externo.
Pre-requisitos, Factores Decisivos y Preocupaciones
El cambio desde la distribución de soluciones cerradas a OSS requiere una cuidadosa

consideración.
Podría resultar que en algunos casos liberar el código fuente no resulte un movimiento
inteligente ya que cada empresa, producto o mercado requiere un enfoque específico.
Por ejemplo, los productos Software que se centran en liderar por coste o con un alcance
funcional horizontal son mejores candidatos para cambiar a OSS que aquellos que ofre-
cen un valor añadido por medio de su sofisticación o funcionalidades avanzadas.
El Software que tenga un amplio alcance horizontal que está enfocado a un mercado ma-
sivo es probable que atraiga mayor atención de los desarrolladores externos y por lo tanto
está mejor indicado para la apertura de código.
La posición en el mercado del producto Software también es un factor importante en

esta decisión. Por ejemplo, liberar el código de un producto que tiene una gran cuota de
mercado y que está al frente del “estado del arte” en cuanto a capacidades técnicas con
respecto a sus competidores o que tiene un ecosistema de otros productos y servicios
dependiendo de él es improbable que reporte ningún beneficio a su fabricante.
La decisión sobre liberar el código de un producto debería incluir también las siguientes
etapas y consideraciones:
• Evaluar el mercado y el producto objetivo: Considerar tanto las ofertas comer-

ciales como de OSS o combinaciones de ambas. Determinar si existe interés del
mercado porque el producto se vuelva de código abierto.
122
• Determinar el interés de la comunidad de desarrolladores: Considerar la proba-

bilidad de que se forme una comunidad de desarrolladores alrededor del producto
y que proporcionen sus habilidades, experiencia y esfuerzos de desarrollo una vez
que sea de código abierto. Los foros, listas de distribución de correo, redes sociales
y otros canales de comunicación pueden ofrecer tales percepciones.
• Decidir qué componentes del producto liberar: Es posible liberar sólo un com-
ponente y mantener el resto como propietario. Las razones pueden ser desde es-
conder secretos o algoritmos que mejor que no se publiquen, que parte del código
fuente se esté compartiendo con otros productos o que tenga dependencia de tec-
nologías de terceros con distintos esquemas de licenciamiento.
• Equilibrar los costes del cambio a corto plazo: Los costes técnicos del cambio
pueden implicar compatibilidad con versiones anteriores de las nuevas versiones
OSS, o que los consumidores no están dispuestos a embarcarse en una nueva di-
rección OSS y prefieran cambiar a otros productos.
Además, es posible que se necesite contratar a nuevo personal y si no existe sufi-

ciente familiaridad con las prácticas OSS se puede necesitar externalizar parte de
los procesos como la instalación, configuración y mantenimiento.
• Considerar nuevos procesos, infraestructura o entorno: Formar un proyecto y

comunidad OSS cambiará la forma en la que una compañía u organización realiza
el desarrollo de Software.
Se necesitará infraestructura técnica específica y un entorno apropiado que dé so-

porte a los problemas como la formación de una nueva comunidad abierta y cola-
borativa, el libre flujo de la información, nuevos modelos de gobierno y habilidades
de gestión, división de las tareas y soporte para equipos de trabajo geográficamen-
te distribuidos.
El acceso a la comunidad OSS, la gestión de la información OSS que está disponi-

ble en Internet y tratar los problemas de licenciamiento y con clientes son rutinas
organizativas adicionales que necesitan de apoyo. Antes de embarcarse en la di-
rección a OSS es importante verificar que estos elementos se pueden desarrollar
y mantener.
• Asegurar que esté presente una mentalidad correcta: El desarrollo de OSS re-
quiere una mentalidad y cultura particular que puede que no esté presente dentro
de la empresa y que se necesite desarrollar. Pueden existir resistencias por ideólo-
gos no OSS.
123
Es posible que falte la cultura de respeto por los derechos intelectuales de los desa-
rrolladores o que exista la necesidad de enlazar sus habilidades y capacidades con
los requisitos del proyecto.
Las formas de superar estas dificultades son la participación en otros proyectos o

eventos OSS, la selección de una licencia que sea capaz de atraer a una comunidad
de desarrollo o permitir que los empleados de la empresa se impliquen en otros
proyectos OSS antes de hacer el cambio. Se necesita también desarrollar la toleran-
cia por la inevitable cabalgata por libre, así como el entendimiento de que el abrir
el código propio proporcionará ciertas ventajas a los competidores.
• Desinfectar el código: Aunque pueda verse como un paso técnico secundario, el

asegurarse de que el código está listo para la distribución pública puede resultar
ser una tarea tediosa que implique rescribir o añadir comentarios y documenta-
ción, re-implementación de ciertas funcionalidades de mejores maneras y la elimi-
nación de ciertas partes que sólo estén indicadas para una visión interna. Esto es
importante, ya que el código fuente es probable que sea sometido a un escrutinio
(incluso por herramientas automáticas) y formará parte de la nueva imagen de la
empresa.
• Seleccionar un modelo apropiado de negocio: Es importante seleccionar el más

apropiado atendiendo a un amplio rango de consideraciones. Lo veremos más ade-
lante.
• Seleccionar una licencia apropiada: Tal y como vimos anteriormente seleccionar

la más apropiada atendiendo al grado de permisividad necesario.
• Decidir el enfoque publicitario: La construcción de la conciencia hacia un pro-

ducto OSS puede resultar un desafío, dado que se necesitará abordar o crear nue-
vos canales de comunicación y se deberá realizar una aproximación a nuevas co-
munidades de usuarios.
Dato importante
La decisión de una organización de dirigirse al dominio del OSS debe estar funda-
mentada no sólo en consideraciones sociales y tecnológicas sino también en una
profunda evaluación de la perspectiva de negocio y del impacto de dicha decisión.
124
Ecosistema del OSS
Los modelos de negocio basados en OSS pueden implicar que muchos participantes de
una industria cooperen en distintos roles para formar un ecosistema. A continuación in-
troduciremos de manera resumida los tipos de empresas, grupos y organizaciones que
pueden estar implicados en tal ecosistema, y después examinaremos los enfoques a tra-
vés de los cuales el negocio se puede basar en esas cooperaciones.
Los desarrolladores OSS y las comunidades de proyectos conforman un grupo diverso

de gente con una pasión e interés compartido en tanto un proyecto como un producto
específico y en el concepto de hacerlo abierto a la comunidad para que cualquiera pueda
realizar mejoras o añadirle funcionalidades. Están organizados en una comunidad que
está formado alrededor de un proyecto, tanto si se trata de desarrolladores independien-
tes o dentro de los límites corporativos.
Los distribuidores de Software se centran en el negocio de la integración de sistemas,

empaquetamiento, aseguramiento de la calidad y servicios. Ejemplos típicos son las dis-
tintas distribuciones de Linux (de manera significativa RedHat y SuSE).
Su papel en el OSS es importante ya que empaquetan el Software en distintas distribucio-

nes, las mejorar con aplicaciones middleware y ofrecen soporte técnico y otros servicios
de valor añadido como formación para tareas específicas.
Estas empresas obtienen ingresos debido al gran número de transacciones en las que
están implicados y también ganan en reputación por su participación en el movimiento
OSS.
Los productores y fabricantes de Software se pueden beneficiar del OSS por medio de
la incorporación de OSS en la oferta de sus productos. Pueden utilizar el código fuente
existente dentro de los productos que desarrollan o pueden adoptar productos completos
de OSS e incluirlos en su lista de ofertas, sujeto a las restricciones de licenciamiento. En
cualquier caso, de esta manera minimizan sus costes totales de producción.
Además, pueden ofrecer servicios complementarios y soporte técnico a los usuarios de

productos OSS de terceros (similar a lo que hacen los distribuidores). Finalmente pueden
también elegir abrir la totalidad o parte de sus propios productos (por ejemplo, Sun y
Java, Netscape y Mozilla,…). Se ha podido constatar que tal movimiento ha resultado en
numerosos beneficios incluyendo un aumento de ingresos y reputación. La elección de la
licencia dependerá de su estrategia de desarrollo de negocio.
125
Los productores y fabricantes de Hardware pueden incorporar OSS, tales como con-
troladores (drivers) y aplicaciones que soporten su Hardware (por ejemplo, HP e IBM).
También pueden utilizar OSS en plataformas de Software embebido, tales como decodifi-
cadores, enrutadores de banda ancha, teléfonos móviles y navegadores GPS (por ejemplo
el videograbador TiVO y los móviles Android).
Los proveedores externos de servicios proporcionan soporte técnico, servicios de asis-

tencia y valor añadido, de manera similar (y frecuentemente en competición directa) a los
distribuidores.
Los usuarios finales de los productos Software son normalmente categorizados como
usuarios domésticos o corporativos, siendo éstos últimos más proclives a pagar por una
documentación detallada del producto o por servicios de valor añadido como soporte
técnico.
Otros tipos de negocios pueden estar involucrados en el ecosistema OSS, incluyendo

compañías que fabriquen accesorios para ser comercializados junto con los productos de
Software OSS dirigidos a la comunidad OSS u otros tipos de organizaciones afines a la
causa OSS que puedan desear ofrecer su apoyo o patrocinio.
Modelos Principales de Negocio
En los siguientes párrafos describimos los principales modelos de negocio que se en-
cuentran dentro del ecosistema OSS.
1. Empaquetado de valor añadido
Es posible empaquetar una gran variedad de productos y servicios de valor añadido junto
con el núcleo del producto OSS. Servicios típicos pueden ser instalación e integración
de sistemas o soporte técnico. Un ejemplo típico de este papel es RedHat, que facilita la
compleja tarea de instalación y configuración de los diversos componentes del sistema
operativo GNU/Linux. El soporte técnico, personalización y servicios de actualización
están más enfocados a los consumidores corporativos y pueden incluir acuerdos a largo
plazo. Los servicios de soporte a la versión de Software pueden incluir la identificación y
provisión de la versión más segura, estable y reciente de un producto OSS en particular
así como el ofrecimiento de versiones avanzadas o Premium a través de algún mecanismo
de suscripción.
Finalmente, el empaquetamiento también se puede ofrecer en términos de una distribu-

ción física y entrega del producto OSS (por ejemplo CDs/DVDs y documentación impre-
sa enviada por correo postal ordinario).
126
2. Servicios y soporte
Los servicios y el soporte conforman un modelo de negocio similar al del empaquetado

de valor añadido, sin embargo está orientado hacia servicios más independientes y solu-
ciones de soporte.
Un modelo de suscripción puede ofrecer a los usuarios la habilidad para comprobar ma-
nualmente las actualizaciones de Software y nuevas versiones, acceso a foros de discusión
para el soporte técnico así como acceso a consultores y contratistas de pago para ayudar
con tareas específicas. Como ejemplos tenemos el escritorio corporativo Linux de SuSE y
el servidor de aplicaciones JBoss de RedHat.
Este modelo proporciona un flujo de ingresos predecible para los proveedores y la op-
ción de contratar tales servicios sólo cuando sea necesario para los clientes. Se puede
proporcionar un soporte y formación postventa junto con documentación y manuales
adicionales.
Finalmente, es posible ofrecer servicios de consultoría independientes con respecto a los

aspectos estratégicos de las decisiones e inversiones relacionadas con OSS.
Algunas veces los proveedores de Software también aúnan este papel de consultor, be-
neficiándose de su reputación para ofrecer estos servicios e incrementando de esa forma
sus ingresos.
3. Modelo del artículo cebo (Loss-Leader)
En este modelo el Software se puede distribuir libremente como de código abierto, para
atraer el interés y disparar la demanda hacia otro Software comercial relacionado. Esta
práctica crea una comunidad de desarrolladores y usuarios alrededor del producto e in-
crementa la reputación del fabricante.
El Software propietario puede ser una versión avanzada del producto OSS (por ejemplo
la versión OSS de Sendmail frente a la comercial Sendmail PRO) o puede ser un conjunto
de funcionalidades o productos relacionados (por ejemplo, guías, kit de herramientas,
marcos o idiomas,…).
4. Licenciamiento dual
Varios fabricantes permiten a sus clientes seleccionar qué licenciamiento desean aplicar
para el uso de su Software. Una licencia libre tal como GPL se ofrece para aplicaciones no
comerciales y una licencia propietaria para las que sí lo son. De manera alternativa, las
extensiones de una oferta OSS se pueden cubrir con una licencia no OSS.
127
Las versiones comerciales de una aplicación OSS pueden incluir características o ca-
pacidades adicionales. Las ventajas de la presencia de la empresa y sus productos en la
comunidad OSS se emplean para disparar las ventas de las versiones comerciales (por
ejemplo, MySQL).
5. Componente embebido (Widget Frosting)
Este término se emplea para embeber Software OSS en productos Hardware, tales como
un núcleo (kernel), controladores de impresión, compiladores, sistemas operativos o apli-
caciones. Esto ofrece al fabricante de Hardware todas las ganancias de un desarrollo OSS
(un grupo más numeroso de desarrolladores, mayor implicación del cliente, revisión en-
tre pares y otras medidas de fiabilidad así como un posible incremento de lealtad de los
clientes).
Los costes de licenciamiento del Software se reducen. Ejemplos de esta estrategia es el

descodificador de TiVO que ejecuta un kernel de Linux o la fundación “One Laptop Per
Child” con su portátil XO que está basado en una distribución GNU/Linux Fedora.
6. Licenciamiento de marca
En el licenciamiento de marca una empresa cobra a otras empresas por los derechos de
uso de sus nombres de marcas registradas. La reputación de la marca gana en la creación
de un producto OSS exitoso que se ha vendido a otras empresas que crean productos
derivados.
Por ejemplo Sun liberó una implementación de la plataforma Java bajo licencia GPL lla-
mada Open Java Development Kit que retuvo la marca Java para utilizar su poder de
alineamiento con otras implementaciones bajo la misma estrategia de “escribe una vez,
ejecuta en cualquier sitio”.
7. Complementar con accesorios (Accessorising)
Existe una infinidad de accesorios que acompañan al Software OSS, desde libros, manua-
les y documentación a elementos más auxiliares como camisetas, tazas y pegatinas. Las
empresas obtienen ingresos considerables de la venta de tales objetos. Como ejemplos
tenemos la compañía de publicaciones O’Reilly que ofrece cientos de títulos de docu-
mentación sobre Software OSS e incluso conferencias sobre el tema como la convención
de código abierto (Open Source Convention, OSCON)
8. Soporte financiero y coexistencia
Aunque esta quizá no llegaría a ser un modelo de negocio en el sentido estricto, los pro-
yectos OSS están sustentados por donaciones de otras empresas que han adoptado sus
productos. Adicionalmente las fundaciones como la FSF pueden ayudar al sostenimiento
de proyectos OSS o directamente a sus programadores.
128
Las empresas pueden también patrocinar directamente los proyectos OSS, ya sea por
medio de fondos o contribuyendo con desarrolladores para trabajar en proyectos o por
medio de la liberación de código y motivando a sus empleados a que trabajen sobre ello.
Como ejemplo tenemos al entorno de desarrollo Eclipse de IBM que aún se encuentra
sustentado por programadores de IBM.
Por último, los fondos de capital riesgo también demuestran un interés considerable en
los proyectos OSS, especialmente detrás de las historias de éxito como RedHat, Netscape
y otros.
5.1.4.4. Repaso a aplicaciones OSS representativas

A continuación mostramos una colección de algunas de las más destacadas aplicaciones
de OSS, categorizadas según su tipo. Las aplicaciones seleccionadas incluyen algunas de
las más populares (en términos de número de descargas de SourceForge.net) y algunas
seleccionadas como ejemplos representativos de las distintas categorías, si bien esta se-
lección no pretende ser objetiva ni completa.
APLICACIONES DE SISTEMAS
Sistemas Operativos
GNU/Linux, FreeBSD,
NetBSD, OpenBSD, Xen
Entornos de
Escritorio
Gnome, X11, KDE
Bases de Datos
MySQL, PostgreSQL, HSQL-

DB, SQLite
Servidores Web y de
Aplicaciones
Apache HTTP Server, Jakarta

Tomcat, JBoss, AWAStats
Herramientas de
Administración de
Sistemas
Wireshark, Nagios, phpM-

yAdmin
Correo Electrónico
Fetchmail, Sendmail, Postfix,

SpamAssassin
129
APLICACIONES DE SISTEMAS
Infraestructura de
red
Bind, Zenoss
Seguridad
Clonezilla, putty, TrueCrypt,

WinSCP
APLICACIONES DE
ESCRITORIO
Mosaic, Firefox, Thunderbird,

OpenOffice.org, Evolution,
Pidgin (Gaim), KeePass Pas-
sword Safe
ENTRETENIMIENTO
Mumble, MediaInfo, Media

Player Classic, Bittorrent,
VLX media player, Audacity
GRÁFICOS
Inkscape, Ghostscript, Gnu-

plot, GMT, GraphViz, GIMP,
iReport, FreeMind
EDUCACIÓN
Moodle, Tux Paint, EToys,

Scratch
CIENTÍFICO E INGENIERÍA
R-Project, GNU Octave
EDICIÓN
TeX, Docbook, TCPDF, TeX-

nicCenter
DESARROLLO DE SOFTWARE Lenguajes, Intérpre-

tes y Compiladores
GCC, Java Technology, Scala,

Erlang, Haskell, Perl, Python,
PHP, Ruby, Tcl/Tk, Lua,
ScummVM, MinGW
Librerías
Libpng, GD, Boost C++
Editores
Vim, GNU Emacs, Note-

pad++
130
DESARROLLO DE SOFTWARE
Sistemas de Control
de Versiones
CVS, Apache Subversion,

Git, Mercurial
IDEs y Herramientas
de construcción de
Software
Eclipse, NetBeans, Apache

Ant
Marcos (Frameworks)
ZK Simply Ajax and Mobile,

Mono, Qt, Ruby on Rails
SISTEMAS DE GESTIÓN DE
CONTENIDOS
Drupal, WordPress, Joomla,

Arianne RPG, Media Wiki
APLICACIONES DE NEGOCIO
Compiere, OpenERP, Post-

Books ERP, Openbravo ERP,
webERP, OrangeHRM, JStock
Algunas aplicaciones OSS destacadas por categorías
5.2. Ingeniería del software: metodologías, fases, estándares y mejores

prácticas
En esta sección pretendemos mostrar una perspectiva del arte de la programación. La
historia comienza alrededor de 1960 y continúa con su desarrollo hoy en día.
El término Ingeniería del Software se volvió popular después de una conferencia en

1968, cuando las dificultades y obstáculos para diseñar sistemas complejos se estaban
tratando de manera abierta. Comenzó pues una búsqueda de soluciones que se concentró
en mejores metodologías y herramientas.
Los más prominentes fueron los lenguajes de programación que reflejaran el estilo pro-
cedimental, modular y por último orientado a objetos. La ingeniería del Software está
íntimamente ligada a su aparición y mejora. También fueron significativos los esfuerzos
de sistematizar o incluso automatizar tanto la documentación de programas como las
pruebas.
131
En última instancia, las pruebas de corrección y la verificación analítica estaban diri-

gidas a sustituir a las pruebas. Más recientemente, el rápido crecimiento de la potencia
de computación ha hecho posible aplicar la misma a incluso tareas más complejas. Esta
tendencia ha incrementado drásticamente las demandas de ingenieros de Software. Los
programas y los sistemas se volvieron complejos y prácticamente imposibles de entender
en su totalidad. Los gastos de amortización y la abundancia de recursos de computación
redujeron inevitablemente el cuidado por el buen diseño. La calidad sonaba extravagante,
incluso un perdedor en la carrera por obtener beneficios.
No obstante, deberíamos estar preocupados por los resultados del deterioro de la calidad.
Nuestras limitaciones no vienen más por un Hardware lento, sino por nuestra propia ca-
pacidad intelectual. El resultado de esta experiencia nos indica que la mayoría de progra-
mas deberían ser mejorados de manera significativa y hechos más fiables, económicos y
fáciles de usar.
Las ciencias de la computación normalmente se caracterizan como una disciplina de la

ingeniería con el estudio sistemático y desarrollo de Software como su principal materia.
La Ingeniería del Software por otro lado aunque combina ambas palabras clave no ha sido
una disciplina central en la mayoría de los departamentos de ciencias de la computación.
En muchos aspectos, esta disciplina está caracterizada por las mismas idiosincrasias que
se han observado dentro de las ciencias de la computación en conjunto:
• Campo altamente innovador y cambiante sin un núcleo ampliamente reconocido

de material que todo practicante de la profesión debe conocer.
• Pocos resultados se encuentran sustentados por estudios empíricos o comparati-

vos.
• El trabajo dentro del campo anterior a tres o cuatro años raramente se toma en
cuenta o se referencia.
• Se suele dar nuevos nombres a problemas antiguos y las soluciones antiguas se

pasan de largo.
• La evolución de la disciplina está fuertemente ligada a las demandas económicas

y de la sociedad.
• Existe una necesidad de trabajo interdisciplinar que comprende por ejemplo las
matemáticas, psicología, ciencias empresariales, ciencias físicas, ciencias de la sa-
lud, …
• Existe un continuo debate sobre si debería haber una disciplina llamada Ingeniería
del Software y si así es si debería ser tratada como otra disciplina entre el conjunto
de disciplinas de ingeniería tradicional.
132
Explicación de la concepción de la Ingeniería del SW
5.2.1. Nacimiento de los modelos de desarrollo de Software

En los años 60, cuando el desarrollo de Software todavía era algo relativamente nuevo,
existía muy poco de algo que pudiéramos llamar proceso formal. Los programadores
simplemente hicieron lo mejor que pudieron para anticipar cuanto tiempo tardarían en
realizarlo y se ponían a codificar. A menudo, las predicciones eran incorrectas y muchos
proyectos de Software sobrepasaban el presupuesto de manera desastrosa.
En los 70, en un intento de traer algo de orden a este proceso impredecible, muchos de-
sarrolladores (normalmente a instancias de la dirección) intentaron adoptar el modelo en
cascada (Waterfall Model), que consistía en un proceso ordenado de siete etapas orienta-
do a la ingeniería del Software que podemos observar en la siguiente figura.
133
Modelo de desarrollo de SW en Cascada
A simple vista parece un proceso atractivo, compuesto por siete etapas ordenadas y en el
que cuando se concluye una etapa no hay más acción que pasar a la siguiente. El mismo
nombre de “cascada” indica que no existe iteración de ningún tipo dado que el agua no
sube tras haber caído.
El modelo en cascada posee una muy buena cualidad, que es que fomenta que los desa-
rrolladores pasen más tiempo en la planificación y diseño antes de saltar a la codificación.
Excepto por eso, es un completo sinsentido, dado que viola la regla del bucle.
134
Los gerentes lo encontraron increíblemente atractivo, pero los programadores sabían que
era un absurdo, ya que el Software es algo muy complejo como para que funcione algu-
na vez con un proceso tan lineal. Incluso el creador de este modelo (Winston Royce) no
estaba de acuerdo con este modelo como se entiende de manera común. Es interesante
resaltar que incluso en su publicación original resalta la importancia de la iteración y la
capacidad para volver a pasos previos tantas veces como fuera necesario. De hecho, nun-
ca utilizó la palabra “cascada”, pero se dedicó a enseñar en universidades y empresas este
enfoque lineal. Parece en fin que todo esto ha sido promulgado por gente que nunca tuvo
que construir sistemas reales por ellos mismos.
Entonces, en 1986 Barry Boehm presentó un modelo distinto, que se basaba más en cómo
el desarrollo de Software ocurre de manera real. Se presenta normalmente como una es-
pecia de diagrama intimidatorio, donde el desarrollo comienza en el centro y se expande
en espiral en sentido de las agujas del reloj, pasando por cuatro cuadrantes de manera
sucesiva, tal y como podemos observar en la figura siguiente.
Modelo de desarrollo de SW en Espiral
135
Su modelo contiene muchísimo detalle complejo, que quizás no sea necesario que abor-
demos.
Existen básicamente tres grandes ideas, envueltas en los siguientes elementos: evalua-
ción de riesgo, prototipos y bucles. En resumen, el modelo en espiral sugiere que durante
el proceso de desarrollo de Software:
1. Comenzar con un diseño básico
2. Anticipar los mayores riesgos del diseño
3. Construir prototipos que mitiguen esos riesgos
4. Probar los prototipos
5. Detallar el diseño aprovechando lo aprendido
6. Volver al paso 2
Básicamente se trata de repetir este ciclo hasta que el sistema esté completo. Este modelo
gana al modelo en cascada sin lugar a dudas ya que permite una revaluación y comproba-
ción de requisitos constante por lo que resulta más flexible. Por el contrario, es más difícil
predecir el tiempo en el que estará listo el producto y mantener controlados los costes.
Existen otros modelos de Ingeniería del Software descendientes de los anteriores y que
han ido surgiendo y han sido adoptados, cada cual con sus beneficios y perjuicios.
5.2.2. Comparativa de cinco modelos principales de desarrollo de Software

Un modelo de proceso de Software es una representación abstracta de un proceso.
La descripción de este proceso viene dada por cuatro etapas fundamentales:
1. Especificación
2. Diseño
3. Validación
4. Evolución
La manera en la que un proceso de desarrollo de Software pasa por las etapas anteriores
constituye los modelos de desarrollo de nuestro estudio. Así pues, de entre todos los exis-
tentes, distinguimos los siguientes modelos por resultar ser los más adoptados para el
desarrollo del Software:
136
1. Modelo en Cascada
2. Modelo Iterativo
3. Modelo o Método en V
4. Modelo en Espiral
5. Modelo de Programación Extrema
5.2.2.1. Modelo en Cascada

Tal y como introdujimos anteriormente, el mismo supone el enfoque clásico de la ingenie-
ría de Software. Es uno de los más antiguos y se emplea en proyectos de la administración
del estado y en grandes compañías. Dado que este modelo enfatiza la planificación en las
etapas tempranas, garantiza el descubrimiento de defectos del diseño antes de que se de-
sarrollen. Además, su intensa documentación y planificación hace que funcione bien para
proyectos en los cuales el control de calidad es una preocupación prioritaria.
El ciclo de vida del modelo en cascada puro consisten en una serie de etapas no solapadas
tal y como vimos anteriormente. Las etapas son las siguientes:
1. Requisitos del sistema: Establecen los componentes para construir el sistema, in-
cluyendo los requisitos del hardware, las herramientas Software y otros componentes
necesarios. Como ejemplos podemos incluir las decisiones sobre paquetes externos
de Software como bases de datos o librerías necesarias.
2. Requisitos de Software: Establece las expectativas para la funcionalidad del Soft-

ware e identifica a qué requisitos del sistema afecta el Software. El análisis de requi-
sitos incluye determinar la interacción necesaria con otras aplicaciones y bases de
datos, requisitos de rendimiento, requisitos de interfaz de usuario, etc.
3. Diseño de Arquitectura: Determina el marco de Software de un sistema para cum-

plir con los requisitos específicos. Este diseño define los componentes principales y
la interacción de esos componentes pero no define la estructura de cada componente.
Los interfaces externos y herramientas empleados en el proyecto pueden ser deter-
minados por el diseñador.
4. Diseño Detallado: Examina los componentes de Software definidos en la etapa de di-

seño de arquitectura y produce una especificación para detallar cómo se implementa
cada componente.
5. Codificación: Implementa la especificación del diseño detallado.
137
6. Pruebas: Determina si el Software cumple con los requisitos específicos y encuentra

cualquier error presente en el código.
7. Mantenimiento: Aborda los problemas y las peticiones de mejora después de que el

Software se haya entregado.
En algunas organizaciones, un comité de control de cambios (Change Advisory Board,

CAB) mantiene la calidad del producto por medio de una revisión de cada cambio que se
realiza en la etapa de mantenimiento. Se ha de considerar el aplicar el modelo de ciclo de
desarrollo en cascada cuando se corrijan problemas o implementen peticiones de mejora.
En cada etapa se crean los documentos que explican los objetivos y describen los reque-
rimientos para esa fase. Al final de cada etapa se produce una revisión para determinar si
el proyecto puede proseguir a la siguiente etapa. Es posible incluir un prototipo en cual-
quiera de las etapas desde el diseño de arquitectura en adelante.
Mucha gente cree que este modelo no se puede aplicar a todas las situaciones. Por ejem-
plo, con el modelo en cascada puro, los requisitos deben estar listos antes de comenzar
con el diseño, y el diseño completo debe estar listo antes de comenzar con la codificación.
No existe pues un solapamiento entre etapas.
En el desarrollo de Software del mundo real sin embargo uno descubre problemas duran-
te las etapas de diseño o codificación que señalan errores o lagunas en los requerimientos.
El modelo en cascada no prohíbe retornar a fases más tempranas, por ejemplo volver a
dase de requisitos desde la fase de diseño. Sin embargo, esto implica un costoso trabajo.
Cada fase completada requiere una revisión formal y el desarrollo de una extensa docu-
mentación. Por lo tanto, cualquier descuido hecho en la fase de requisitos supone una
costosa corrección en fases sucesivas.
Dado que el actual desarrollo viene más tarde en el proceso, uno no ve resultados por un
largo período de tiempo. Este retraso puede ser desconcertante tanto para la dirección
como para los clientes. Mucha gente cree también que la cantidad de documentación es
excesiva y poco flexible.
Aunque el modelo en cascada tiene sus debilidades, resulta instructivo porque resalta
etapas importantes del desarrollo del proyecto. Incluso si uno no aplica este modelo debe
considerar cada una de estas etapas y sus relaciones en su propio proyecto.
138
Ventajas y Desventajas modelo en Cascada
Como ventajas podemos encontrar:
• Fácil de entender e implementar
• Usado y conocido ampliamente
• Refuerza los buenos hábitos: definir antes de diseñar, diseñar antes de codificar
• Identifica entregables e hitos
• Dirigido por documentos, URD, SRD,…Estándares de documentación publicados

(p.e. PSS-05)
• Funciona bien en productos maduros y equipos débiles
Y por el contrario, como desventajas podemos señalar:
• Idealizado, no se ajusta perfectamente a la realidad
• No refleja la naturaleza iterativa de un desarrollo exploratorio
• Es irrealista al esperar unos requerimientos precisos tan tempranamente en el pro-

yecto
• El Software se entrega tarde en el proyecto lo que retrasa el descubrimiento de

errores serios
• Resulta difícil la integración de la gestión de riesgos
• Resulta difícil y caro realizar cambios en los documentos
• Existe una sobrecarga administrativa significativa lo que es costoso para pequeños

equipos y proyectos
Variantes del modelo
Podemos distinguir dos variantes principales del modelo que son:
• En cascada puro: Es el modelo de desarrollo de sistema clásico que consiste en

fases continuas:
1. Conceptualización
2. Definición de Requisitos
139
3. Diseño de arquitectura
4. Diseño detallado
5. Codificación y desarrollo
6. Pruebas e implementación
Este modelo funciona bien para productos con unos requisitos bien definidos y entendi-
dos o cuando se trabaja con herramientas técnicas, arquitecturas o infraestructuras bien
entendidas. Sus debilidades lo hacen ser desaconsejable cuando se necesita un desarrollo
rápido. En esos casos, otros modelos modificados pueden resultar más efectivos.
Fortalezas Debilidades
Minimiza la carga de planificación Inflexible

dado que se hace por adelantado
Sólo la fase final produce una entrega
La estructura minimiza el esfuerzo que no sea documentación
baldío lo que funciona bien para
plantillas inexpertas o débiles La vuelta atrás para solucionar errores
es dificultosa
Fortalezas y debilidades del modelo en Cascada Puro
Dato importante
El término Ingeniería del Software se volvió popular después de una conferencia

en 1968, cuando las dificultades y obstáculos para diseñar sistemas complejos se
estaban tratando de manera abierta. Comenzó pues una búsqueda de soluciones
que se concentró en mejores metodologías y herramientas.
• En cascada modificado: Este modelo emplea las mismas fases que el modelo puro,
pero no está basado en una base discontinua. Esto permite que las fases se solapen
cuando sea necesario. El modelo puro se puede descomponer en sub-proyectos en
una fase apropiada (como después del diseño de arquitectura o diseño detallado).
Es posible añadir espirales de reducción de riesgo en la cúspide de la cascada para
reducir riesgos antes de las fases en cascada.
140
El modelo puede modificarse aún más usando opciones como la realización de

prototipos, JADs o sesiones CRC o incluso otros métodos de toma de requisitos
hechos en fases superpuestas.
Fortalezas Debilidades
Más flexible que el modelo puro Los hitos son más ambigüos que en el
modelo puro
Si hay continuidad del personal entre
las fases la documentación se puede Las actividades se realizan en paralelo
reducir sustancialmente y son proclives a malentendidos y de
supuestos erróneos
La implementación de las funciones
sencillas no tiene que esperar por las Las interdependencias no previstas
complejas pueden crear problemas
Fortalezas y debilidades del modelo en Cascada Modificado
5.2.2.2. Modelo Iterativo

El problema con el modelo en cascada creó una demanda de un nuevo método de desa-
rrollar sistemas que pudiera proporcionar resultados más rápidos y que requiera menos
información por adelantado así como ofrecer una mayor flexibilidad. Con el desarrollo
iterativo el proyecto se divide en pequeñas piezas. Esto permite que el equipo de de-
sarrollo muestre resultados de manera temprana en el proceso y obtenga una valiosa
retroalimentación de información o comentarios críticos (feedback) sobre la experiencia
y opiniones de los usuarios del sistema. A menudo, cada iteración es un mini proceso en
cascada con el feedback de una fase proporcionando información vital para el diseño de
la siguiente fase.
En una variante de este modelo, los productos Software que se producen al final de cada
paso o conjunto de ellos, pueden subir a producción inmediatamente como versiones
incrementales.
5.2.2.3. Modelo o Método en V

Justo como el modelo en cascada, el ciclo de vida del modelo o método en V es un camino
secuencial de ejecución de procesos. Cada fase debe completarse antes de que comience
la siguiente. Se enfatiza las pruebas en este modelo más que en el modelo en cascada. Los
procedimientos de pruebas se desarrollan de manera temprana en el ciclo de vida antes
de que se realice cualquier codificación, durante cada una de las fases que preceden a la
implementación.
141
Los requisitos comienzan el modelo de ciclo de vida al igual que el modelo en cascada.
Antes, el plan de pruebas se centra en cumplir con las funcionalidades especificadas en
la toma de requisitos. La fase de diseño de alto nivel se centra en la arquitectura y diseño
del sistema. Es en esta fase cuando se crea un plan de pruebas de integración para probar
la capacidad que tienen los componentes de Software del sistema de trabajar conjunta-
mente.
La fase de implementación es de nuevo donde tiene lugar la codificación. Una vez que
se completa la codificación, el camino de ejecución continúa por el lado derecho de la V
donde los planes de prueba desarrollados anteriormente se ponen en funcionamiento.
Modelo de desarrollo de SW en V
Ventajas y Desventajas Modelo en V
• Es simple y fácil de emplear
• Cada fase tiene unos entregables específicos
• Existe mayor probabilidad de éxito que en el modelo en cascada dado el anticipado

desarrollo de planes de prueba durante el ciclo de vida
• Funciona bien para pequeños proyectos donde los requisitos son fácilmente en-
tendibles
142
Por otro lado, las desventajas que encontramos son:
• Resulta muy rígido como el modelo en cascada
• Tiene poca flexibilidad y el ajuste del alcance resulta difícil y caro
• El Software se desarrolla durante la fase de implementación por lo que no se pro-

ducen prototipos iniciales del Software
• Este modelo no proporciona un camino claro para los problemas que se encuen-
tren durante las fases de pruebas
5.2.2.4. Modelo en Espiral

El modelo en espiral lo introdujimos anteriormente como alternativa al modelo en casca-
da tradicional y es similar al modelo incremental con un énfasis mayor en el análisis de
riesgos. El modelo consta de cuatro fases:
1. Planificación
2. Análisis de riesgos
3. Ingeniería
4. Evaluación
Un proyecto de Software pasa de manera repetida por estas fases en lo sucesivas itera-
ciones (llamadas espirales en este modelo). La espiral de base comienza en la fase de
planificación, se recogen los requisitos y se evalúan los riesgos.
Cada espiral subsiguiente se construye sobre la espiral de base. Los requisitos se reco-
gen durante la fase de planificación. En las fases de análisis del riesgo, se lleva a cabo un
proceso para identificar el mismo y las posibles soluciones alternativas. Se construye un
prototipo al final de la fase de análisis de riesgo.
El Software se produce durante la fase de ingeniería, junto con las pruebas al final de la
fase. La fase de evaluación permite al cliente evaluar la salida del proyecto hasta la fecha
antes de que el proyecto continúe hacia la siguiente espiral.
En el modelo en espiral, el componente angular representa el progreso y el radio de la

espiral representa el coste.
143
Ventajas y Desventajas modelo en Espiral
• Una alta cantidad de análisis de riesgo
• Especialmente buen modelo para proyectos grandes y de misión crítica
• El Software se produce de manera temprana en su ciclo de vida
• Puede resultar ser un modelo costoso de usar
• El análisis de riesgos requiere una pericia altamente específica
• El éxito del proyecto es altamente dependiente de la fase de análisis de riesgos
• No funciona bien para proyectos pequeños
Sectores del modelo en espiral
Por otro lado, la espiral está divida por los ejes cartesianos en cuatro sectores:
1. Establecimiento de objetivo: Se identifican los objetivos específicos para la fase.
2. Evaluación y reducción del riesgo: Los riesgos se evalúan y se ponen en marcha las
actividades para reducir los riesgos clave.
3. Desarrollo y validación: Se elige un modelo de desarrollo para el sistema que puede

ser cualquiera de los modelos generales.
4. Planificación: El proyecto se revisa y se planifica la siguiente fase de la espiral.
Modelo en espiral Ganar-Ganar
El modelo original en espiral de Boehm (referido anteriormente) comenzaba cada ciclo

de la espiral realizando el siguiente nivel de elaboración de los objetivos del sistema pros-
pectivo, restricciones y alternativas.
Una dificultad principal en aplicar el modelo en espiral ha sido la falta de una guía explí-
cita del proceso para determinar esos objetivos, restricciones y alternativas.
144
El modelo en espiral ganar-ganar (Win-Win) utiliza el enfoque de esta teoría Win-Win

(W) para converger tanto en los objetivos del sistema de siguiente nivel como en sus res-
tricciones y alternativas. El enfoque de esta teoría W implica el identificar los interesados
del sistema y sus condiciones de ganar y utilizar procesos de negociación para determi-
nar un conjunto de objetivos, restricciones y alternativas mutuamente satisfactorio.
En definitiva, tal y como observamos en la figura el proceso de la teoría W de nueve pasos

se traduce en las siguientes extensiones del modelo en espiral:
1. Determinar objetivos: Identificar los interesados en el ciclo de vida del sistema y sus
condiciones de ganancia y establecer los límites del sistema iniciales y las interfaces
externas.
2. Determinar restricciones: Determinar las condiciones bajo las cuales el sistema

produciría unos resultados de ganancia-pérdida o pérdida-pérdida para algunos in-
teresados.
3. Identificar y evaluar alternativas: Solicitar sugerencias de los interesados, evaluar-

las con respecto a las condiciones de ganancia de los interesados, sintetizar y ne-
gociar las alternativas candidatas ganar-ganar, analizar, evaluar, resolver los riesgos
ganar-perder o perder-perder, registrar los compromisos y las áreas para ser flexibles
en el registro del diseño del proyecto y los planes de ciclo de vida.
4. Ciclo a través de la espiral: Elaborar las condiciones de ganancia, evaluar y cribar las
alternativas, resolver los riesgos, alcanzar los compromisos adecuados y desarrollar y
ejecutar los planes posteriores.
5.2.2.5. Modelo de Programación Extrema

El modelo de programación extrema (Extreme Programming, XP) es un enfoque de de-
sarrollo basado en el desarrollo y entrega de muy pequeños incrementos de funcionali-
dad. Depende de una mejora constante del código, la implicación del usuario en el equipo
de desarrollo y programación por parejas.
Entre las dificultades de este modelo cabe destacar que puede resultar difícil mantener le
interés de los clientes que están implicados en el proceso y que por otro lado los miem-
bros del equipo puede que no sean los adecuados para la implicación intensiva que carac-
teriza a los métodos ágiles.
La priorización de cambios puede resultar dificultosa donde existen múltiples interesa-

dos y también es de destacar que el mantenimiento de la simplicidad requiere trabajo
adicional. También, los contratos pueden ser un problema al igual que con otros enfoques
de desarrollo iterativo.
145
Prácticas de programación extrema
• Planificación incremental: Los requisitos se graban en tarjetas de historias y las

historias que se incluyen en una versión se determinan por el tiempo disponible
y su prioridad relativa. Los desarrolladores desglosan esas historias en tareas de
desarrollo.
• Pequeñas entregas: Se desarrolla primero el conjunto útil mínimo de funcionali-

dades que proporciona valor al negocio. Las versiones del sistema son frecuentes e
incrementalmente añaden funcionalidades a la primera versión.
• Diseño simple: Se lleva a cabo el diseño suficiente para cumplir con los requisitos
actuales y no más.
• Desarrollo de prueba primero: Se emplea un marco de prueba unitaria automá-

tica para escribir pruebas para un nuevo pedazo de funcionalidad antes de que la
funcionalidad en sí misma sea implementada.
• Refactorización: Se espera que todos los desarrolladores refactoricen el código

continuamente tan pronto como se encuentren posibles mejoras al código. Esto
mantiene al código simple y fácil de mantener.
• Programación en parejas: Los desarrolladores trabajan en parejas, comprobando

cada uno el trabajo del otro y proporcionando soporte para hacer un buen trabajo.
• Propiedad colectiva: Las parejas de desarrolladores trabajan en todas las áreas del
sistema, por lo que no existen islas de desarrollo experto y todos los desarrollado-
res son propietarios de todo el código. Cualquiera puede cambiar cualquier cosa.
• Integración continua: Tan pronto como el trabajo de una tarea está completo, se
integra en el sistema completo. Después de tal integración todas las pruebas uni-
tarias en el sistema deben tener éxito.
• Ritmo sostenible: No se consideran aceptables grandes cantidades de horas extra

ya que el efecto neto es a menudo la reducción de la calidad del código y produc-
tividad de término medio.
• Cliente in situ: Un representante del usuario final del sistema (el cliente) debería
estar disponible a jornada completa a disposición del equipo de XP. En un proceso
de programación extrema el cliente es un miembro del equipo de desarrollo y es
responsable de traer los requisitos del sistema al equipo para que se implementen.
146
Principios ágiles y de la Programación extrema
• El desarrollo incremental se sustenta a través de pequeñas y frecuentes versiones

del sistema.
• La implicación del sistema significa un compromiso con el equipo a tiempo com-

pleto.
• La gente se implica por medio de la programación por parejas, propiedad colectiva

y un proceso que evita largas jornadas de trabajo.
• El cambio se sustenta por medio de entregas (versiones) regulares del sistema.
• Mantenimiento de la simplicidad por medio de una constante refactorización del

código.
Modelo de desarrollo de Software Extremo (XP)
Ventajas e inconvenientes modelo programación extrema
Como ventajas podemos citar:
• Los métodos ligeros son adecuados para proyectos de tamaño pequeño o mediano
• Proporcionan una buena cohesión del equipo
• Enfatizan el producto final
• Son iterativos
• Tienen un enfoque basado en las pruebas para el aseguramiento de los requisitos

y la calidad
147
• Dificultad para escalar a grandes proyectos donde la documentación es esencial
• Se necesita experiencia y habilidades para que no degenere en un proceso de co-

dificación y arreglo
• Las parejas de programación son costosas
• La construcción de los casos de prueba es una habilidad difícil y especializada
5.3. Conclusiones
En los contenidos de esta unidad hemos tenido la oportunidad de repasar las distintas
alternativas de las que dispone una empresa para contar con una plataforma tecnológica
que sea una ventaja competitiva en su actividad a la hora de ofrecer sus productos o ser-
vicios a sus clientes, o incluso de producirlos gracias a estos medios.
La decisión entre las alternativas suele estar condicionada por el tipo de actividad que
realiza la empresa y lo que considera que son sus actividades clave, frente a aquellas que
las ve como secundarias o que no formen parte de su negocio.
No obstante, no siempre la decisión está clara y se hacen necesarias una serie de ayudas
para que las empresas puedan escoger el modelo más ajustado a sus necesidades, ca-
pacidades y objetivos. Este modelo podrá cambiar con el tiempo según evolucionen los
condicionantes.
Así, hemos podido observar los criterios de decisión entre las alternativas de adquirir una
solución externa, desarrollarla por nuestros medios o incluso el emplear una solución de
SW Libre.
En el caso de optar por la decisión del desarrollo interno del Software, es necesario cono-
cer los distintos modelos de desarrollo y analizar las ventajas e inconvenientes de cada
uno y así poder decidir cuál es el que mejor se adapta a nuestras necesidades.
148
6. Tecnologías y conceptos web

“El World Wide Web Consortium (W3C) crea y supervisa el desarrollo
de las tecnologías Web, incluyendo XML (Extensible Markup Langua-
ge), HTML (HyperText Markup Language) y sus numerosas aplica-
ciones.”
El mundo del World Wide Web (WWW) es uno de los que más transformaciones y más
rápidas ha sufrido en sus pocos años de vida.
Las empresas edifican sus negocios basándose en las competencias. El éxito de un nego-
cio depende de que lo haga mejor que sus competidores. Pero, ¿soy capaz de producir algo
único, más rápido, mejor, más barato?
El concepto de Web 2.0 puede cambiar la forma en la que uno ve esas competencias,
ayudando a encontrar nuevas (ofrecidas por terceros) y permitiéndonos compartir las pro-
pias.
La Web 2.0 promete grandes cambios, pero no necesariamente una revolución como los
visionarios de las “punto COM” habían esperado. Web 2.0 cambia las reglas del negocio,
pero no como un remplazo de los anteriores negocios a aquellos basados en la Web.
Las redes de alianzas de nuevo estilo más que remplazar o interrumpir las infraestructu-
ras de las compañías “Offline” tradicionales se centran en conectarse y construir nuevas
redes. Existen infinidad de oportunidades para conectar las innovaciones de ambos mun-
dos de negocios online y offline y los competidores potenciales pueden resultar ser socios
potenciales.
En las secciones siguientes introducimos algunos de los estándares y conceptos más im-
portantes del mundo Web actual y las tendencias que existen.
6.1. Estándares web

El World Wide Web Consortium (W3C) crea y supervisa el desarrollo de las tecnologías
Web, incluyendo XML (Extensible Markup Language), HTML (HyperText Markup
Language) y sus numerosas aplicaciones. También mantienen un ojo en temas de mayor
nivel como hacer el contenido accesible al mayor número de dispositivos y usuarios así
como establecer unos pilares comunes para el futuro desarrollo, lo que hace al contenido
Web “compatible hacia delante”.
149
El W3C no es un organismo oficial de estándares, sino un esfuerzo coordinado por ex-

pertos en campos relacionados con la Web para poner un poco de orden al desarrollo de
tecnologías Web. El W3C da su última palabra sobre cómo distintas cuestiones deberían
ser manejadas, por medio de documentos llamados “recomendaciones”.
La mayoría de sus recomendaciones se vuelve los estándares de facto para el desarrollo

Web. Existen otros organismos de estándares que también afectan a la Web y a Internet
en su totalidad, como son los siguientes:
• ISO (International Organization for Standardization): La ISO es una verdadera

organización de estándares que gestiona más de 10,000 estándares, incluyendo
cualquier cosa desde los sistemas de información y el conjunto de caracteres a
las dimensiones de una película o el tamaño del grano de las pegatinas. Su sello
de aprobación ayuda a mantener el comercio y las tecnologías de la información
compatibles a lo largo del mundo.
• IETF (Internet Engineering Task Force): El IETF es una comunidad internacio-

nal de diseñadores de red, operadores, fabricantes e investigadores preocupados
con la evolución de Internet en su conjunto. Publica las famosas solicitudes de
comentarios (Request for Comments, RFC) que definen cómo se hacen las co-
sas en Internet incluyendo FTP (File Transfer Protocol), TCP/IP (Transmission
Control Protocol/Internet Protocol), HTTP (Hypertext Transfer Protocol) y el
correo electrónico.
• Ecma International: Anteriormente conocido como ECMA (European Computer

Manufacturers Association) es una asociación europea para la estandarización
de la información y los sistemas de comunicación. Ecma Internacional gestiona los
estándares de tecnologías de la información, incluyendo ECMAScript, la versión
estandarizada de JavaScript.
• Unicode Consortium: Este consorcio gestiona el estándar Unicode para conjuntos

de caracteres multilenguaje.
• ANSI (American National Standards Institute): Cubre un amplio rango de ver-

daderos estándares incluyendo ASCII (American Standard Code for Informa-
tion Interchange).
6.1.1. El proceso de estandarización

Internet se construyó sobre estándares porque no es propiedad ni es operado por ninguna
persona ni compañía. Las decisiones con respecto a cómo se deben lograr las tareas se
han tomado tradicionalmente por medio de un esfuerzo cooperativo de invención, discu-
sión y finalmente adopción de la forma de gestionar una tarea específica.
150
Incluso antes de la Web, los estándares de Internet como los protocolos, sistemas de nom-
brado y otras tecnologías de redes se han gestionado por el IETF. El proceso comienza
cuando se identifica una necesidad de una funcionalidad (por ejemplo añadir adjuntos al
correo electrónico) y una persona o un grupo propone un sistema para hacerlo funcionar.
Después de una fase de discusión la propuesta se hace pública en forma de una RFC. Una
vez que se trabajan los obstáculos y se acuerdan las soluciones la tecnología se vuelve un
estándar. Esto por supuesto es una simplificación enorme, si bien nos sirve para explicar
someramente el proceso de trabajo.
La Web ha estado sujeta al mismo proceso de desarrollo que otro protocolo de Internet.
El problema era que la explosión de excitación y oportunismo de la Web inicial causó el
desarrollo de HTML y otras tecnologías para desplazar el ritmo tradicional de la aproba-
ción de estándares. Por lo que mientras que el W3C comenzó a trabajar en los estándares
de HTML en 1994, las compañías de Software no esperaron.
Para ganar control del mercado de navegadores, el navegador Netscape salió a escena
con su propio conjunto de etiquetas HTML propietarias que mejoraron vastamente la
apariencia de las páginas Web.
Microsoft finalmente respondió con su propio juego de etiquetas y características para

competir directamente y así es como nació la guerra de navegadores. Ambas empresas
son culpables de la mentalidad de “dar a la gente lo que quiere” sin importarles cómo
podría impactar a largo plazo. El problema se hizo aún mayor ya que el diseño Web creció
más allá del HTML simple para abarcar tecnologías Web más ricas como las hojas de es-
tilo (Cascade Style Sheets, CSS) JavaScript y DHTML (Dynamic HTML).
Como resultado hemos heredado un montón de etiquetas y tecnologías que funcionan

sólo en un navegador u otro así como elementos (como por ejemplo <Font>) que no hacen
nada para describir la estructura del documento. Este hecho chocaba directamente con la
intención original del HTML para describir la estructura del contenido de un documento
y no su presentación visual. Mientras que los estándares Web están mejor establecidos
ahora el W3C está aún en la tarea de compensar las cosas tras años de falso código aún
en uso.
De hecho, no llevó mucho a la comunidad de desarrollo decir “¡basta!” y demandar que

los creadores de navegadores se centraran y acataran las recomendaciones enunciadas
por el W3C. El campeón de este esfuerzo fue sin duda el Web Standards Project (WaSP,
www.webstandards.org), un colectivo de desarrolladores Web establecido en 1998 quienes
presionaron a los desarrolladores de navegadores, desarrolladores de herramientas y la
comunidad de diseño para ponerse de acuerdo.
151
La buena noticia es que las actuales versiones de navegadores han recorrido caminos
paralelos para soportar los estándares de lenguajes de marcas HTML y XHTML. Queda
alguna pequeña etiqueta específica de algún navegador pero al menos no se han creado
nuevas. El siguiente desafío es obtener un soporte consistente para las hojas de estilo
CSS.
6.1.2. Las ventajas de los estándares

Todavía estamos esperando por el día perfecto en el que los navegadores acaten fielmente
las recomendaciones del W3C pero este hecho no es una razón para dejar de crear conte-
nidos compatibles con los estándares. Los estándares ofrecen una pléyade de beneficios
de los que uno puede beneficiarse inmediatamente, como son:
• Accesibilidad: Tu contenido Web será visto ciertamente por una variedad de na-
vegadores y dispositivos. Además de los navegadores gráficos puede ser visuali-
zado por dispositivos alternativos como teléfonos móviles, portátiles, tabletas o
dispositivos de asistencia como lectores de pantalla para invidentes. Por medio de
la creación de documentos bien estructurados y lógicamente marcados de acuerdo
con las guías de accesibilidad uno es capaz de proporcionar una mejor experiencia
para el mayor número de usuarios.
• Compatibilidad hacia delante: Los estándares del futuro se construirán sobre los
actuales estándares. Por lo tanto, el contenido que sea estrictamente cumplidor
hoy disfrutará de una mayor longevidad en el día que se dejen de soportar la ma-
yor parte de elementos y atributos. ¿Por qué no construir los sitios Web de manera
correcta desde el principio?
• Desarrollo más rápido y simple: Durante años, los desarrolladores Web han ne-
cesitado hacer malabares para compensar las diferencias entre los navegadores,
algunas veces recurriendo a crear distintas versiones del todo el sitio Web para
poder lograr la compatibilidad. Un apropiado marcado de la estructura de los do-
cumentos y el uso estratégico de las hojas de estilo pueden permitirte crear una
única versión de tu contenido que sirva para todos los visitantes. Y dado que el
documento que controla el estilo visual es independiente del contenido, el dise-
ño y desarrollo editorial puede ocurrir en paralelo, acortando potencialmente los
tiempos de producción. Esto último mejora por lo tanto nuestro caso de negocio.
• Mayor velocidad de descarga y visualización: Los documentos que utilizan un

HTML no estándar para controlar la presentación (como tablas, etiquetas <font>
e imágenes transparentes) tienden a inflarse. Eliminando esos elementos y utili-
zando hojas de estilo CSS para controlar la presentación normalmente redunda
152
en ficheros más pequeños que descargan más rápido y que pueden añadir unos
ahorros importantes de ancho de banda. Además, los navegadores actuales repro-
ducen las páginas más rápido en modo estándar que en modo compatible. Páginas
más rápidas significa visitantes más felices.
6.1.3. Estándares actuales

El diseño y desarrollo Web se habla en términos de “capas” (y algunas veces como el “pas-
tel de capas”), tomando prestado el modelo de capas o niveles del empleado para describir
los protocolos de red.
El documento de marcas forma la capa estructural, que es la base sobre la cual se aplican
otras capas. La siguiente en venir es la capa de presentación especificada con las hojas
de estilo CSS, que proporciona instrucciones de cómo el documento debería verse en
la pantalla, como debería sonar cuando se lea en voz alta o estar formateado cuando se
imprima.
Por encima de estas capas, puede que se encuentre también una capa de comportamien-
to que abarca las secuencias de comandos (scripts) y programación que añaden interacti-
vidad y efectos dinámicos al sitio Web. A continuación presentamos de manera resumida
cada una de las capas:
1. Capa Estructural: Después de años de que los desarrolladores de navegadores se

volvieran locos creando etiquetas, la comunidad Web está retornando a la intención
original de HTML como un lenguaje de marcas, para describir la estructura del do-
cumento y no para dar instrucciones de cómo debería verse. Existen los siguientes
lenguajes estándar:
a. XHTML 1.0 y 1.1 y 2.0 (en desarrollo) (Extensible Hypertext Markup Langua-
ge): Siguientes generaciones de HTML atendiendo a las reglas de sintaxis de XML.
b. XML 1.0 (Extensible Markup Language): Es un conjunto de reglas para crear

nuevos lenguajes de marcas. Permite a los desarrolladores crear conjuntos a medi-
da de etiquetas.
2. Capa de presentación: Ahora que todas las instrucciones de presentación se han

eliminado del estándar de marcas esta información es exclusiva de las hojas de estilo
CSS. Los estándares CSS se desarrollan en fases:
a. CSS nivel 1: El estándar desde 1996 soportado por las actuales versiones de nave-
gadores. Contiene reglas para el control de la muestra de texto, márgenes y bordes.
b. CSS nivel 2.1: Esta recomendación es más conocida por añadirse del posiciona-
miento absoluto de los elementos de las páginas Web. El nivel 2.0 es recomenda-
ción desde 1998 y el 2.1 aún candidato y no es consistente en todos los navegadores.
153
c. CSS nivel 3: Se construye sobre el nivel 2 pero está modularizado para hacer más
fáciles futuras expansiones y permitir a los dispositivos soportar subconjuntos ló-
gicos. Está aún en desarrollo.
3. Capa de Comportamiento: Las secuencias de comandos y la programación de la

capa de comportamiento añade interactividad y efectos dinámicos al sitio. Está com-
puesta los siguientes elementos:
a. Modelos de Objetos: El modelo de objeto documento (Document Object Model,

DOM) permite a las secuencias de comandos y las aplicaciones acceder y actua-
lizar el contenido, estructura y estilo de un documento por medio de nombrar for-
malmente cada parte del documento, sus atributos y cómo ese objeto puede ser
manipulado. Al principio, cada navegador tenía su propio DOM, haciendo muy
difícil crear efectos interactivos para todos los navegadores. Tenemos dos nive-
les: El nivel 1 o de núcleo, que abarca los documentos HTML y XML así como la
navegación y manipulación del documento; y el nivel 2, que incluye un modelo de
objeto de hoja de estilo, haciendo posible manipular la información de estilo.
b. Secuencias de comandos (scripting): Netscape introdujo su lenguaje de scrip-

ting, JavaScript con la versión 2.0 de su navegador. Se llamó originalmente “Li-
vescript”, pero más tarde fue renombrado por Sun y se añadió la palabra “Java”.
Microsoft contaba con su propio JScript mientras que soportaba algún nivel de
JavaScript en la versión 3.0 de su navegador. Estaba claro que se necesitaba un
estándar. En la actualidad el W3C está desarrollando una versión estándar de Ja-
vaScript (1.5) en coordinación con el Ecma International.
4. Otras tecnologías basadas en XML: XML es un meta lenguaje empleado para crear
otros lenguajes de marcas y aplicaciones. Esto ha permitido el desarrollo de algunos
estándares especializados, como por ejemplo SVG (para gráficos), MathML (nota-
ción matemática), SMIL (presentaciones multimedia), etc.
6.2. SOA: Conceptos clave

La pregunta que nos hacemos al leer el título es ¿pero qué es SOA? La arquitectura orien-
tada a servicios (Service Oriented Architecture, SOA) es un concepto que muestra un
enfoque de la arquitectura IT orientado al negocio que soporta la integración de un nego-
cio como servicios o tareas de negocio enlazadas y repetibles.
SOA permite a las empresas actuales a innovar asegurando que sus sistemas de IT pue-
den adaptarse rápidamente, fácilmente y de manera económica para dar respuesta a los
cambios de necesidades del negocio. Ayuda a los clientes a incrementar la flexibilidad
de sus procesos de negocio, refuerza su infraestructura subyacente de TI y reutiliza sus
inversiones de TI por medio de la creación de conexiones entre aplicaciones y fuentes de
información dispersas.
154
La arquitectura orientada a servicios comienza con un servicio, definido como una tarea
de negocio simple (como por ejemplo comprobar el ratio de crédito de un cliente poten-
cial cuando se abre una nueva cuenta). Es importante señalar que estamos hablando de
una parte del proceso de negocio y no sobre Software o TI.
La orientación al servicio se centra en el negocio y en la manera que la empresa ve las dis-

tintas funciones que la constituyen. Podríamos pensar en descomponer el negocio de una
empresa en conjuntos de tareas de negocio que pudieran ser implementados por nuestros
servicios. Los servicios pues son como los bloques de construcción de los sistemas de TI
que soportan nuestros procesos de negocio. Si una empresa en particular se ve a sí misma
como un conjunto de servicios conectados para producir un resultado en particular, en-
tonces esa empresa utiliza un enfoque orientado a servicios para traer bienes y servicios
de alto valor al mercado.
SOA es un enfoque de arquitectura que sigue los principios de orientación al servicio

para hacer que los recursos de Software más flexibles y disponibles. SOA proporciona los
elementos tecnológicos necesarios para trabajar con servicios que no son sólo Software o
Hardware, sino tareas de negocio. Es un patrón para el desarrollo de una clase más flexible
de aplicaciones Software.
SOA está basado en estándares que permiten la inter-operatividad, la agilidad del nego-
cio y la innovación para generar más valor de negocio para aquellos que emplean estos
principios.
La mayoría de decisiones que las empresas toman para facilitar la innovación y flexibili-
dad se corresponden a necesidades rápidas de cambio del negocio. SOA hace el cambio
más fácil. La integración rígida de los sistemas de TI con un enfoque cortoplacista para
cumplir con las necesidades más inmediatas hace que el cambio sea más difícil, costoso
y largo. Por el contrario, SOA divide las TI en bloques de construcción que se montan y
reconfiguran fácilmente. Estos bloques se llaman servicios.
Dado que estos servicios se construyen sobre estándares abiertos, se pueden integrar
fácilmente con otros sistemas de TI sin miedo a un bloqueo del fabricante lo que fomenta
la reutilización.
Con esta nueva visión uno puede observar cómo SOA ayuda a las empresas a volverse
más ágiles permitiendo el alineamiento de las necesidades de negocio y las capacidades
de TI que soportan esas necesidades.
SOA en definitiva permite que el entorno de TI responda de manera efectiva y eficiente a

los requisitos de negocio. SOA ayuda a las empresas a aplicar la reutilización y flexibili-
dad lo que reduce los costes (de desarrollo, integración y mantenimiento), incrementa los
ingresos y obtiene una ventaja competitiva sostenible por medio de la tecnología.
155
Es importante señalar que SOA es una evolución y no una revolución. Aunque sus resul-
tados sean verdaderamente revolucionarios, se construye sobre muchas tecnologías que
se han estado empleando en el mercado, como los servicios Web, tecnologías transaccio-
nales, principios guía de la información, bajo acoplamiento, componentes, desarrollo y
diseño orientado a objetos, modelos orientados a eventos, EJB y .NET.
La belleza de SOA reside en que esas tecnologías existen juntas en SOA por medio de
estándares, interfaces bien definidos y compromisos de las organizaciones para emplear
los servicios clave en vez de “reinventar la rueda” cada vez. Ninguna de estas tecnologías
es SOA en sí misma. SOA no trata sólo de tecnología, sino cómo la tecnología y el negocio
se enlazan juntos con un objetivo común de flexibilidad del negocio.
A estas alturas ya deberíamos tener una idea a alto nivel de qué es SOA y lo que repre-
senta como visión. Pero nos falta un elemento esencial del que se vale SOA y que son los
servicios Web.
6.2.1. Servicios web

Un servicio Web es un sistema Software diseñado para soportar una interacción máquina
a máquina interoperable sobre una red de comunicación. ¿Qué significa todo esto?
Los servicios Web son frecuentemente interfaces de programación de aplicaciones

(Application Programming Interfaces, API) que pueden accederse a través de una red
como Internet ejecutados en un sistema remoto que aloja los servicios solicitados.
SOA es un estilo de arquitectura que permite la creación de aplicaciones que se cons-

truyen por medio de la combinación de servicios interoperables y poco acoplados. Estos
servicios interoperan basados en una definición formal o contrato que es independiente
de la plataforma subyacente y lenguaje de programación.
En SOA, debido a que la unidad básica de comunicación es un mensaje más que una ope-
ración, los servicios Web están normalmente poco acoplados. Aunque uno puede hacer
SOA sin servicios Web, las mejores prácticas de implementación de SOA siempre implica
a los servicios Web por el valor que proporcionan en términos de interoperatividad y
flexibilidad.
Técnicamente los servicios Web se basan en XML, dada su naturaleza de representación

común de datos que puede usarse como medio para intercambiar información entre pro-
gramas escritos en distintos lenguajes y ejecutan distintos tipos de instrucciones de má-
quina.
En pocas palabras, XML es el traductor oficial para la información estructurada. La in-

formación estructurada es tanto el contenido (palabras, imágenes,…) como el papel que
juega.
156
XML es la base de todos los servicios Web y la clave de la inter-operatividad. Toda espe-
cificación de servicio Web está basada en XML.
Los servicios Web tienen las siguientes características:
• Bajo acoplamiento: Parte del valor de SOA es que está construido sobre la premisa
del bajo acoplamiento de los servicios. El bajo acoplamiento trata de la capacidad
de los servicios para unirse juntos bajo demanda para crear servicios compuestos
o desencajarse tan fácilmente en sus componentes funcionales. Los servicios SOA
se unen de manera dinámica y flexible.
El bajo acoplamiento es simplemente una manera de asegurar que los detalles téc-
nicos como el lenguaje, plataforma y demás están desacoplados del servicio.
• Granularidad del servicio: De la experiencia de profesionales se sabe que el éxito

depende del diseño de los servicios y el enfoque del servicio. Un servicio es un
Software auto-contenido y reutilizable que es independiente de las aplicaciones
y las plataformas computacionales sobre las cuales ejecuta. Los servicios cuentan
con interfaces bien definidas y permiten una correspondencia 1:1 entre las tareas
de negocio y los componentes precisos de IT necesarios para ejecutar la tarea.
Los servicios SOA se centran en las tareas de nivel de servicio, actividades e inte-
racciones. La relación de un servicio con un proceso es crítica. Un proceso de nego-
cio es un conjunto de tareas de negocio relacionadas que incluyen a las personas,
sistemas y la información para producir un resultado o producto específico. Con
SOA, un proceso se compone de un conjunto de servicios. Antes de SOA, el foco
se centraba en sub-tareas técnicas de menor calado. Seguramente hayáis oído de
gente que llama a esto un fino “nivel de granularidad” o bajo “nivel de abstracción”.
Por motivos de simplicidad en SOA sabemos que hay más que una simple relación
uno a uno entre los pasos de un proceso y los servicios que se han diseñado para
soportar ese proceso de negocio flexible.
Toda empresa tiene una visión distinta de cómo de granular necesita ser su ser-
vicio, basado en su propio diseño de negocio. De manera simple, podemos definir
la granularidad como la cantidad de función que un servicio expone. Por ejemplo,
un servicio de grano fino o de elevada granularidad proporciona mayor cantidad
de pequeñas unidades de un proceso de negocio y uno de grano grueso o menor
granularidad proporciona una tarea de negocio mayor, que contiene un mayor nú-
mero de sub-pasos.
En definitiva, hay que recordar que la granularidad es siempre una función de la

descomposición del proceso de negocio, cuanto más detallado sea el proceso de
negocio, mayor granularidad tendrán los servicios.
157
Es importante denotar que este concepto de servicio es una de las claves de hacer SOA
el lenguaje del negocio. La mayoría de los directivos de las empresas no podrían preocu-
parse menos por SOA. En vez de eso, se centran en el problema que tienen frente a sus
ojos y si cabe.
Gracias a estos servicios de negocio, el lenguaje empleado y el enlace entre los servicios
de negocio se convierten en una pieza esencial de la solución al problema que se tiene
entre manos y al de la misión estratégica futura.
6.3. Web 2.0 y Mash-ups

Hasta ahora hemos hablado de la arquitectura orientada al servicio o SOA, pero ¿qué es
Web 2.0, PHP, AJAX y la plétora de otros términos de TI que existen hoy en día? SOA
es la clave de la flexibilidad del negocio y de TI y por lo tanto es la clave de descubrir el
potencial de un negocio.
Web 2.0 es un concepto que trata sobre la conexión de la gente e ideas a través de comu-
nicaciones que son eficientes y en tiempo real.
Los mecanismos de comunicación varían, desde podcasts, wikis y feeds hasta las redes
sociales. La flexibilidad es el impulsor clave del éxito de la Web 2.0, por medio de una
entrega flexible de datos a través de una combinación de servicios y dispares fuentes de
datos por medio de mash-ups, feeds de datos en tiempo real y ricas interacciones.
En última instancia, la Web 2.0 es la conductora del consumo de servicios. La clave está
en unir la flexibilidad de la Web 2.0 a los principios de la orientación al servicio del bajo
acoplamiento, encapsulación y reutilización que son el corazón y alma de SOA. SOA y
Web 2.0 no sólo son para los fanáticos de las tecnologías, sino que está hecha para todo
aquel que utilice las ricas colaboraciones y comunicaciones del Internet de hoy en día.
El enlace entre la Web 2.0 y SOA es importante que se entienda por las empresas. La Web
2.0 está compuesta por muchas tecnologías “habilitantes”, como PHP, AJAX, RSS, REST
y otras más.
La plataforma Web está evolucionando desde una interconexión transaccional de compu-

tadoras a la Web 2.0, lo que permitirá a las empresas interaccionar con sus clientes en ma-
yor cantidad de formas, más eficientes y colaborativas. Esto a su vez está abriendo nuevas
oportunidades para los servicios empresariales, servicios aplicativos, servicios
Software y servicios de infraestructura. El hecho de habilitar las funcionalidades Web 2.0

requiere una mayor flexibilidad de las infraestructuras, que puede ser sostenida por una
robusta arquitectura orientada al servicio.
158
Dado que resulta de vital importancia entender el vínculo entre SOA y Web 2.0 nos pro-
ponemos definir los principios básicos de Web 2.0 y su proposición de valor para después
los puntos de unión entre ambos conceptos.
6.3.1. Definición de Web 2.0

Según diversas fuentes, el término Web 2.0 se refiere a una segunda generación de servi-
cios disponibles en la WWW que permite a las personas colaborar y compartir informa-
ción en línea.
En contraposición a la primera generación, Web 2.0 proporciona a los usuarios una ex-
periencia más cercana a aplicaciones de escritorio que las tradicionales páginas Web es-
táticas.
Las aplicaciones Web 2.0 comúnmente pueden emplear una combinación de técnicas, in-
cluyendo APIs de servicios Web públicas, AJAX y sindicación Web. Estas técnicas permi-
ten publicaciones masivas (Software social basado en la Web). El concepto incluye blogs
y wikis.
La misma Wikipedia es un uso de las técnicas de Web 2.0 y las filosofías sociales y cola-
borativas. El diccionario está impulsado por el contenido proveniente de fuentes de todo
el mundo.
159
Dato importante
El paraguas de la Web 2.0 es muy amplio también, de hecho virtualmente cualquier

cosa que permita una función modular pueda ser entregado al usuario en un rico
contexto Web se denomina “Web 2.0”. Estos componentes comparten normalmente
una característica: Se pueden montar fácilmente entre sí para proporcionar una
experiencia enriquecida del usuario en un contexto de navegación Web.
Redes Sociales
Linkedin, Facebook, Orkut MySpace, Friendster
Tecnología que permite a los usuarios
mejorar las relaciones personales
RSS
Bloginess, Yahoo!, Feed
NewsGator
Un estándar XML que permite a los Burner, Pluck
usuarios recoger y leer contenidos
OSS
The Apache SW OpenOffice.org, Linux,
SW público que puede ser copiado y Foundation MySQL
modificado sin pago
Blogs
TypePad, MSN Spaces,
Blogger, Xanga, Gawker
Diarios online de texto, fotos y otra Weblogs.com
multimedia
Ask.com
Motores de búsqueda
MSN, Google, Yahoo, Bing Technorati
Servicios que encuentran contenido Web
basado en criterios del usuario
America Online
Portales de opinión
TripAdvisor, Insider
Pages, CNET.com,
Portales Web que permiten a los usua- Review Center
rios buscar opiniones de un producto o
GameRankings.com
servicio
Compartición de archivos P2P Bittorrent
Compartir archivos multimedia por medio HoZoA

de redes de usuario que actúan tanto de
cliente como servidor Gnutella.com
Amazon.com
Comercio-e C2C
eBay
Compras y ventas entre consumidores

craiglist
por la red
uBid.com
160
PriceGrabber.com
Sitios de comparación de compras
Froogle
Sitios que permiten a los consumidores
comparar productos o servicios
Shopzilla
Odeo
Podcasts
PodShow
Video o audio online que los usuarios

Podcast Alley
pueden descargar a un dispositivo
Juice
JotSpot
Wikipedia
Wikis / SW de colaboración
Groove Networks
SW de publicación compartida o sitio que
permite a los usuarios editar contenido
Basecamp
Socialtext
Del.icio.us
Etiquetado Flicker
Metadatos asignados a elementos como BEA

fotos o páginas Web que facilitan la bús-
queda y el intercambio Shadows
Digg
Alguno de los servicios disponibles en la Web 2.0
Para definirlo con palabras sencillas, Web 2.0 es la madurez de la Web que ha estado con
nosotros durante algún tiempo.
A lo largo de la última década, la siempre salvaje frontera de la Web ha sido poco a poco
tranquilizada para conformar un práctico conjunto de principios de diseño que guían la
creación de nuevas tecnologías, estándares y modelos de negocio y que están redibujan-
do los fundamentos de TI.
El énfasis está en la simplicidad, velocidad en crear valor, soluciones que incluyen al usua-
rio final (el fin de la distinción entre “desarrollador” y “usuario”), construcción de comu-
nidades y sobre todo un énfasis especial en la función de Software entregada en forma de
servicios de red.
161
Subyacente a la popularidad de la Web 2.0 está la tendencia en crear medios enriquecidos

(Rich Media) por medio de una integración flexible de fuentes de datos dispares y servi-
cios nacidos en Internet. La proposición de valor de la Web 2.0 es similar a la de SOA, que
es permitir que el cambio ocurra sin demasiado sufrimiento.
También y de similar manera a SOA es necesario un cambio cultural. La adopción de la

Web 2.0 ha crecido gracias a una comunidad creciente de desarrolladores, incluyendo de
las líneas de negocio, departamentales y los consumidores. Todos ellos se entusiasman
enormemente con las posibilidades que ofrece la Web 2.0 de componer procesos finales y
crear aplicaciones a partir de los servicios que se ofrecen.
La Web 2.0 trata sobre la creación de relaciones. Dado que los sitios Web son sociales,
los usuarios interactúan entre ellos y las empresas pueden interactuar directamente con
sus consumidores. Esta forma de interacción es diferente del pasado porque las empresas
están proporcionando y recibiendo información en tiempo real de nueva e innovadoras
formas. Todo esto trata en fin de redes sociales (social networking) “muchos a muchos”,
en vez relaciones “uno a uno” con el usuario.
Web 2.0 habilita el cambio de una forma cultural diferente, presentando Software que se
vuelve mejor cuanta más gente lo use, servicios, Software sin embalar, participación, pu-
blicación informal (como los blogs) y pequeñas piezas con bajo acoplamiento.
La filosofía de la Web 2.0 es que la interacción social es la reina. El blogueo sobre temas
calientes conduce a la socialización y a la sabiduría de las masas. La Web como una pla-
taforma está construida sobre comportamientos en boga como la apertura, la confianza y
una filosofía de estar permanentemente en versión beta.
Colectivamente, estas ideas conforman una rica conversación sobre la forma en que dise-
ñamos y empleamos la tecnología para ayudarnos a crear valor. Estas ideas representan
un movimiento desde aplicaciones a servicios, desde local a la red, desde concentrado
a distribuido y lo que es más importante, del diseño de Software orientado a la tarea al
orientado al proceso.
6.3.2. Mash-ups
El paraguas de la Web 2.0 es muy amplio también, de hecho virtualmente cualquier cosa
que permita una función modular pueda ser entregado al usuario en un rico contexto Web
se denomina “Web 2.0”. Estos componentes comparten normalmente una característica:
Se pueden montar fácilmente entre sí para proporcionar una experiencia enriquecida del
usuario en un contexto de navegación Web.
162
Los sitios Web como Flickr, Gmail u otros permiten al usuario una experiencia de mucho
más nivel que lo que se podría esperar de un sitio Web. Estos sitios Web 2.0 es lo que
se denominan Mash-ups. El término surgió cuando los DJs unieron juntos pedazos de
distintas canciones para crear una nueva canción. En el mundo de la Web 2.0 un mash-up
es una aplicación Web compuesta de rápida creación que combina capacidades de aplica-
ciones Web existentes de una nueva forma para de esta forma crear valor para el usuario.
Los mash-ups representan el puente práctico entre SOA y Web 2.0. Si un mash-up Web 2.0
representa la venida conjunta de información desde fuentes dispares, la infraestructura
SOA proporciona esas fuentes de información. Los servicios SOA escalables, dinámicos
y accesibles por la Web son la materia prima para los mash-up Web 2.0.
Por ejemplo, la que ofrece tecnología Flickr se ofrece como un mash-up. La navegación
geográfica de fotografías se hace como un mash-up. El resto se hace con AJAX (lo vere-
mos en breve) y tecnología Web pura. Sin embargo, Flickr está normalmente embebido
dentro de los mash-up ofrecidos por servicios de otras empresas.
Juntos SOA y Web 2.0 cumplen la promesa de la flexibilidad y la agilidad para los pro-
cesos de negocio. Los mash-ups de Web 2.0 proporcionan el marco ideal para conseguir
levantar esos bloques de construcción de los procesos de negocio y así ser capaces de
proporcionar la información a la gente de manera rápida y flexible.
En el contexto empresarial, Web 2.0 permite a los trabajadores que no poseen conoci-
mientos técnicos construir de manera ad-hoc aplicaciones mash-up empresariales cola-
borativas por sí mismos para solventar las necesidades inmediata del negocio.
Por medio del uso de herramientas intuitivas y ya disponibles como los tableros mash-up
pueden ensamblar contenido existente, unirlo junto y compartirlo con sus colaboradores
clave, clientes y socios de negocio y así facilitar el negocio de una nueva y excitante ma-
nera.
6.4. REST y AJAX: La ventaja de la flexibilidad

Es frecuente que diversas fuentes se refieran al diseño de la Web 2.0 como como un enfo-
que innovador de abajo a arriba (Bottom-up) dirigido desde el punto de vista del usuario
o consumidor. La innovación requiere cambio y el cambio conduce a la necesidad de fle-
xibilidad, por lo que podemos observar el valor de utilizar Web 2.0 mientras se rentabiliza
la flexibilidad de SOA.
163
Innovación dirigida por el

Innovación Tradicional
consumidor
Fuente de inspiración Ejecutivos Consumidores
Activos existentes, productos Profunda observación de las

Elementos clave
y posicionamiento necesidades del consumidor
Implicación del consumidor Estructurada Expontánea
Proceso Lineal, estructura Caos controlado
Postura corporativa Salir hacia el consumidor Invitar a entrar al consumidor
Necesidad de evaluación Explícito Explícito y Latente
Encuestas, grupos de Búsqueda, email, blogs,

Herramientas
enfoque, guiones Intranets y Smart POS
Cambio de la innovación de top-down a bottom-up
Por ejemplo, la Web 2.0 utiliza una versión ligera de una orientación al servicio llama-
da Transferencia de Estado Representacional (Representational State Transfer, REST).
REST se ha convertido quizás en la forma de orientación de servicio más ampliamente
desplegada debido a su simplicidad. Resulta también más sencillo hacer un mashup o
crear valor por medio de una novedosa combinación de otros servicios basados en REST,
permitiendo de esta forma que las TI permiten el cambio y la flexibilidad. Sin un entorno
SOA robusto, la demanda de trabajadores cualificado, dado que son ellos quienes crean
las aplicaciones dinámicas, puede causar fallos de índole crítica.
Con el incremento de la flexibilidad, los requisitos de usabilidad también se ven incre-

mentados. Con el uso combinado del JavaScript asíncrono y XML, conocido como AJAX,
la usabilidad de un sitio puede ser de una magnitud enormemente mayor que la de un
sitio síncrono.
AJAX no es realmente nuevo, pero es una combinación de tecnologías existentes: XML-

HttpRequest, JavaScript, CSS y XML. AJAX es asíncrono por lo que permite peticiones
al servidor dentro de la página por lo que no es más necesario refrescar la página entera
cuando deseas que el usuario interactúe con el servidor.
Tanto AJAX como REST son habilitadores para SOA. REST puede usarse para exponer
los servicios y AJAX para construir interfaces de usuario. REST es un enfoque ligero para
interconectar interfaces y servicios de Internet públicos y se aconseja el uso de servicios
más estructurados en sistemas finales. REST tiene sus ventajas e inconvenientes también.
Es más fácil porque está menos estructurado, pero la falta de estructura es un problema
para las empresas que apuestan su negocio al SOA para sus funciones de negocio críticas.
La mayoría de las empresas necesitan saber que sus interfaces y la semántica de invoca-
ción están bien documentadas y que se están haciendo cumplir.
164
Esta es la razón por la que la combinación de SOA y Web 2.0 puede volverse el nuevo
lenguaje del negocio. Este enfoque consigue mayor velocidad de entrega, afinidad con los
clientes y un mayor retorno de la inversión para las iniciativas Web.
6.5. La Web como la nueva plataforma y nuevos modelos de negocio

Echando la vista atrás, las empresas han ido depositando su confianza en distintas pla-
taformas que les han permitido competir en el mundo de los negocios con una ventaja
tecnológica. Empezando con la era del mainframe, pasando por por la de cliente/servidor
y moviéndonos a la era de Internet el valor de las plataformas ha cambiado con el avance
de la tecnología.
SOA permite que estas plataformas compitan por el éxito, con los fabricantes de SOA
jugando un papel como meros participantes y facilitadores para otros como Yahoo!, Ama-
zon y otros que ofrecen “servicios” en el mercado. Estos cambios han permitido a las em-
presas a magnificar el valor su posición en el mercado por medio de una innovación en el
ecosistema y en la inversión.
Tenemos ejemplos como MySpace.com, Facebook.com, Google+ o Tuenti que llevan in-
trínsecas muchas de las filosofías de la Web 2.0 al tratarse de sitios Web de redes sociales
que ofrecen una red interactiva de blogs, perfiles, grupos, fotos, MP3s y videos junto con
sistema de correo interno, chat y otras aplicaciones impulsadas y alimentadas por los
propios usuarios.
Otro ejemplo significativo lo constituye Youtube.com (adquirido por Google en 2006),

en el que los usuarios pueden “colgar” videos que pueden ser visionados por cualquiera,
convirtiéndose cada usuario en un emisor de contenidos.
La pléyade de aplicaciones y servicios que se ofrecen en la Web 2.0 junto con SOA produ-
cen un impacto en las estructuras económicas de los negocios.
Por ejemplo, los departamentos de publicidad y ventas verán impactados todos sus pro-
cesos. La nueva red de influencia que crea la Web 2.0 por medio de blogs, redes sociales,
comunidades virtuales, wikis y demás crea una nueva forma de relacionarse de las em-
presas con sus clientes. Incluso el hecho de mantener una relación en línea con alguien a
quien nunca has conocido es un paradigma interesante.
Merece la pena profundizar en la psicología de este tipo de interacciones espontáneas,

anónimas y aún así instantáneamente personales y lo que puede suponer para los nego-
cios, tanto en términos de publicidad como de ventas pero también en términos de aten-
ción a los clientes y el mantenimiento del control de cuentas y la lealtad.
165
En el camino de las empresas por alcanzar la deseada flexibilidad, Web 2.0 y SOA ahora
permiten una nueva clase de publicidad. Este nuevo modelo de negocio permite mode-
los de relaciones orientadas a las comunidades y unas ventas más orgánicas. Dadas las
nuevas formas en las que los usuarios o consumidores se relacionan con los proveedores
de esos servicios que demandan, una comunidad que quiera probar antes de comprar
supone un desafío para esta nueva generación de vendedores.
Dentro del mundo de las TI, el tiempo del ciclo de desarrollo se acorta y el tiempo de co-
mercialización se convierte en un factor crítico de éxito. Con las capacidades de mashup,
incluso los pequeños y medianos negocios son capaces de producir poderosas funciona-
lidades de negocio a un coste razonable. Si unimos esto al valor de SOA podemos vislum-
brar un futuro de máxima flexibilidad.
Por ejemplo, una pequeña empresa que ofrece una innovadora aplicación online puede
utilizar servicios que ofrece un gigante del mercado como los servicios en la nube de
Amazon.com para mantener una plataforma que le permita servir su producto o servicios
a sus clientes, con lo que puede empezar a ser capaz de dar servicio en poco tiempo y
acelerar con ello la obtención del ROI.
Los usuarios finales también experimentan un cambio de expectativas. Hemos comenza-

do ya a ver los efectos de la economía digital en nuestras vidas y con la facilidad de los
mashups hasta los usuarios finales son capaces de desarrollar sus propias creaciones de
las aplicaciones que les permitan cumplir con sus objetivos de negocio.
Esto indica que los directivos y emprendedores de nuevos negocios deben pensar a tra-
vés de los nuevos patrones y ver al mundo con este nuevo filtro de flexibilidad. En este
sentido, podemos enumerar una serie de nuevas reglas que rigen los negocios en la red
de nueva generación:
• Sirven la necesidad individual de los individuos
• Se produce una adopción orgánica y expansión viral
• Proporcionan información personal y contextualizada
• Crean valor instantáneamente
• Hace unos de las relaciones sociales y de comunidad para entender al usuario y

colmar sus necesidades
166
6.6. Conclusiones
El mundo Web ha tenido un crecimiento y evolución espectacular que no ha estado exen-
to de las distintas fuerzas de intereses que afectan a otras actividades o sectores. Gracias
al esfuerzo desinteresado de los iniciadores del WWW y la filosofía imperante de aper-
tura y colaboración las herramientas y tecnologías con las que se han ido constituyendo
la Web han ido sufriendo un proceso de estandarización que nos permite comunicarnos
mejor, de una manera más consistente y común y facilitar así la creación de valor por
cualquier participante, ya sean empresas o usuarios comunes.
En resumen, el foco se centra en el valor de la información, ideas o creaciones que se

intercambian, transforman o dan nuevos usos más que en un poder político, económico
o cultural establecido.
En definitiva, este proceso ha resultado ser una forma de socializar y democratizar el

mundo en niveles insospechados hasta ahora (recordamos el caso de las revoluciones
del mundo árabe y su impulso en redes sociales) por medio de tecnologías estándar más
abiertas, accesibles, modulares e inter-conectables.
Dado que la innovación necesita el cambio y éste conduce a la necesidad de flexibilidad,

el valor de emplear Web 2.0 con una arquitectura basada en SOA consigue que nuestros
entornos tecnológicos sean más flexibles y estén preparados para el cambio. Web 2.0 y
SOA tratan de unir servicios preexistentes en nuevas y útiles aplicaciones de negocio. La
conexión en las tecnologías está clara: tanto AJAX como REST son habilitadores para
SOA. Como ya comentamos REST se emplea para exponer servicios y AJAX para cons-
truir frontales de usuario.
Los impactos en el negocio incluyen la reducción de los esfuerzos globales del desarrollo,
mejoras en la funcionalidad, la promoción de la consistencia de los datos y la mejora en la
respuesta al cliente, lo que añade valor.
Es imprescindible que los líderes de las empresas de hoy en día comprendan lo que supo-
ne Web 2.0 y SOA y los impactos que tienen en la constitución de la Web como la nueva
plataforma y los nuevos modelos de negocio, usuarios finales y otros grupos internos que
constituyen una parte crítica de la futura competitividad de la compañía.
En definitiva, el mundo al que se tiende con el matrimonio entre SOA y Web 2.0 es lo que
llamamos “flex-pon-sivo” (respuesta flexible).
167
CEUPE
Centro Europeo de Postgrado
Web
www.ceupe.es
E-mail
info@ceupe.es

MMCD - A3 - Mod11 - Tecnología Aplicada A La Empresa 2.0 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MMCD - A3 - Mod11 - Tecnología Aplicada A La Empresa 2.0 PDF

Загружено:

Авторское право:

Доступные форматы

Módulo

1. Introducción a las tecnologías de

• El exponencial avance de las tecnologías que soportan la infraestructura del nú-

• Las mejoras en capacidad, fiabilidad y velocidad de las llamadas “tecnologías de

• Las mejoras en capacidad (memoria, proceso,…), portabilidad, usabilidad (pantallas

TIPOS DE EMPRESAS POR CAPAS DE ECONOMÍA DE INTERNET

1.1. Internet y su utilidad en el ámbito empresarial

Si bien la red nació con un propósito militar-estratégico y posteriormente evolucionó

El fenómeno de las llamadas “redes sociales” resulta importantísimo y merecería un ca-

1.1.1. Modelos más representativos de e-Business

En esta fuente se indica que un “modelo de negocio” se refiere al plan implementado

1.1.1.1. El mercado electrónico : actores y categorías

Un mercado electrónico permite la participación de vendedores y compradores para

Los mercados electrónicos tienen tres funciones principales:

• Unir a compradores con vendedores

• Facilitar las transacciones comerciales

• Proporcionar una infraestructura legal

Las tecnologías de la información impregnan las tres funciones y ayudan a mejorar la

Internet y la WWW (o simplemente “la Web” permiten a las empresas implementar

Como ejemplo, muchos servicios de búsqueda y agentes comerciales están disponibles

Servicios del Mercado Electrónico

Las empresas, individuos y organizaciones gubernamentales son los principales actores

Actores del mercado electrónico

• Business-to-Customer (B2C) y Customer-to-Business (C2B).

• Customer-to-Costumer o Citizen-to-Citizen (C2C)

• Government-to-Business (G2B) y Business-to-Government (B2G).

• Government-to-Citizen (G2C) y Citizen-to-Government (C2G)

Es notorio que tradicionalmente es siempre mayor la prevalencia de relaciones “top-

Business to Business (B2B)

Business to Customer y Costumer to Business (B2C/C2B)

Empresa a cliente/consumidor y viceversa. Esta categoría está representada principal-

Customer to Customer o Citizen to Citizen (C2C)

Consumidor a consumidor o ciudadano a ciudadano. Los mercados C2C están formados

Government to Business y Business to Government (G2B/B2G)

Además de las adquisiciones públicas, las organizaciones gubernamentales pueden ofre-

Government to Citizen y Citizen to Government (G2C/C2G)

Government to Government (G2G)

En un mercado B2C de información la infraestructura electrónica no sólo ayuda a juntar a

Los servidores, redes y Software deberían proporcionar la infraestructura para integrar

Cadena de valor y relación entre mercados B2B y C2C

• Descubrimiento de producto por medio de búsqueda y navegación

En algunos casos puede existir la resolución de disputas y servicios al cliente.

1.1.1.2. Tipos de modelos de negocio electrónico

A día de hoy podemos encontrar multitud de tipologías de modelos donde destacamos

Modelos tipo Correduría/Agencia (“Brokerage Model”)

• Intercambio de mercado (Marketplace Exchange): Ofrece un completo rango

• Cumplimiento de compra/venta (Buy/Sell fulfillment): Toma las órdenes del

• Sistema de recolección de demanda (Demand Collection System): El modelo

• Agente de transacciones (Transaction Broker): proporciona un mecanismo de

• Distribuidor: Es una operación de catálogo que conecta un alto número de fabri-

• Agente de búsqueda (Search Agent): es un agente Software o “robot” que se uti-

• Mercado o centro comercial virtual (Virtual Marketplace): es un servicio de

Modelos tipo publicitario

• Portal: Normalmente es un motor de búsqueda que puede incluir una variedad de

• Clasificados: Se trata de sitios que anuncian productos o servicios a la venta o que

• Pago por posicionamiento en buscadores: Vende una posición favorable de los

• Publicidad contextualizada / Marketing basado en comportamiento: Desarro-

• Intromerciales: Anuncios animados a pantalla completa localizados a la entrada

• Ultramerciales: Anuncios en línea interactivos que requieren que el usuario res-

Modelos tipo Infomediario (Intermediario de información)

Algunas firmas actúan como infomediarios ayudando a compradores y/o vendedores a

• Servicios de Medición de Audiencia: Agencias de investigación de mercados de

• Publicidad por incentivos: Programas de fidelidad de los consumidores que les