Blog de Fernando Machado Piriz

Artículos sobre transformación digital, arquitectura empresarial y temas relacionados

Las bases de la transformación digital: “todo definido por software” y “todos programan”

leave a comment »

Parece haber un acuerdo acerca que la transformación digital se trata menos de tecnología y más sobre diseño del negocio y sobre cultura centrada en el cliente. Obviamente no se trata de tecnología digital: los DVD, como su propio nombre lo indica, son contenedores de películas digitales en lugar de cintas de vídeo analógicas o películas en celuloide, pero no fue hasta que Netflix añadió video a demanda a través de Internet al negocio de entrega física de DVD, que se convirtió en una referencia en transformación digital.

Como George Westerman et al. han puesto claramente en este libro -o en este artículo que lo resume-, es la intensidad de la gestión transformacional, es decir, cuánto están apostando los altos directivos a la transformación digital, lo que separa los “digiratis” -maestros digitales- del resto de los mortales. Sin embargo, las empresas todavía necesitan pensar en las bases para la transformación digital, y precisamente allí es donde las plataformas digitales tienen su lugar; dicho de otra forma, una plataforma digital no hará transformar digitalmente una compañía, pero una compañía no puede transformarse sin una plataforma digital.

¿Qué son esas plataformas digitales? Son lo que hace que pueda funcionar sin fricción un negocio que involucra a los titulares de la empresa y sus socios, y que a su vez permite que la empresa participe en otros negocios “para [que la organización pueda] ejecutar su estrategia de negocio digital”, según Gartner.

Hace un tiempo las computadoras eran una cosa física; ahora existe la virtualización de hardware por software y en consecuencia tenemos máquinas virtuales. También hace un tiempo teníamos matrices de discos duros, y ahora tenemos almacenamiento definido por software; teníamos cables físicamente conectados, enrutadores, cortafuegos, etc. y ahora tenemos redes definidas por software; y la lista continúa hacia cosas muy grandes como los centros de cómputo definidos por software o hacia cosas muy pequeñas como los chips definidos por software o, más precisamente, matrices de puertas lógicas programables en terreno.

Incluso los dispositivos IoT, que son comunes en muchas empresas que se transforman digitalmente, pueden cambiar sus comportamiento basados en el software que ejecutan; cuanto menos inteligente sea el dispositivo, mayor será la duración de su batería, pero menor será su capacidad de ejecutar software sofisticado, o incluso ejecutar software a secas; pero conecte el dispositivo a la nube a través de una puerta de enlace para IoT, y entonces tendrá también su IoT definido por software.

Estas plataformas digitales tienen otra característica interesante: para lograr agilidad y facilidad de adaptación, no sólo permiten cambios sino que los alientan, haciendo que sean más fáciles. Las reglas [de negocio] que controlan el comportamiento de las aplicaciones que se ejecutan en estas plataformas pueden ser cambiadas de forma declarativa -a diferencia de imperativas o algorítmicas-, eventualmente a través de una interfaz de usuario gráfica manejada por algún usuario de negocio, no por un programador. Es declarativo, pero sigue dando órdenes a una computadora para hacer algo, así que sigue siendo programación.

Los usuarios finales que hacen las pruebas de aceptación no necesariamente usan la aplicación en sí para ver si funciona como debería. Probablemente no lo hagan lo suficientemente rápido y probablemente no estén dispuestos a hacerlo tantas veces como sea necesario para poder entregar nuevas versiones de la aplicación cada día o varias veces al día. Entonces la única manera es pedirles que declarativamente especifiquen cómo hacer las pruebas, en lugar de hacer las pruebas por sí mismos. Una vez más, es declarativo, pero sigue siendo programación.

Entonces resulta que tenemos usuarios finales codificando, ya sea adaptando aplicaciones que se ejecutan en plataformas digital para hacer cosas diferentes o incluso cosas nuevas, o ya sea para asegurarse que las aplicaciones funcionan como quieren, pero también hay más gente programando: los operadores de las plataformas.

Los operadores suelen escribir scripts para realizar tareas repetitivas. Alguien me dijo alguna vez “cuando quieras que la computadora haga algo, ejecuta los comandos; cuando quieras que haga lo mismo de nuevo, piensa en escribir un script y luego ejecuta los comandos; cuando quieras que haga lo mismo por tercera vez, escribe un script que ejecute los comandos por ti”. Es más rápido ejecutar el script que escribir los comandos, pero todavía más importante, los scripts no se equivocan: una vez que funcionan, no se olvidan de ejecutar algún comando ni cometen los errores que las personas cometemos cuando estamos cansados, apurados, o estresados por una fecha de entrega.

Y los programadores siempre programaron, entonces ahora todo el mundo programa.

Eso es lo que implica desde un punto de vista personal una plataforma de transformación digital: “todo definido por software” y “todo el mundo programa”. De nuevo, una plataforma no va a hacer que su organización se transforme digitalmente, pero es muy poco probable que pueda transformarse sin una. Me considero afortunado de haber estudiado ciencias de la computación y por haber programado alguna vez; me facilita entender y poder explicar a mis clientes como Microsoft Digital Advisor este fundamento de la transformación digital.

Anuncios

Written by fernandomachadopiriz

24/03/2017 at 22:16

Desintermediación, modularidad del negocio y plazas de mercados

leave a comment »

Cuatro de los últimos cinco ejecutivos de negocio con los que he hablado como Microsoft Digital Advisor, de una forma u otra, están interesados en los temas que están en el título de este artículo. Aunque están en diferentes industrias, desde agronegocios, logística a, por supuesto, el sector bancario; se han referido a estos temas con otros términos, todos tienen estos conceptos en la cabeza, aunque no necesariamente todos los puntos están claramente conectados. Lo que estoy tratando de cubrir aquí es mi punto de vista personal acerca de cómo están interconectados estos conceptos.

Comencemos con desintermediación. Desintermediación es la eliminación de intermediaros en la cadena de valor. Netflix teniendo sus propios estudios para producir series y películas exclusivas como House of Cards y muchas otras, es un ejemplo de desintermediación, porque no dependen de los estudios de Hollywood y los distribuidores de películas para tener contenido de primer nivel.

Volviendo a las industrias mencionadas al comienzo, un ejemplo en los agronegocios puede ser un granjero orgánico vendiendo sus frutas y vegetales directamente a las personas como usted y yo en un mercado de productores, en lugar de venderlas a un granjero mayorista, que la vende a su vez a los supermercados donde habitualmente usted y yo las compramos. Aunque la desintermediación en este caso está lejos de encontrarse ampliamente difundida, desafía el corazón del negocio de los granjeros mayoristas y de los supermercados, porque ya no son necesarios para que podamos conseguir al menos las frutas y vegetales que necesitamos; y es bueno para los proveedores, porque probablemente puedan vender sus productos a un mejor precio, y es bueno para nosotros, porque sabemos exactamente el origen de lo que comemos y probablemente paguemos menos que en los supermercados por los mismos productos.

Otro ejemplo, esta vez en el sector bancario , podría ser el préstamo entre particulares, donde las personas y las empresas que tienen dinero utilizan un servicio en línea para prestar directamente a quienes necesitan dinero. Los prestamistas entre particulares tienen menos infraestructura y costos de cumplimiento regulatorio más bajos que los bancos tradicionales, por lo que pueden prestar dinero a tasas de interés más bajas que los bancos tradicionales, lo cual es bueno para los que piden prestado dinero; pero también es bueno para los prestamistas, porque a menudo obtienen retornos más altos en comparación con productos similares ofrecidos por los bancos tradicionales.

El ejemplo de agronegocios es de desintermediación completa -no hay nada entre el proveedor y el consumidor- mientras que el último es una desintermediación parcial -hay un servicio en línea entre proveedores y consumidores-. Más sobre esto más adelante.

Aunque la desintermediación se vuelve cada vez más común en más industrias y en más productos y servicios dentro de las industrias a medida que pasa el tiempo, no sucede en todos los aspectos de todos los negocios al mismo tiempo; pero la tendencia es irreversible. Entonces, mientras que algunas industrias y empresas con modelos de negocios verticalmente integrados -como una ventanilla única para los diversos de puntos de contacto a lo largo de la cadena de valor- están seriamente amenazadas por la desintermediación y luchan contra ella, otros en cambio ya están adoptando la desintermediación en sus modelos de negocio, aprovechando lo que este artículo de Oliver Wyman llama a la modularidad del negocio. Aunque el artículo cubre la industria de servicios financieros, la modularidad del negocio es aplicable a muchas sino a todas las industrias. El siguiente par de definiciones son tomadas del artículo mencionado.

Por un lado, la demanda modular es cuando “los proveedores de productos o servicios ya no poseen la relación directa con los clientes”. Es la forma normal de hacer negocios para la mayoría de los productores en la agroindustria, pero no es tan común en el sector bancario. Otro ejemplo de demanda modular es la industria hotelera: incluso antes de la aparición de sitios de reservas de viajes como Expedia.com, TripAdvisor.com y otros, uno solía reservar sus estadías en hoteles a través de una agencia de viajes, era raro llamar directamente a un hotel para hacer una reserva.

Por otro lado, la oferta modular se produce cuando “la cadena de suministro no se entrega en casa, cuando partes de la producción son realizadas por diferentes empresas”. Una vez más, forma normal de hacer negocios para la mayoría de los productores en la agroindustria, pero no es común en el sector bancario. Los restaurantes son un buen ejemplo en una industria diferente: no producen las materias primas que utilizan para el menú que ofrecen, ni las especies y otros ingredientes; no hacen las mesas de comedor, ni la vajilla, ni los manteles, y así sucesivamente.

Tanto la demanda como la oferta modular vienen en grados, la modularidad va desde baja a alta gradualmente. Cuando la modularidad de la demanda y la oferta son bajas, se tiene la integración vertical que mencioné anteriormente. La combinación interesante para este artículo aparece cuando la demanda y la oferta son altamente modulares. ¿Por qué? Ahí es donde el concepto de plazas de mercado marketplaces entra en juego.

Un mercado o plaza de mercado, también conocido como plataforma de negocios en Platform Revolution por Geoffrey G. Parker y otros, o como plataforma de tecnología de negocios digital de acuerdo con Gartner, es un facilitador de las interacciones entre los consumidores o usuarios del lado de la demanda y los proveedores de productos o servicios en el lado de la oferta

El mercado se utiliza para intercambiar “unidades de valor”, es decir, productos o servicios ofrecidos por los proveedores y consumidos por los consumidores o usuarios. El mercado tiene al menos un componente “inteligente” que responde a las necesidades e intereses de los consumidores con productos o servicios ofrecidos por los proveedores, de tal forma que satisface esas necesidades o que coincide con esos intereses. La clave en estos mercados es que todas las transacciones pasan a través y ocurren gracias al mercado. Hay una forma de monetizar las interacciones en el mercado, como una costo por transacción o como un porcentaje del costo de las unidades de valor que se intercambian, cobradas a los proveedores, a los consumidores, o a ambos, pero no es la única. A los productores se les puede cobrar una cuota de inscripción o una suscripción de forma continua, mientras sean parte del mercado; y lo mismo aplica a los consumidores o usuarios.

Imagine que está a punto de comprarse un automóvil por ejemplo. Un mercado de autos puede ofrecerle autos nuevos o usados de varios concesionarios y fabricantes. El mercado lo conoce a usted lo suficientemente bien como para proponerle préstamos atractivos u opciones de arrendamiento financiero leasing, ya sea de bancos o empresas de préstamos entre particulares, así como seguros de diferentes aseguradoras. La póliza del seguro se puede calcular sobre la base de los hábitos de conducción, kilometraje, etc, mediante el uso de un dispositivo ofrecido por un tercero que está conectado al auto para recoger datos de telemetría que se envían a la aseguradora y finalmente al mercado también, bajando del precio de la póliza si usted conduce con cuidado y a la defensiva o no utiliza su coche demasiado, o elevándolo si usted conduce imprudentemente. El mercado también puede ofrecerle servicios de mantenimiento o de lavado de autos; pueden ser servicios regulares, o el proveedor de servicios puede recoger su auto de su casa o su oficina y dejarlo de nuevo en el mismo lugar pocas horas más tarde, por lo que no es necesario que usted lo tenga que moverse, porque el mercado sabe que usted es una persona muy ocupada. Y lo que es aún más interesante, si el mercado lo conoce lo suficientemente bien y es lo suficientemente “inteligente”, es que puede recomendare que no tenga un auto en absoluto, y en su lugar le sugiera usar un servicio de autos compartidos, de viajes compartidos, o simplemente alquilar un auto cuando lo necesite. El mercado de estos automóviles puede ser utilizado por personas como usted y yo, pero también por los propietarios de flota de automóviles, etc.

Una vez que el mercado tiene suficientes datos sobre las transacciones, sabe mucho sobre los proveedores y los consumidores, y puede responder a preguntas como quién, cuándo, qué, cuánto, etc. Aquí es donde entra en funcionamiento el segundo componente “inteligente” del mercado, porque estos datos no sólo son útiles para el propio mercado, sino que pueden ser muy valiosos para terceros que están dispuestos a pagar por ello. Resolviendo los problemas y reglamentos relacionados con privacidad y cumplimiento, por ejemplo segmentando y haciendo los datos anónimos, aparece un nuevo modelo de negocio.

El mercado puede verse desde tres puntos de vista diferentes, pero complementarios:

  • Los aspectos comerciales, es decir, cómo definir y monetizar la plataforma. Este artículo aborda resumidamente ese aspecto en particular.
  • Los aspectos tecnológicos, es decir, los servicios en la nube, la estrategia y la arquitectura API, la plataforma y las herramientas de desarrollo móvil, IoT y big data, contenedores, etc. Más sobre los aspectos tecnológicos en mi post anterior.
  • Los aspectos del ecosistema, es decir, cómo ejecutar hackathons y descubrir e incubar startups para expandir los servicios o productos ofrecidos, cómo involucrarse con la investigación y con la academia, cómo conectarse con agencias gubernamentales y no gubernamentales, y así sucesivamente.

Cualquier intento serio de construir un nuevo mercado o de participar en uno existente debería considerar simultáneamente todos los aspectos mencionados, así como la relación de los mercados con la modularidad del negocio y la desintermediación.

Written by fernandomachadopiriz

18/03/2017 at 06:46

Construye tu propio bot: Charla en .NET Conf UY 2016 con Fabián Alves en Channel 9

leave a comment »

Gracias a la organización de .NET Conf UY 2016, José Erosa, Fabián Fernandez, Pablo Terevinto, Daniel Pardo y el resto del equipo de colaboradores, está publicada en Channel 9 la charla sobre bots y Bot Framework que dimos en esa conferencia con Fabián Alves.

Written by fernandomachadopiriz

17/01/2017 at 13:16

Publicado en Anuncios

.NET UY Conf, Septiembre 30 al 4 de Octubre

leave a comment »

El sábado 3 de octubre a las 10.10 estaremos con Carolina Romero hablando de Dev/Ops, la conferencia va desde el 30. ¡Los esperaamos!

NETConfUY.Flyer.0928

Written by fernandomachadopiriz

28/09/2015 at 10:31

Publicado en Uncategorized

Agile Architecture Workshop por Martín Salías

leave a comment »

Mi amigo Martín va a estar en Montevideo el 26 y 27 de mayo con un taller de arquitectura ágil que les recomiendo. Más detalles en la página del evento.

Written by fernandomachadopiriz

17/05/2015 at 12:56

Publicado en Anuncios, Arquitectura

Road to the Cloud: Montevideo Estrategia de negocios y networking para ISVs

leave a comment »

image

El miércoles 10 de diciembre de este 2014, de 16:00 a 19:30, Microsoft organiza un evento para compartir con sus pares en la industria que han utilizado los beneficios de la nube para construir negocios exitosos. Comparta acerca de las mejores prácticas y lecciones aprendidas, y conozca las oportunidades desde el punto de vista del nuevo modelo de negocios.

Más información y registro aquí.

Written by fernandomachadopiriz

24/11/2014 at 13:18

Publicado en Anuncios, Azure

Toda empresa es una empresa de software, y toda empresa de software puede ser un proveedor de servicios

with one comment

El software está en todos lados. Excepto tal vez en los negocios como los carritos de chorizos de calle, todos los negocios funcionan en base a software. Y el carrito de chorizos es una excepción si y sólo si no acepta pagos con tarjeta de crédito, o no utiliza algún servicio en línea para pedir las materias primas con las que prepara después los chorizos. Al fin y al cabo, cada empresa es una empresa de software, ya sea que sólo consuma software, o que desarrolle y consuma software a la vez.

Para aquellas empresas que hacen desarrollo de software en la propia empresa y luego usan ese software para gestionar su negocio, incluso si es sólo una parte del total de software que utilizan, el tradicional ciclo de vida de desarrollo de software podría no ser apropiado en algunas circunstancias, como lo veremos en un minuto.

Y para aquellas empresas cuyo negocio es el desarrollo de software para que otras empresas o individuos consuman, el tradicional ciclo de vida de desarrollo de software podría no ser apropiado tampoco.

Por tradicional ciclo de vida de desarrollo de software me refiero al proceso que crea un producto de software al final. No me importa si se trata de desarrollo en cascada o ágil, lo único que me importa es que un producto de software es creado como resultado de ese proceso. Tiene las siguientes características:

  • Muchas características. La diferenciación de los productos se basa en tener tantas características como sea posible para un público tan amplio como sea posible. Los productos raramente están dirigidos a funciones o necesidades específicas del cliente.
  • MTTF o tiempo medio entre fallas. Al igual que con los productos manufacturados tradicionales, su objetivo principal es el tiempo medio entre fallas: los productos son mejores si tienen pocas fallas.
  • Cadencia de actualización lenta. Las actualizaciones de productos de software son relativamente poco comunes; pueden ser a través de parches para corregir errores, a través de paquetes de servicio para agregar nueva funcionalidad, o por medio de versiones completamente nuevas. El tiempo de desarrollo de productos de software suele ser largo, seguido por período de garantía de mantenimiento, y luego de un descanso antes de empezar todo de nuevo.
  • Hábitos de consumo desconocidos. Una vez que los productos son liberados, es difícil saber cómo son consumidos por los usuarios, y tomar decisiones en base a los patrones de uso.
  • Dentro del calendario, dentro del presupuesto. La prioridad más importante es liberar productos a tiempo y dentro del presupuesto.

Además, como ocurre con los productos fabricados tradicionales, la confiabilidad es percibida desde la perspectiva de cada unidad individual. Proporcionar confiabilidad requiere control de calidad dentro del proceso de producción. Cuando los usuarios experimentan problemas con los productos, por lo general están dispuestos a esperar hasta el horario de oficina para reportar su problema. Un problema raramente impacta más de una persona a la vez. Y por lo general está claro para los usuarios cuando los problemas se deben a problemas en el producto de software, en lugar de problemas en el entorno en el que el software está ejecutando.

Pero cualquiera de estos negocios podría verse afectados por la transformación actual de las demandas de software:

  • Su empresa desarrolla una aplicación de software para móviles, puede ser una aplicación de línea de negocio en el mundo de las empresas, o puede ser otra aplicación de software de propósito específico del mercado de aplicaciones en el mundo de los consumidores. En el segundo caso, la mayoría de estas aplicaciones por lo menos almacena algunos datos o hace algún tipo de procesamiento en un servidor remoto, lo que las pone en el mismo grupo que las que están en el primer caso: aplicaciones móviles que consumen servicios remotos.
  • Su empresa hace negocio electrónico con otras empresas, puede ser exponiendo los procesos internos a través de software donde otros pueden participar, o utilizando aplicaciones de software para el intercambio de información con el fin de completar una transacción. De una forma u otra están proporcionando servicios basados en software, o consumiéndolos; probablemente ambos.

¿Notaron la palabra software al principio de las dos frases anteriores y la palabra servicio al final? No es casualidad –yo lo escribí de esa manera- pero eso es lo que estamos viendo y vamos a ver en un futuro próximo: aplicaciones de software móviles que consumen algún tipo de servicio remoto y servicios basados en software siendo expuestos para que otros puedan consumirlos.

Si siente que cualquiera de las dos categorías antes mencionadas son aplicables a su empresa, ya sea creando software para su propio consumo, o si está en el negocios de desarrollo de software para que otros utilicen, y todavía está desarrollando software como productos, ¿adivine qué? Usted no está desarrollando software, usted está proporcionando servicios. Los llamo proveedores de servicios basados en software. Y eso es una cuestión completamente diferente, ¿quiere saber por qué? Veamos:

  • Confiabilidad y agilidad en vez de más características. La diferenciación de los servicios se basa en las capacidades de alta confiabilidad que se ajustan a un conjunto específico de necesidades del mercado. Los servicios más eficaces y efectivos ponen la confiabilidad y la agilidad por encima de la candiad de características.
  • MTTR o tiempo medio de resolución. Al igual que con los servicios públicos tradicionales, su foco está en el tiempo medio de recuperación: las interrupciones van a ocurrir, por lo que los servicios son mejores cuando más rápido estén funcionando de nuevo.
  • Actualizaciones continuas, desarrollo continuo. Las actualizaciones de software son continuas; podrían libear nuevas funciones o nuevas versiones enteras con mucha frecuencia, y corregir los errores todos los días. El desarrollo de software para servicios suele ser continuo; puede ser que haya ciclos de liberación, pero por lo general esos ciclos son muy cortos.
  • Patrones detallados de uso. Por lo general es posible recopilar cantidades enormes y muy precisas de datos sobre el uso del servicio, lo que permite tomar mejores decisiones.
  • Siempre funcionando, a costos adecuados. La prioridad más importante es tener el servicio en funcionamiento, manteniendo el costo de operación apropiado.

Además, como ocurre con los servicios públicos tradicionales, la confiabilidad es una función de todo el sistema. Proporcionar confiabilidad requiere monitoreo proactivo en tiempo real del comportamiento de cada componente del sistema. Cuando los usuarios sufren interrupciones del servicio, el impacto es mucho más amplio, un problema impactar una amplia gama de clientes. La respuesta no puede esperar al horario de oficina. El soporte tiene que estar disponible 24x7x365. Los usuarios no se preocupan dónde están los problemas cuando se producen cortes en el servicio. Puede ser que estén en el software en el que se basada el servicio, o en el centro de datos, o en la red, o en cualquiera de los componentes dependientes.

¿Su fábrica de software no puede seguir el ritmo de las solicitudes de cambio y no tiene suficiente agilidad para acompañar a transformación de su negocio? ¿Tiene requisitos contradictorios de diferentes unidades de negocio o diferentes grupos de usuarios? ¿No puede encontrar una buena manera de organizar sus equipos de operaciones de software y de desarrollo de software? ¿Quiere saber una cosa?… su fábrica de software probablemente no está organizada como tiene que ser organizado un proveedor de servicios.

Las fábricas de software se organizan en torno a los productos de software, mientras que los proveedores de servicios se organizan en torno a los servicios. ¿Y todavía se preguntan por su fábrica no funciona?

La organización de los equipos alrededor de los productos significa dos cosas. Uno: que muy probablemente tenga un equipo para cada producto, algunos de los miembros podrán ser compartidos entre los equipos, pero los equipos trabajan para un sólo producto. Y dos: que muy probablemente tenga una segregación de tareas dentro de los equipos: analista de negocios, arquitectos, diseñadores, desarrolladores, probadores, y hasta operadores si ejecuta su propio software. ¿Un producto utiliza otros? Por supuesto, excepto si tiene pedazo gigante de software monolítico, en cuyo caso usted está peor que el resto de nosotros, y tiene problemas más urgentes e importantes que resolver. Cada una de las funciones de un equipo de producto que he mencionado antes, trabaja para su propio producto. Los equipos de un producto realmente no se preocupan por otros los productos que utilizan los suyos y ciertamente no controlan los demás productos que ellos consumen. Y la transición desde desarrollo hasta operaciones se parece a desarrolladores que lanzan algo sobre el muro para que la tomen los operadores… ¿a quién le importa lo que sucede en el otro lado? Invariblemente hay una venganza, los operadores siempre pueden enviar solicitudes de corrección de errores hacia los desarrolladores.

La organización de equipos alrededor de los servicios, significa que un equipo de servicio tiene todo lo que necesita para ofrecer el servicio y cumplir con el acuerdo de nivel de servicio. No hay muros. El dueño del servicio, analistas de negocio, desarrolladores, probadores y operadores se sienta juntos por adelantado para definir cómo lucirán en el futuro el servicio en sí y el proceso de desarrollo del servicio, de extremo a extremo. Radical, ¿no? Sí, pero es lo que necesita. Un operador diciéndole a un desarrollador de software qué tipo de despliegue automatizado, monitoreo y capacidades de telemetría necesitará para operar el servicio. Estos son requisitos no funcionales y los arquitectos y desarrolladores de software están acostumbrados a tratar con este tipo de requerimientos. Un probador diciéndole a un desarrollador de software la manera en la que debe diseñar el software para que él o ella pueda probarlo de forma eficaz y eficiente. Estos son requisitos no funcionales también. Un arquitecto de software o desarrollador diciéndole al dueño del servicio lo que se puede o no se puede construir en un momento dado y las restricciones de recursos y presupuesto. Parece una locura, pero estos ejemplos son tan sólo requerimientos del negocio, el propietario del servicio está acostumbrado a tratar con ellos durante la definición del servicio.

Si piensa que los servicios están sólo en la capa externa en contacto con el mundo exterior, está equivocado. El mismo concepto se puede utilizar en las capas internas, en lo que me gusta llamar como arquitectura empresarial orientada a servicios. No es lo mismo que la arquitectura orientada a servicios simple y llana, donde los servicios de aplicación eran la piedra angular. Estoy hablando de servicios de negocio, servicios de aplicaciones y servicios de infraestructura, todos organizados de la misma manera, confiando uno en uno a través de acuerdos de nivel de operación bien definidos desde el lado de los consumidores de servicios, y de acuerdos de nivel de servicio como parte de una clara definición de servicio desde el lado del proveedor de servicios.

Las empresas de software más grandes (bueno, depende de su definición de grande) son de hecho proveedores de servicios basados en software (Microsoft, Google, Amazon, Facebook, Twitter, WhatsUp, Apple, y así sucesivamente). Su empresa podría no ser tan grande como éstas, pero si se trata de un proveedor de servicios basado en software, es posible que tenga más cosas en común con ellos de lo que usted piensa. De alguna manera u otra, todos ellos se organizan detrás de los servicios que proporcionan. ¿Por qué no habría de hacerlo usted?

Written by fernandomachadopiriz

20/11/2014 at 09:58