Cloud Pública

¿Qué deberíamos exigir a una Cloud pública?. Al menos lo siguiente:

1. Capacidad de cómputo: Servidores y Software base necesario para instalar y ejecutar las aplicaciones. Debería haber varias "tallas" de máquinas y con diferentes sistemas operativos disponibles. También debe ser posible el dimensionamiento más o menos automático.
2.  Almacenamiento: Almacenaje de ficheros digitales (imágenes, documentos de texto, vídeo, …) y con diferentes rendimientos. No es lo mismo almacenar logs de aplicaciones que probablemente nunca vamos a consultar que vídeos accedidos por nuestros usuarios.
3. Seguridad de red y al balanceo de carga: Debe ser posible hacer segmentación de redes y distribución de la carga entre los distintos segmentos. Es decir, es responsabilidad nuestra diseñar la topología de red en una cloud (aunque sea pública) y por lo tanto debe ser posible hacerlo.
4. Servicios gestionados: La cloud pública debe permitir centrarse en labores propias de nuestro negocio dejando el "heavy lifting" para sus técnicos. Es decir la administración y operación de las infraestructuras y software (backups, incidencias en infraestructura, etc...) debe ser posible delegarlo en el proveedor.
5. Despliegue y versionado de aplicaciones: Al final, lo que casi siempre va a pasar es que necesitemos desplegar nuestras aplicaciones en la nube. El servicio en cloud deberá disponer de herramientas que faciliten el desarrollo y el despliegue de aplicaciones en la nube.

Hay muchas más cosas pero teniendo en cuenta estos puntos tan simples podemos ir profundizando en qué nos ofrece cada proveedor de cloud.

Some thoughts about IT Development Strategy

It is commonly accepted that the definition of Strategy is a high level plan to achieve one or more goals under conditions of uncertainty.

By the definition, we can tell at least two things: first, that there cannot be a “magic bullet” because you have to define your goal before defining the strategy and the goals may vary between enterprises. And the second thing is that it is not going to be easy because of the uncertainty factor.

So, What can we do?. Software Engineering has tried, for some years now, to find an answer. Many methodologies like ITIL, CMMI, COBIT or lately TOGAF have proved very useful to better manage the IT departments and somehow they also helped with the strategy. All of them promise to “add value” because the role of IT is changing from being a support department to be the core of the business. In fact many IT terms has been applied to business (Service Oriented Enterprise, Process Focused Organization,…).

It is not my intention to make a digression about the several methodologies currently in the market, nor about the different organization’s types. I’d rather express my personal beliefs based on my own experience even though they don’t match with any methodology and they are nothing but some principles I think useful to have in mind when setting a strategy.

First principle: Simplicity. Simplicity means different things in different contexts, but applied to IT Strategy or to IT development, simplicity is related with efficiency. You probably don’t need the latest “cool” technology to do that report and you are adding an overhead any time you use something new in your technology stack (yes, you will need someone who knows about the new cool thing, pay for maintenance, patchs,…). Does it mean that you never have to use new technologies?. Short answer, NO. You have to carefully evaluate the pros and cons and I dare to say you should estimate a ROI (it can be your own flavour of ROI) as the business people do. In my opinion, simplicity should be in the DNA of any organization.

Establish a process. Some one could say, “A process?, What about simplicity?”. A process is overhead when we are taken into consideration an isolated development or only one system deployment. When we are talking about Enterprise IT, establish a process is the best way to learn what is working for you and what is not. Thus, a process is, at least, a very good information source about how you are doing and also the only way to add quality to the final product.

Promote TEAMS!. I have seen many times people working in the same place; they call it a team but they were not. Ideally, team members must have complementary backgrounds and skills, sharing common goals, have a foreseeable shared future, and share a common fate. Let’s face it. At the end of the day you have to rely on your people to do the right thing and a team is better than an individual by far. People can do amazing things working together.

Knowledge Management. Internal resources (internal teams) most often cannot cope with all the work and you have to seek help outside. That’s good in many aspects. New points of view, new skills, fresh air…. But there is one thing you never can let go. Knowledge. In your strategy, there must be a way to ensure that you do not depend on someone’s good will (establish a process and promote team working can be on handy). It is your duty to keep the situation under control at all times.

Try to have your own Royal Marine Corp (in many places known as Architecture Team). When talking about development, there’s always the requirements definition thing. The business users want something that they don’t know but they would recognize if they could see it. Well, the Royal Marine Corp can produce something very quickly. Mobility applications, Social Networking integrations, the Cloud Computing applications, you name it. When there is no time, your reduced but highly motivated and skilled team can do the job.

In summary, in my vision, there is the central principle of keep it simple, try to be reliable, your people is the most valuable thing you have, don’t lose control and sometimes you need a commando to do the dirty job.

Promotores Vs Constructores

Un tema conflictivo en cualquier organización es el coste del desarrollo IT. Es decir, ¿cuanto cuesta hacer tal o cual aplicación?. Desde la ingeniería del software se han dado varias propuestas para resolver este problema pero que, en mi modesta opinión, no sirven para el cliente que encarga el desarrollo software. Básicamente, estas técnicas de estimación están orientadas a las empresas que desarrollan software como su negocio principal, por lo que pueden conocer datos significativos como la preparación de su gente, la calidad de sus herramientas, el histórico de proyectos, etc...
El cliente que subcontrata el desarrollo no tiene nada de esto y siendo realistas, lo que suele ocurrir en la práctica, es que el cliente final pregunta a diferentes empresas de construcción de software en cuanto estiman el coste. El problema de esto es que normalmente no está definido lo que se quiere hacer por lo que las estimaciones pueden ser muy variables y además las sorpresas son frecuentes.
La propuesta que yo hago es fijarse en otros sectores. Por ejemplo, un promotor de viviendas puede ser que no tenga ni idea de cuanto vale poner 5 ventanas de doble cristal con aislante térmico de primera categoría ni falta que le hace. Lo que sí sabe es cómo es la clientela en esa zona, cuanto está dispuestos a pagar por una casa de unas determinadas calidades, cuanto debe ser el margen y cuanto está dispuesto a invertir él. Con estos datos, es ya una misión del de la constructora (que sí sabe cuanto le cuestan a él las ventanas) el dar una memoria de calidades y un presupuesto

El E-Commerce

No pretendo disertar en este blog sobre el significado del E-Commerce ni sobre sus posibilidades. Se han escrito Teras de información sobre este particular así que no creo que yo pueda aportar mucho en este campo.
Lo que sí me gustaría es reflexionar un poco sobre el E-Commerce y su relación con el concepto de "aldea global". En nuestras ciudades y pueblos, lo normal es que haya una carnicería en el barrio y una panadería y una joyería....Si la población es suficiente incluso se pueden especializar estos comercios y hacer que aparezcan más. Por ejemplo, puede haber pastelería y panadería, a veces dos de cada pero es muy raro que haya cuatro o cinco, ¿no?.
Pues en el E-Commerce yo creo que va a pasar lo mismo. Si la logística no lo impide veremos dos o tres tiendas de cada ramo en todo el mundo, seguramente la más competitivas (ya sabéis, la mano invisible del mercado). El resto simplemente no tiene sitio.

Aplicaciones en USB revisited

Lockheed Martin ha ido un paso más allá de lo que proponíamos en este post y ha decidido que su personal en movilidad no use portátiles si no llaves USB con un sistemas operativo propio y con mecanismos de cifrado para garantizar la privacidad.
En este artículo podéis ver más información sobre la funcionalidad de estos dispositivos.

Aplicaciones autocontenidas en una llave USB

En la página portableapps nos explican como podemos llevarnos nuestros programas favoritos de un pc a otro. Para un usuario particular esto puede ser útil si por lo que sea tiene que usar varios pcs y no le interesa instalar todo el software que necesita en todos y cada uno de los pcs.
Para una empresa, las aplicaciones portables pueden tener otra dimensión. Le permite extender su sistema informático a otros empresas. Es decir, si por alguna funcionalidad de negocio hay que darle una aplicación a otra empresa, no se tendría que instalar el software en una máquina de esta segunda empresa. Se podría dar la aplicación en un USB con todo lo necesario para que funcione.

Se podría alegar que al entregar el software en un USB el cliente lo podría copiar al disco duro, a otro usb, etc, y de alguna manera romper la ventaja de tener un entorno autocontenido. Pues bien, con un simple script en Visual Basic se pueden hacer una serie de comprobaciones que aseguren que el código se está ejecutando en la llave USB correcta, por ejemplo, una unidad de nombre "XXXXX" y un determinado número de serie. Pego un código de ejemplo:

strComputer = "."


' Obtención de la letra de unidad


Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")


' Comprobación de S/N del fabricande del HW

' Cogemos el número del fichero
Const ForReading = 1
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile _
("configuracion.properties", ForReading)
strNextLine = objTextFile.Readline
arrServiceList = Split(strNextLine , ",")
SnFichero = arrServiceList(0)

' Hacemos la búsqueda entre los dispositivos físicos conectados al equipo
Set colDevices = objWMIService.ExecQuery _
("Select * From Win32_DiskDrive Where InterfaceType='USB' and PNPDeviceID like '%" & SnFichero & "%'")

if colDevices.count = 0 then ' No hemos encontrado el dispositivo
Wscript.Echo "El dispositivo de nombre XXXXX no está conectado."
else ' El dispositivo existe
Wscript.Echo "El dispositivo de nombre XXXXX está conectado."

' Comprobación de los datos de la unidad lógica asociada al pendrive
Set colDisks = objWMIService.ExecQuery _
("Select * from Win32_LogicalDisk where VolumeName='XXXXX'")
if colDisks.count = 0 then ' No hemos encontrado la unidad lógica
Wscript.Echo "Se ha modificado el nombre del dispositivo de XXXXX."
else ' La unidad lógica existe
For Each objDisk in colDisks
letraUnidad = objDisk.Name
Set colProcesses = objWMIService.ExecQuery( _
"select * from win32_process Where Name = 'Wscript.exe'" )
For Each objProcess in colProcesses
rutaEjecutable = objProcess.CommandLine
' Buscamos la letra de unidad en la ruta de ejecución del proceso
resultado = instr(rutaEjecutable,letraunidad & "\script\Def4.vbs")
' Wscript.Echo letraUnidad & " - " & rutaEjecutable
Wscript.Echo "Ruta de ejecución del script: " & rutaEjecutable & VbCr & "Letra de unidad XXXXX: " & letraunidad
if resultado <> 0 Then
Wscript.Echo "Se está ejecutando en el pendrive."
else Wscript.Echo "NO Se está ejecutando en el pendrive."
end if
Next
next
end if
end if

El ROI en la inversiones tecnológicas

En algún post como éste, contaba mi modesta opinión sobre añadir herramientas informáticas sin pararse a pensar en el proceso subyacente. Hoy me he encontrado este artículo en donde se va un poco más allá y se afirma que no existe ROI en realizar inversiones puramente tecnológicas.

¿Entonces, cómo decidir abordar un proyecto tecnológico?. Llevado el argumento al absurdo, si no hay retorno de la inversión, nunca se debería realizar ningún proyecto tecnológico, ¿no?. Pues bien, y aquí está el quid del asunto, lo que se dice en el artículo es que el ROI existirá en la medida en la que la tecnología pueda cambiar la naturaleza del trabajo realizado y este cambio se puede medir con elementos más o menos familiares a las empresas como son los cuadros de mando que muestran el "Business Performance".

En definitiva, y aunque tire piedras sobre mi propio tejado, no puedo hacer otra cosa que estar de acuerdo con el autor del artículo y personalmente he asistido a muchos despliegues de herramientas en donde todo el mundo estaba empeñado en que no se debía cambiar la forma de hacer las cosas y el objetivo era adaptar la herramienta a lo que ya se estaba haciendo, costase lo que costase.

Como me dijo una vez un compañero, un clavo lo puedes clavar con una piedra pero si tienes un martillo.... Yo añadiría, ¿de verdad tienes que usar un clavo?.