Archives

La Internet de las Cosas (parte 2)

Let's see a concrete and current example about an application based on the concepts of the Internet of Things. In this way we can know how these systems will work in the future. The vast majority of the examples provided for IoT revolve around a "smart coffee cup", or household appliances with sensors. While these are valid examples, they focus too much on the "Things" aspect, which is only part of the IoT. The revolutionary of the Internet of Things are the systems that are intertwined from things. As time goes by, these advanced IoT applications will impact our lives as deeply as web 2.0 innovations did. As we will see below in our example, this is already happening today.

Uber is a mobile application that connects people with taxis and rental cars. Maybe it's not the most obvious example for an IoT system, but I think it's an excellent case of success, and it shows us the future of these platforms. In addition, it has the advantage of being a current and profitable system, which already has a concrete impact on the real world. I intentionally choose an example about which I do not have an internal knowledge, in this way I will not reveal any secret. This also means that I speculate with some of the details of the implementation, but I guess I'm not that far from reality.

This is the way Uber works today. First of all we must download the application from the operating system store, and then register with a credit card. The steps are the following.

1. When we need a taxi, we start the application from a mobile device.
2. The Uber app shows us our location on a map, along with the location of all the cars we can call. It also shows us the estimated time for the arrival of the vehicle. In my case, it was only two minutes.
3. While we look at the map, the location of nearby cars is updated in real time.
4. We can enter our destination and obtain an estimated price even before calling a car. In my case, the cost was from $ 23 to $ 31 for a 25-minute trip.
5. Once we decide to call a car, we press a button to confirm our location. At this point we can indicate our current coordinates or define a nearby location.
6. When the trip is confirmed we receive the driver's name and a general description of the car, which includes the color and the license number. From this moment we will see the car on the map, approaching in real time on our mobile device. The reputation of the driver, in stars and comments, appears along with this information.
7. At this point the app shows us a counter and constantly tells us where the car we are hiring is. We also have an option to exchange messages with the driver, which can be useful if we change plans. When the car arrives we receive a notification on the phone.
8. Once inside the vehicle, the driver already has all our information, and receives step-by-step instructions to reach our destination.
9. When we arrive at our destination we simply appreciate the trip. No need to pay, leave a tip or even take the phone out of your pocket. The tip is included in the price, and the cost of the trip is automatically debited from the credit card. Then we received an email with a receipt for the operation.

And that's it. I can summon a car with just a few clicks, and without using money or taking the phone out of my pocket. There are multiple wrinkles and refinements. For example, we can choose the type of car that interests us (taxi, limousine or personal car), which is reflected in the price we pay. It is also possible to qualify the car and the driver, share the fare and other tools for the passenger. Drivers can also qualify passengers, and receive recommendations on the most required places. All the drivers and passengers I spoke with agree that the system works very well. And besides, it's really profitable. Uber earns its money through a commission of 20% on travel, which meant an estimated profit of 220 million in 2013, in a total of 1.1 billion transactions.

Uber is a good example of the Internet of Things in multiple aspects. In the first place, it is important to take into account the central role played by both the location of the car and the passenger, and the real-time nature of this information. The GPS chip, in conjunction with other positioning systems, allows you to identify the coordinates of any mobile device. While these sensors are contained within smartphones, they are the same as those used for the Internet of Things. In the case of Uber, the "Things" are the sensors of the mobile devices of passengers and drivers. The "Internet" in this case is the interconnection of each sensor, through the smartphone, with the brain and memory in the Uber cloud.

I think it is revealing that very few consider Uber as an example of the Internet of Things. It is a case in which the important thing is not the devices, but the people involved, that is, the passengers and the drivers. What happens is that mobile devices, together with their sensors, have become part of our daily life. We have a tendency to focus on people and human needs, such as transportation. In the future of the Internet of Things, our needs will always be at the center.

Continuing with our analysis of Uber, once the application is launched, the geolocation sensors of the devices send their information to a system that is hosted in the cloud. When we call a car, our device sends a message to the Uber cloud, indicating that the person X, in such coordinates, wants a car to take him to his destination.

When you receive an order of this type, the Uber cloud uses real-time analytics to determine the ideal vehicle for the passenger. I do not have the specific data of their algorithms, but they work combining geographical proximity with the estimated travel time, the reputation of the users involved and other factors. Most of this information is processed in an instant, using the freshest data from the mobile devices of passengers and drivers. A certain percentage of that information, such as rates, is processed according to a schedule, and not necessarily in real time.

The net result is that a car is quickly assigned to a passenger, approximately one tenth of a second. Because certain complex factors are calculated in advance, the system can use sophisticated metrics to improve the value of business decisions. In theory, this allows for better decision management at an impressive speed. Once the system obtains a result, it is put into effect. In the case of Uber, this takes the form of a notification to the driver, who notifies him of the passenger's request.

Other applications of the Internet of Things tend to follow an architecture similar to the one we describe for Uber:

1. Orders, in addition to sensor and human information, are transmitted to a system in the cloud.
2. A quick decision subsystem processes observations and orders quickly.
3. This decision subsystem uses the context provided by the main system, which analyzes multiple sources of information.
4. Relying on the context, the decision system initiates an action, such as sending a notification.
5. Other complex actions can be initiated for analysis, as in the case of reputation or awards.

While this pattern adapts very well to the Internet of Things, it can also be used in multiple situations. Whenever an action must be contextualized in response to a flow of information, this approach will be very useful. We find that the elements of this IoT architecture are excellent for the fields of mobile advertising and computer security, for example.

The key to the Internet of Things is the ability to place information and orders in context, and then respond to them intelligently. When these observations come from sensors, the IoT label almost always applies. But the heart of any IoT architecture is the ability to intelligently respond to events through the autonomous decisions of a system. In the case of Uber, the heart of your business is the ability of your cloud to assign passengers and drivers wisely. When we talk about the Internet of Things, the important thing is not only the interconnected "Things", but the intelligence generated based on the context of the information.

La Internet de las Cosas (parte 1)

By Jim Walsh .

A term like The Internet of Things (IoT) can be overused and lose all its meaning. Those of us who witness the birth of "Web 2.0" know this situation very well. In retrospect, the result of this movement was the interactive Internet, which is how we know it today: Twitter, YouTube, Facebook and blogs, among other services. In the world of technology, once something becomes successful it becomes the "natural" way, and it no longer needs a particular name. I think we will see a similar phenomenon around the Internet of Things: once you have transformed the world, you will no longer need a name, and it will simply be the state of technology.

In this series of notes we will discuss the concept of IoT, the reasons for its progress, and how the world will change even more profoundly than its predecessor, Web 2.0.

The Internet is evolving rapidly, allowing everyone on the planet to connect through various computing devices. With the advent of smart and increasingly accessible mobile devices, access to the Internet has come close to ubiquity in the last decade. For this year, more than 40% of the world population (about three billion people) has access to the network. In the group of industrialized countries commonly called G5 (United States, England, Germany, France and Japan), more than 85% of people have access to the Internet, and the rest of the world is not so far away.

As the cost of computing and storage has drastically decreased, coupled with wireless connectivity, technologies seek to link not only people, but also "things" through the Internet. In this sense, IoT describes what many consider to be the next evolution of the Internet. The vision of IoT is that the elements of the physical world will have a presence on the Internet, as well as more than a billion people today have a presence on Facebook. In this way, an object such as a coffee machine can become smart, and notify us of the state of our coffee through the web.

The concept of physical objects communicating with each other through the Internet is not necessarily new. When we talk about "people" in the network, we only do it figuratively. They are really our machines (whether notebooks, desktops or mobile devices) which are connected and not the humans themselves. The Internet is already composed entirely of "things"; and we use them as means of communication and alter egos. So, what is changing? When we talk about the Internet of Things, what it implies is that the devices themselves will begin to take on a role that until now has been reserved for humans. In particular, the devices will create and take advantage of enormous amounts of information that will circulate on the Internet and that will not require the intervention of humans. Increasingly,

This has not yet happened on a large scale. Currently, and in the course of Internet history, people create most of the content by typing, scanning, speaking, recording, photographing and filming, among other possibilities. In 2012, only 30% of all new information was generated by machines such as sensors, computer logs and security cameras. The remaining 70% was created by people, directly or indirectly.

Not all this information is available through the Internet, but this situation will change as the world interconnects. The trend indicates that the information generated by machines will exceed that created by humans in the coming years. This is because the amount of things on the Internet starts to exceed the number of people. According to estimates, in 2014 there were approximately twice as many devices connected to the Internet.

The idea of machine-to-machine communication is central to the Internet of Things, but the concepts are not the same thing. M2M can be considered as a call from one point to another, while IoT is more similar to an entry in a blog, in which the information is persistent and can be accessed by anyone with permissions. The difference is that in information between humans, intelligence resides in the person performing, reading or responding to certain content. In the Internet of Things, intelligence is found in the network or in the device itself. It is this intelligence that gives meaning to the data delivered by sensors, and which decides the way in which to act.

It is clear that some of these devices will become increasingly intelligent, such as cars. However, in many cases the brain of the Internet of Things will not be on the device, but on the Internet itself. Or, rather, in cloud computing. Many everyday objects will gain sensory abilities, and they will take advantage of the Internet to communicate what they feel. In 10 years, the cups may have a sensor to measure the temperature of the coffee, another pressure to determine the amount of liquid, and even connectivity and a source of energy. All this does not qualify as a brain, however.

The brains will be in the clouds. This approach allows linking information from multiple sensors, which opens the door to complex and really interesting behaviors. It also allows you to learn from past behaviors, and make relationships with other situations. By maintaining devices with sensors but without brains, the systems can be quickly updated without generating conflicts in the rest of the network.

As the cost of storage and processing continues to decline, as predicted by Moore's Law, intelligence will be distributed among more and more devices. If we look further ahead, even disposable devices can become smart. However, for now, genuinely intelligent equipment does not represent the essential of the Internet of Things. This essence is in distributed sensors and interconnected devices, with a brain in the clouds becoming more intelligent and capable of acting on information in real time.

What is TM Forum Frameworx and how to apply it to your business?

About TM Forum

Before speaking about TM Forum Frameworx, we should know some things about TM Forum, the organization behind it. We should see first how they describe themselves in their official site:

“TM Forum is the global industry association for digital business, connecting talented individuals, leading companies, and diverse ecosystems to accelerate our members’ successful digital business transformation. The collective experience and interests of our member community comprised of tens-of-thousands of professionals within 900+ market-leading organizations drives everything we do, from thought-provoking research and publications, to practical guidance, collaboration programs, tools and best practices, hands-on events, and training for business and IT leaders.”

As you can see, the focus of the forum are the digital businesses and its main objective is to accelerate their transformation. They achieve this through a collaborative work with their member organizations - whose numbers grow day by day - and the professionals who work for them. In this way, when an organization becomes a TM Forum member, it gains access to the accumulated knowledge of years of experience. Besides, the forum is dynamic, so the information available for members is ever evolving.

What is TM Forum Frameworx?

TM Forum Frameworx is a suite of best practices and standards for the business processes, information structure and applications - and for the integration between them - within an organization. Besides, Frameworx includes two important extensions of the aforementioned core components: a suite of Business Metrics and a certain number of Best Practices. All these tools help us improve end-to-end service management.

In the next figure, the relationship between its elements becomes clear:

cuadro-bp-300x239

The graphic above is the TM Forum Wheel. In its center we have the Integration Framework, which enables the relationship between the three other frameworks: Business Process Framework, Information Framework and Application Framework. We can also appreciate above the existence of the Business Metrics and the Best Practices as supporting material.

Before continuing, TM Forum Frameworx Components should be described:

Business Process Framework: It is a hierarchical catalog and classification scheme of the key business processes required to run a service-focused business.
Information Framework: It provides a reference model and common vocabulary for all the information required to implement Business Process Framework processes.
Application Framework: It provides a common language for communities who specify, procure, design and sell operation and business support systems, in order to provide logical groupings of applications, procuring to define each application’s functionality.
Integration Framework: It is a set of standards that supports the interoperability between applications defined in the Application Framework via TM Forum interfaces, which are defined in terms of the Information Framework's entities/attributes, and the requirements for the interfaces from a business process perspective, which comes from the Business Process Framework.

Finally, the extensions can be described as follows:

Business Metrics: They are an industry-agreed view of the standard, in the form of quantifiable metrics a Digital Services enterprise requires to run its business.
Best Practices: They are the extension of the core components of Frameworx to meet specific requirements, developed by member organizations interested in some areas.

Frameworx Development

TM Forum Frameworx was not developed from scratch, but with acquired industry knowledge and has been evolving in a collaborative environment named “Virtual Research and Development Consortium” made up of TM Forum Members from a growing array of industries from all around the world. It is important to mention that any member can contribute to the standard and every contribution is well received and analyzed afterwards to determine if it deserves to be part of the standard in future releases.

Why to adopt Frameworx?

There are several reasons to adopt Frameworx, but I will mention and explain some of them for you to consider:

Reduce time-to-market, by enhancing the agility of the organization with streamlined end-to-end service management.
Use the same standards as our partners and providers, which makes easier the creation, delivery and management of the enterprise-grade services.
Get and keep market share, through the improvement of the customer experience and retention, using proven processes, metrics and maturity models.
Optimize the business processes, identifying the most commonly used, detecting redundancies and bottlenecks, reducing costs after solving them.
Reduce integration costs and risks through the use of standardized interfaces (supported by the Integration Framework) and a common information model (the Information Framework).
Reduce transformation risk, by delivering a blueprint for agile, efficient business operations. Frameworx should be used as a point of reference, reason why we use the term “blueprint”.
Gain independence and confidence in your procurement choices, through conformance certification and procurement guides: we have standard RFP (Request For Proposal)/RFI (Request For Information) guidelines and templates available in Frameworx.
Remove ambiguity in the language, having a common, industry-standard language. This is important, especially taking in consideration terms are overloaded in the industry.

My experience with TM Forum Frameworx

With GlobalLogic, I had the experience of dictating TM Forum Workshops for an important telecommunications company in Chile, in the context of a digital transformation project they are going through.

First of all, I gave them some basic tools to understand the concepts behind Frameworx and, of course, the opportunity to apply them in practice. The theory behind the standard is overwhelming and everything was new to them, but day by day I could see their progress and they were motivated by this new world they were diving in.

With that knowledge, they were able to compare their existing business processes and applications with the ones defined in the frameworks from TM Forum, learning from the standard to improve what they have in their daily work.

Secondly, with the learning from the first part of the project, I conducted a five weeks dynamic with our client, involving functional analysts, technicians and managers, among other professionals. In this activity, we worked together analyzing their processes and applications and we helped them to map these elements to Frameworx (to the Business Process and the Application Framework respectively), detecting redundancies in the application’s functionalities and identifying business processes without an owner, just to mention a couple of examples. On the other hand, Information and Integration Frameworks were out of the scope, the same can be said about Business Metrics and Best Practices extensions.

The implementation of Frameworx requires some years of work and that is the process our client has just started with us. They trust in the standard to be the protagonist of this digital transformation project, along with us for the support they need during this big challenge.

Frameworx adoption worldwide

But our client is not alone: According to a TM Forum survey among member organizations - all of them leading service provider companies -, Frameworx is currently adopted and used by 95% of the companies who took the survey and 82% of them mandate the standard in many or all specifications. This organizations can learn one from each other and they guarantee that Frameworx plays an essential role in their ability to do the following:

Enable IT architecture simplification & agility
Provide a common frame of reference between project members
Reduce risk in transformation projects
Reduce cost of integration

As you can see, some of this aspects were considered before when we spoke about the reasons to adopt Frameworx.

In conclusion, this standard is being adopted widely between service provider companies – especially TELCOs - all around the world, and they claim they are getting important benefits from it. Therefore, if you are part of one of them and you have not heard about TM Forum up to this moment, you are invited to investigate further about it.

Identificación de Servicios en SOA

Una arquitectura basada en SOA está fuertemente basada en la interacción de distintos servicios que se componen y combinar para cumplir un determinado objetivo. Uno de los principales desafíos en el éxito de un emprendimiento SOA consiste en la manera de realizar la interacción entre los servicios. Esto último se define como orquestación. Una apropiada orquestación de servicios en una arquitectura SOA garantiza una adecuada reutilización de servicios, que es una de las máximas que se persiguen. Sin embargo, para lograr esto es necesario partir de una correcta identificación de servicios. Esto es, ¿qué servicios deben interactuar? ¿Cómo? ¿Por qué este esquema y no otros? Tales preguntas son abordadas en la referencia [1], y se describen a continuación las principales ideas.

Identificando servicios
Existen ciertos aspectos que deben considerarse al momento de definir e identificar los servicios dentro de una arquitectura SOA. Los más importantes mencionados en [1] son:

Flexibilidad. Un sistema es más flexible que otro cuando es más adaptable a cambios. En el mundo de los servicios, esto se logra especificando muchos servicios pequeños, con una única funcionalidad. De esta manera, los servicios pueden componerse fácilmente. Por otro lado, si se definen pocos servicios, “cargados” de funcionalidad, el sistema resultante será menos flexible y difícil de modificar.

Performance. La manera de combinar servicios repercute en la performance del sistema. Existen lenguajes como BPEL (Business Process Execution Language) que se utiliza para definir la orquestación de servicios, WDSL (Web Service Definition Language) para definir sus interfaces, y SOAP (Simple Object Access Protocol) para el intercambio de mensajes. Los mencionados lenguajes están basados en XML y favorecen la legibilidad. Sin embargo, crean una sobrecarga en la ejecución del sistema. Cuantos más servicios estén involucrados, mayor será la sobrecarga.

Reuso. Es importante es este punto tener un control centralizado de todos los servicios definidos, de manera de poder detectar rápidamente la posibilidad de utilizar un servicio ya definido en vez de reinventar la rueda implementándolo nuevamente. De la misma manera que lo analizado en flexibilidad, cuantos más pequeños sean los servicios, más chances habrá de reutilizarlos.

Estrategias posibles
La manera más natural según establece [1] es proceder siguiendo una metodología top-down. Una vez definidos los procesos involucrados, el paso siguiente es establecer qué servicios serán necesarios. En este punto deben considerarse los aspectos ya mencionados previamente: flexibilidad, performance y reuso. Como ya se estableció, muchos servicios pequeños favorecen el reuso y la flexibilidad, pero en detrimento de la performance. Luego, es importante destacar que no existe un balance ideal u óptimo. Ante cada sistema se deberá buscar la mejor manera de combinar todos los aspectos.

Sin embargo, existen heurísticas que pueden emplearse. La más conocida impulsa seleccionar aquellos procesos dentro de la arquitectura que logran hacer una diferencia frente a los competidores. Quizás algún servicio referido a un aspecto administrativo no sea tan distintivo frente a la competencia, pero sí posiblemente lo sea un servicio que afecte directamente la utilización del sistema por parte de los usuarios. Estos últimos servicios deben priorizarse para lograr flexibilidad y reuso, ya que son los que impulsarán la diferencia frente a la competencia. Vale la pena mencionar que esta es sólo una estrategia posible, que incluso puede no tener sentido en algunos sistemas. Ante cada nuevo desafío, se deben combinar de la mejor manera performance, reuso y flexibilidad.

Conclusiones
La identificación de los servicios involucrados forma un papel clave para el éxito de un emprendimiento SOA. No debe subestimarse la decisión de cuántos servicios definir, y la manera en que los mismos interactuarán, ya que de esto depende cuán flexible, performante y fácil de reusar será el sistema resultante.

Referencias:
[1] http://www.theenterprisearchitect.eu/blog/2007/04/26/soa-and-service-identification/

Manejo de transacciones en SOA

Un desarrollo de software basado en una solución arquitectónica SOA se destaca generalmente por un sistema distribuido basado en la comunicación e interacción de servicios. Una arquitectura SOA puede incluir entonces distintas plataformas y tecnologías, por lo que el monitoreo de la comunicación entre los distintos servicios que proveen la funcionalidad del sistema es crucial para el éxito del sistema.

Un aspecto que sobresale en este contexto es el transaccional. Típicamente, el concepto de una transacción involucra una serie de pasos que tiene que cumplir la siguiente propiedad: o se hacen todos los pasos, o no se hace ninguno. Es decir, que si alguno de los pasos fallara, se debe volver atrás y deshacer las acciones realizadas hasta el momento. Todo debe quedar como si nunca nada hubiera pasado, para luego reintentar llevar a cabo la transacción. Un ejemplo canónico para ilustrar el concepto de transacciones es un sistema bancario, donde cada una de las operaciones debe cumplir esa característica transaccional: no puede ocurrir que un error deje en estado inconsistente el saldo de una cuenta. Formalmente, se dice que una transacción debe cumplir las propiedades ACID [1]: Atómica, Consistente, Aislada y Durable.

Claramente el concepto de transacciones en un entorno con un alto perfil distribuido como una solución SOA juega un rol preponderante, y debe prestarse especial atención a aquellos servicios que necesiten ejecutarse de manera transaccional.

Transacciones en SOA

Para implementar un servicio dentro de un esquema SOA con un perfil transaccional es clave monitorear todo el tiempo la comunicación entre los componentes. Es decir, el atributo de calidad conocido como disponibilidad, que se concentra en el manejo de fallas, tendrá un papel determinante.

Para llevar a cabo este monitoreo, empresas como SOA SOFTWARE (www.soa.com) ofrecen servicios y productos dedicados. Los mismos están basados en tres pilares: monitoreo, para poder tener conocimiento exacto del lugar de una falla, transaction tracking, para poder deshacer acciones previas una vez detectada una falla, y SLA (Service Level Agreement), para tener un contrato que establezca la calidad del servicio.

Patrones para la implementación de transacciones

Otra opción más artesanal surge de aplicar un patrón arquitectónico de SOA, como lo es el patrón Servicio Atómico Transaccional [2]. Este patrón ilustra una solución general para implementar servicios de manera transaccional. La descripción del patrón tiene 4 partes:

- Problema: cuando un servicio utiliza otros para su solución, y uno de ellos falla, el servicio debe deshacer todas las acciones realizadas para mantener la consistencia del sistema.

- Solución: encapsular los servicios invocados dentro de un servicio “wrapper” con capacidad de efectuar rollback: es decir, ir hasta el último estado consistente.

- Aplicación: Un sistema transaccional se incluye en la solución arquitectónica y es utilizado por aquellos servicios que lo requieran.

- Impacto: existe una sobrecarga en el consumo de memoria, ya que se requieren recursos para mantener el estado de cada uno de los servicios que será utilizado en caso de efectuar un rollback.

La figura 1 (obtenida desde [2]) muestra un ejemplo de este patrón. Los servicios A y B completan sus tareas de manera exitosa. Sin embargo, cada vez que lo hacen inician una transacción local, guardando en una base de datos su estado actual antes de realizar cualquier cambio (puntos 1 y 2 en sus figuras). Luego, una vez que el servicio C falla (punto 3 en la figura), los servicios A y B efectúan un rollback, para volver al último estado actual consistente (puntos 4 y 5).

Conclusiones

El manejo de transacciones nunca es trivial, y menos aún dentro de una arquitectura SOA, donde existe una alta frecuencia de interacción entre servicios conectados a través de distintas plataformas y tecnologías. Se debe proceder con cuidado en la detección de los servicios que requieran características transaccionales, y proceder a cumplir con la misma dentro de la solución. La correcta detección de estos servicios es clave para evitar una sobrecarga en los recursos y la calidad del sistema.

Referencias:

[1] http://es.wikipedia.org/wiki/ACID

[2] http://soapatterns.org/design_patterns/atomic_service_transaction

BPM y Enterprise Architecture

Dentro de toda organización IT moderna existen conceptos que no pueden faltar. Dos de ellos son BPM (Business Process Modeling) y EA (Enterprise Architecture): ambos están enfocados en el análisis y balance entre procesos, tecnología y reglas de negocio. Sin embargo, para su correcto funcionamiento es necesario entender las características y objetivos de cada técnica. Esto permite no sólo distinguir los casos donde cada una logra maximizar su potencial, sino también cómo una organización puede combinar ambos enfoques.

Características principales
BPM busca entender, mejorar, analizar y cuantificar los procesos que involucran las reglas de negocio. Si bien es una definición un tanto ambigua, está claro dentro de la comunidad IT su alcance y funcionalidad.

En cambio, dentro de lo que es EA, existen distintos enfoques. Por un lado, en la referencia [1], Michael zur Muehlen, profesor asociado en Howe School of Technology Management, la define como el proceso de entender, guiar y cambiar una organización desde una perspectiva basada en IT. EA propone describir sistemas complejos desde varias perspectivas complementarias.

Esta visión coincide con lo que en [2] denominan como “EA grande”. En esta referencia distinguen dos visiones de EA. Por un lado, la EA grande, involucrada desde un panorama global, busca dar arquitectura a todos los sistemas y estructuras que existen en la organización, ya sean relacionados con IT o no. En cambio, una “EA pequeña”, está solo enfocada en los sistemas IT.

Si se compara BPM con la EA pequeña hay poco por decir y hacer. Para esto es preciso analizar si artefactos relacionados con la EA pequeñas (aplicaciones, middleware o bases de datos) están involucrados en procesos inherentes a BPM. Una manera posible es analizar los inputs y outputs de los procesos BPM y ver si recaen en alguno de estos artefactos.

Si se toma la EA grande el desafío es mucho mayor, ya que se involucran otros aspectos fuera de IT. En esta versión, EA busca construir un visión global de cómo la organización desarrolla sus sistemas, y la utiliza para razonar sobre las relaciones entre los objetivos de negocio, estrategias de inversión, recursos y tecnologías.

Esta perspectiva está muy relacionada con BPM desde varios factores. Por un lado, BPM está orientada en el modelado, lo cual es clave para construir la visión global que EA requiere. Sin embargo, BPM es mucho más que el modelado de procesos. Incluye la ejecución de los mismos y su monitoreo, así como la adaptación a nuevos requerimientos. Esto genera un ciclo donde las actividades se retroalimentan a través de la tecnología. Por otro lado, EA se desentiende de la parte de “ejecución” y toma esta parte como un problema de alguien más. En este sentido, EA invierte un gran esfuerzo es distinguir y separar la planificación de los procesos de su ejecución.

En [2], el presidente de Enterprise Architecture Consulting Services (http://www.ea-consulting.com/) piensa a EA como una parte de BPM. Se comienza definiendo o visualizando un modelo integrado de procesos de negocio como funciones, considerando puntos de entrada y salida. En este contexto, EA funciona como una disciplina para la toma de decisiones tecnológicas, y juega un rol fundamental en el modelado de procesos BPM.

Como conclusión, es factible presentar a EA como la manera de obtener una construcción tangible de los productos IT de una organización. Esta perspectiva permite razonar en un alto nivel de abstracción, fundamental en toda decisión gerencial de alto impacto. Por otro lado, BPM permite modelar los procesos, obteniendo un análisis más detallado de cada paso involucrado para cumplir una determinada meta de negocio. Las posibilidades de colaboración son muchas, desde el análisis y modelado de procesos, pero en especial al momento de considerar soluciones tecnológicas.

Referencias:
[1] www.ebizq.net/topics/enterprise_integration_architecture/features/13306.html
[2] www.mwdadvisors.com/blog/2012/11/is-bpm-part-of-ea-or-ea-part-of-bpm.html

Métricas en BPM

Poder evaluar cuantitativamente una cierta característica o aspecto funcional de un sistema de software es una herramienta crucial dentro de la administración y gestión de proyectos de software. Esta motivación dio lugar a un área fundamental como lo es la aplicación de métricas al software. A través del uso de una buena métrica es posible definir de manera concreta si se están respetando los valores o términos acordados, o incluso, servir como guía para corregir errores. Por ejemplo, una medición de un valor no esperado es un indicador de problemas.

Las métricas en software son aplicadas a lo largo de todo el proceso de desarrollo, y pueden estimar la cohesión de un código, el acoplamiento entre clases, indicar una jerarquía de herencia demasiado cargada, detectar artefactos de software complejos, medir el flujo de entrada y salida de una clase en un diagrama de clases, etc. La lista es interminable. Trasladado al contexto del modelado de procesos de negocio, el rol de las métricas se potencia. El mundo BPM (Business Process Modeling) se ve enriquecido por la aplicación de métricas que guían y ayudan a mejorar la adopción de BPM en una organización [1].

El trabajo de Jim Boots [2], de la organización Global Process Innovation (www.globalprocessinnovation.com) da a conocer 14 métricas para BPM, las cuales están agrupadas en tres grandes categorías: Valor, Madurez, y Satisfacción. Las de la primera categoría están enfocadas en estimar el valor de impacto obtenido a través del modelado BPM de procesos de negocio. La segunda categoría presenta un conjunto de métricas destinadas a cuantificar la madurez BPM de la organización. Finalmente, la tercera categoría está relacionada con la satisfacción de los métodos empleados, tanto a nivel de los empleados como a nivel gerencial. A continuación se profundiza en cada categoría y se muestra algunos ejemplos destacados de métricas relevantes.

Métricas BPM de Valor
Las métricas en esta categoría incluyen el reporte de los incidentes involucrados y su frecuencia. Llevar el recuento de cada incidente producido lleva a entender y mejorar los procesos involucrados. Otra de de las métricas más destacadas en esta categoría es la que indica el porcentaje de proyectos de mejora de procesos que logran cumplir las metas esperadas. Para definir esta métrica es fundamental que cada área involucrada en un proceso logre la disciplina necesaria para definir con precisión qué entradas necesita para poder cumplir con la salida esperada, y cuánto tiempo le llevará.

Métricas BPM de Madurez
Las métricas de madurez miden el esfuerzo de la organización para involucrarse y comprometerse con BPM. Se estima todo lo invertido y los réditos esperados. La métrica más aplicada de esta categoría es contar el número de procesos de mejora, categorizándolos en comenzados, avanzados y completos, según su grado de adopción. A medida que la organización gane madurez, el ratio entre los procesos comenzados y completados irá decreciendo, mostrando así una mejoría en la performance general.

Métricas BPM de Satisfacción
Las métricas en esta categoría buscar cuantificar la satisfacción de clientes y gerentes en la adopción de técnicas BPM. Para medir la satisfacción de los clientes se prioriza los procesos de negocio. En general esta métrica busca el análisis a través de encuesta con distintas opciones de satisfacción a todos los gerentes involucrados. Para medir la satisfacción de los clientes, hay que considerar las zonas donde los clientes verán transformado el impacto en beneficio. Ejemplos de estas zonas son el tiempo y la calidad de las respuestas obtenidas. Se debe tener cuidado en dos aspectos a la hora de realizar encuestas a los clientes. Primero, no se debe sobrecargar al cliente con demasiadas encuestas, ya que podrían llevar a un impacto negativo de todo el proceso. Y en segundo término, hacer foco en los lugares donde BPM introdujo cambios, ya que este último aspecto es el que se está evaluando.

Referencias:

[1] http://www.processexcellencenetwork.com/business-process-management-bpm/white-papers/using-metrics-to-drive-bpm-excellence/
[2] http://www.globalprocessinnovation.com/uploads/5/5/8/1/5581580/fourteen_metrics_for_a_bpm_program.pdf

Patrones de colaboración en Agile

La colaboración es uno de los aspectos más importantes de los equipos exitosos de Agile. Sin embargo, luego de trabajar en muchos proyectos de este tipo, me di cuenta que la colaboración va mucho más allá del trabajo conjunto. La verdadera colaboración significa preguntar: ¿Cómo puedo ayudarte? En el sentido de ¿Cómo puedo ayudarte a cumplir tus objetivos y eliminar obstáculos? Esta pregunta debería ser parte de la cultura de los equipos y organizaciones que aprovechan Agile. El foco debe reordenarse en base al trabajo y los objetivos conjuntos.

En esta nota nos proponemos analizar patrones de colaboración de equipos Agile que están ayudando a múltiples proyectos en todo el planeta. Por Shrikant Vashishtha.

Swarming

Sin importar el framework de Agile con el que se trabaja, es frustrante encontrarse con un equipo que parece estar extremadamente ocupado, pero que no logra resolver ninguno de los items en progreso. Justamente, una de las claves de Kanban implica reducir el ciclo de las stories, moviéndolas a la columna DONE apenas sea posible. Hay un mantra que debería transformarse en el himno de cualquier equipo: "termina de empezar, empieza a terminar".

Al adoptar esta filosofía, muchos equipos colaborativos han virado hacia una cultura del Swarming. En este enfoque, en lugar de un único desarrollador que trabaja en una story, múltiples miembros del equipo se esfuerzan por terminar el tema lo antes posible. Swarming se presenta así como un aspecto cultural de la organización en equipos.

Roles y jerarquías

La colaboración prospera en aquellos ambientes en los que no hay jerarquías firmes. Agile no busca determinar roles específicos para los integrantes del equipo, ya que todos deben trabajar según un estilo generalista y con objetivos comunes. Pero en equipos y culturas con un enfoque jerárquico, no es poco común encontrarse con miembros que reproducen esta manera de relacionarse. Este enfoque jerárquico casi siempre mata al esfuerzo colaborativo.

Programación en pares

Si bien las estadísticas indican que los equipos de más alta performance casi siempre trabajan en pares, la realidad es que muchos desarrolladores prefieren descartar el la programación en pares sin considerarla. Su argumento parece ser lógico: asignar dos personas a la misma tarea, ¿no implica malgastar esfuerzos o recursos?

La realidad es que pair programming es mucho más que un equipo doble de trabajo. Este enfoque permite facilitar los desarrollos en base al diseño evolutivo, que busca un progreso dinámico y en base a metas claras. Además, el trabajo de pares hace que los desarrolladores no se distraigan en tareas individuales. Esto puede parecer sorprendente, pero permite que cualquier integrante del equipo se sume a la story en cualquier momento, como si fuera un corredor de relevos. Ya no hay islas ocultas de conocimiento. Este enfoque también permite que los integrantes clave del equipo puedan moverse a nuevos proyectos sin que se retrasen por un obstáculo en el desarrollo. De esta manera, el trabajo en pares es un patrón de colaboración importante, incluso en equipos remotos.

KPIs colaborativos

Los desarrollos en Agile implican un cambio cultural y no pueden reducirse a modificaciones en la manera en que trabajan los equipos. En muchas organizaciones existe una desconexión entre el trabajo en Agile y la estructura de la compañía, lo que puede traer efectos adversos en la colaboración. Por este motivo, es de suma importancia definir KPIs que respondan a las necesidades del conjunto, y dejar de lado aquellos que se centren en necesidades individuales.

Paredes de tarjetas

Muchas organizaciones trabajan tercerizando servicios para otras compañías. Como muchos de los clientes se encuentran en otros países, resulta lógico utilizar herramientas electrónicas como Jira, Trello o Rally para monitorear el trabajo del equipo.

Sin embargo, las herramientas electrónicas no siempre satisfacen las necesidades de monitoreo, y de hecho pueden transformarse en un punto de tensión. En su lugar, es posible aprovechar tarjetas físicas en una pared, lo que representa un método mucho más efectivo para conocer el progreso del proyecto. Trabajar con tarjetas físicas permite que los integrantes del equipo puedan moverlas de un lugar a otro para organizar la información rápidamente, y también agregar cambios y aclaraciones. Esto hace que los standups se vuelvan más cortos, y que el equipo se enfoque en el sprint en lugar del progreso individual.

Ventajas de Continuous Delivery

A medida que sucede el avance tecnológico, cambia la forma en la que el mercado sirve sus productos. En un futuro no muy lejano las empresas tenderán a vender “DevOps”, cosa que conlleva una maduración de varias prácticas a tener en cuenta.

Continuous Delivery no tiene otra premisa que darle a nuestro servicio la capacidad de obtener un producto con el mínimo esfuerzo y asegurando el más alto índice de calidad.

Estamos ante dos serios problemas: ¿Cómo aseguramos que nuestros equipos generen calidad y la mantengan en el tiempo? Y si eso no alcanza, ¿Cómo hacemos para que nuestro producto sea entregado sin esfuerzo y de manera segura?

Para asegurar calidad y que esta calidad sea estable, existe una práctica llamada Continuous Integration, la cual nos asegura entre otras cosas:

Cada cambio en nuestro código es acoplado.
Análisis estático de código.
Tests unitarios y de integración.
Building automático.
Tests de regresión.
Tests de performance.

Lo importante de los puntos antes mencionados es que son ejecutados de manera automática y periódica, por lo que nuestro producto siempre se encuentra bajo un análisis tan riguroso como deseemos.

Tecnologías relacionadas

A la hora de implementar estos conceptos existen varias tecnologías que permiten hacer el trabajo más fácil, como por ejemplo Jenkins, una aplicación Web que ejecuta las tareas de manera automática. Gradle, por su parte, nos permite crear scripts orientados al Continuous Integration basados en Groovy. Sonar Qube analiza el código provisto y recomienda modificaciones, y la lista sigue.

Para hacer el proceso de entrega sea con el mínimo esfuerzo y seguro, la primera respuesta con la que nos encontramos es la de hacer de este un proceso automático, el cual pueda eliminar los errores humanos que pudieran ocurrir en el despliegue de la aplicación (ya sea por problemas de creación del binario o problemas de configuración). También es importante tener en cuenta lo costoso que es tener a una persona (que generalmente es la de más seniority) ocupada en dicha tarea, que puede llegar a tardar más de un día, dependiendo de la aplicación en cuestión.

Alguna de las tecnologías que nos permiten realizar esta tarea son: Puppet, utilizada para la configuración de entornos nuevos; Cargo, para desplegar aplicaciones nuevas; Octupus Deploy, Run Deck, etcétera.

Cuestiones implementación

La implementación de una solución de Continuous Delivery no es un método sencillo ni un producto cerrado puesto que depende de la tecnología que estemos utilizando para crear el producto que queremos entregar, o los distintos procesos por lo que decidamos que nuestra aplicación tome parte. Existen cinco puntos que nos definen de manera abstracta como debe ser una solución de Continuous Delivery:

Simplicidad, a la hora de definir el proceso debe ser simple para que sea de fácil entendimiento.
Mantenimiento, el proceso no es algo que quede estable, siempre es necesario agregar nuevos pasos o maneras de implementar la solución.
Escalabilidad, la idea de cada etapa del proceso debe ser pensado para que pueda acoplarse rápidamente a los cambios.
Operatividad, el proceso de continuous delivery debe poder ser ejecutado por cualquier integrante o cliente sin importar el skill que este tenga.
Estandarización, cuando implementamos una solución estas deberían ser las mismas para todos los casos similares.

A nivel técnico nos garantiza que esta calidad está asegurada, pero para el management es una herramienta fuerte para poder demostrar la calidad a los clientes, poder mostrar métricas y reportes de como la calidad es aplicada. Los puntos en los cuales es beneficioso utilizar este proceso son muchos y desde los más diversos, la contra es el esfuerzo implicado en esta solución, aunque a la larga es altamente beneficioso.

La gran ola Mobile (primera parte)

Una de las tendencias sorprendentes de estos años ha sido el ritmo de adopción de las tecnologías móviles. Hemos visto cómo Facebook se transformó en un servicio móvil en 2013, con un increíble 73% de su base de usuarios accediendo desde dispositivos portátiles. Ahora, vemos cómo PayPal se transforma en un estándar para transacciones móviles, con un incremento del 93% en las operaciones con respecto al año anterior.

Mobile es la tecnología que más rápido se ha adoptado en la historia de la civilización humana, y está creando un nuevo terreno para usuarios y consumidores. De acuerdo a informes de la consultora IDC (International Data Corporation), los fabricantes vendieron más de mil millones de smartphones durante 2013, con un crecimiento del 38.4%. Para los consumidores, esta revolución significa libertad de uso, en tanto el poder de procesamiento se multiplica año tras año en sus bolsillos. Para las compañías, el nuevo mercado ofrece la posibilidad de llegar a miles de millones de personas casi instantáneamente.

La ola móvil ya está aquí y seguirá dando de qué hablar durante los próximos tres años. Los dispositivos móviles se han vuelto mainstream, y de hecho se espera que superen en capacidad a las computadoras tradicionales durante este año. Anteriormente experimentamos la ola del escritorio y los servidores, que comenzó en las empresas y luego llegó a los consumidores; en estos momentos estamos experimentando el proceso opuesto. El uso que hacen los consumidores impacta directamente en las decisiones de las empresas.

La oportunidad Mobile
Todas las compañías se están volviendo negocios digitales, y la construcción de excelentes experiencias móviles estará en el corazón de la estrategia de cualquier empresa dentro de los próximos diez años. Para muchas personas, Mobile es simplemente un nuevo canal para extender sus negocios. Sin embargo, si bien la tendencia omnichannel se ve bien en el papel, pocas compañías pueden realmente aprovecharlo. En su lugar, las empresas han traducido sus sistemas internos y su complejidad organizacional hacia los consumidores, y esto tiene que cambiar para mejorar el engagement y la confianza en la marca.

Simplificando, podemos decir que es necesario volver a enfocar e imaginar las experiencias móviles. Al mismo tiempo, y como podemos ver a continuación, no es solamente la tecnología la que está cambiando:

Nuevos modelos de negocio. El mundo digital abre la puerta a nuevos modelos que deben ser explorados. La industria de los medios es un excelente ejemplo de esta situación: ahora el contenido es el rey, pero la conveniencia de los usuarios es la reina. El servicio de Netflix ha aprovechado esta situación y hoy es una fuerza disruptiva dentro de Hollywood. Netflix provee películas y series según la demanda, lo que permite que los usuarios rompan sus lazos con las clásicas empresas de cable, o incluso los cines. El contenido se sigue consumiendo, pero de otra manera. La innovación en los modelos de negocio es indispensable en un mundo en donde los usuarios tienen acceso a toda la información en la punta de sus dedos.

Definiciones y mercados. Hasta hace poco, solíamos diferenciar a las compañías que se enfocan en el mercado de consumidores (B2C) de aquellas que lo hacen con otras empresas (B2B). Hoy en día, gracias a la tendencia BYOD (Bring Your Own Device) y al éxito de las plataformas SaaS (Software as a Service), estas definiciones pierden algo de su sentido. Mientras la fricción para los negocios se reduzca y los canales de engagement se automaticen, veremos que las compañías adoptan modelos "B2Any". De esta manera, las empresas buscarán mercados y consumidores en una escala masiva, y siempre con la personalización en mente.

Barreras borrosas. Las distinciones clásicas de la industria ya no son válidas en un mundo totalmente digital. La digitalización de los negocios está homogeneizando el campo y disminuyendo las barreras de entrada, lo que a la vez vuelve más borrosas a las líneas entre industrias. Por ejemplo, ¿Amazon se dedica a retail, medios o envíos? Las empresas ahora deben transformarse y pelear por la fidelidad de sus consumidores.

Verdadero tiempo real. Mientras progresa la digitalización de los negocios, el tiempo real se ha vuelto una característica indispensable. La capacidad de tomar decisiones "aquí y ahora" toma gran importancia en un mundo dominado por motores de recomendaciones a gran escala y plataformas de comunicación en tiempo real.

Nuevas maneras para móviles. Con el tiempo real a la cabeza, y mientras las líneas clásicas de lo que es una empresa están en discusión, las compañías deben encontrar nuevas maneras de aprovechar las tecnologías móviles. Por ejemplo, algunos hoteles ya permiten ingresar a las habitaciones utilizando al smartphone como llave.

Plan de acción
Para aprovechar las oportunidades que presenta este nuevo mundo de negocios, las empresas deben saber manejarse dentro de los mercados actuales y adaptarse a los múltiples desafíos que se presentan. Para muchas empresas se tratará de un esfuerzo de supervivencia.

Plataformas legacy. Los servicios de gran antigüedad pueden transformarse en un obstáculo para el funcionamiento de la empresa. El problema principal son aquellos sistemas que no están preparados para el enorme nivel de actividad que trae el mundo móvil. Las plataformas actuales se optimizan para transacciones y reducir costos, y no necesariamente para mejorar el engagement de los usuarios.

La importancia de UX. La experiencia de usuario se ha vuelto un punto clave en el éxito dentro del mercado. Luego de una década de interacción con plataformas amigables, los consumidores ahora demandan el mismo nivel en todos los servicios que utilizan.

Explosión de datos. La tendencia Big Data llegó para quedarse. Los datos indican que las empresas generan y almacenan más de 7 zettabytes en el año, número que se multiplicará 44 veces hasta llegar a 2020. Además de la capacidad de manejar gran cantidad de información, las empresas deben desarrollar servicios que puedan ser fácilmente integrados, tanto interna como externamente. Para esto las APIs son esenciales, aunque todavía no hay un enfoque estructurado que pueda abarcar tanta complejidad.

Por Juan Cabrera

URL copied!