... eso era antes de que apareciera Iceberg, una plataforma de construcción de aplicaciones sin programación bajo un concepto PaaS (Platform as a Service) similar al de force
What is Iceberg? Iceberg is a 100% web based platform for building, sharing and selling powerful business applications.
What can you do with it? Build or configure your own apps using workflow, forms, reports, lists, web services, views, relational tables, charts, calendars and much much more...
How to start? Iceberg comes with several powerful free applications for HR, CRM, Project Management, Rostering, Bug Tracking and more...
Then what? Run your applications on our enterprise SAS-70 platform, sell them via our exchange or share them for free
¿Quién se atreve?
Vía: listible.
7 comentarios:
No conocía el producto y no pinta nada mal.
Eso sí, estas herramientas que funcionan en un muy alto nivel están muy bien, hasta que se fastidia algo. Entonces no tienes a nadie que pueda solucionártelo a no ser que tengas a un tío especializado en plantilla y esagente cuesta de conseguir y aún más de mantener.
Saludos.
Los chicos de Benioff han empezado a etiquetar estas propuestas como Development-as-a-Service. (http://wiki.apexdevnet.com/index.php/DaaS)
Phil Wainewright apunta también otras plataformas para construir aplicaciones empresariales. (http://blogs.zdnet.com/SAAS/?p=438)
Estoy con «pepito» para las aplicaciones críticas, y ni siquiera teniendo esos tíos en plantilla…
Creo que otra cuestión relevante es la que plantea Greg Olsen sobre ser consistente y emplear servicios externos de infraestructura. (http://gigaom.com/2008/02/14/how-not-to-end-up-as-an-anachronism)
El gran problema viene luego cuando ésta se "viene abajo" (lo que pasa interna y externamente, aunque es más probable la primera). (http://gigaom.com/2008/02/15/amazon-s3-service-goes-down)
Yo siempre he comparado estos incidentes críticos con los accidentes de tráfico por carretera y los de aviación.
Estoy con vosotros pepito y JoséM, para una aplicación crítica habría que pensárselo por esos dos motivos:
1)disponibilidad de recursos - pero eso aplica a cualquier herramienta, sea "SaaSy" o no. Y si me apuráis a cualquier ERP lo tengas alojado donde lo tengas - la capacidad de reacción autosuficiente es siempre un factor crítico
2) El tener el sistema fuera de casa y a) se cae el sistema (como pasó ayer con la plataforma de Amazon) o se te corta la línea de comunicaciones (aunque para esto se pueden redundar accesos)
Gracias por comentar
JoséM, bienvenido a los comentarios. Veo que compartimos lecturas
Con tu experiencia como consultor ¿Recomendarías un proyecto de ERP sobre force o iceberg? Existiendo aplicación ERP de todos los niveles uno ve difícil empezar algo nuevo en SaaS. Que los actores que controlan ya el modelo de negocio tradicional empiecen a probar SaaS bien, pero que como proveedor te líes la manta a la cabeza e intentes montar un ERP nuevo ahí ¡Uf! Y lo digo yo que tengo en la mesa todos los papeles para montar "mi" propio CRM. Pero lo quiero hacer no con convicción comercial sino técnica.
Lboisset, HOY NO lo recomendaría porque falta bastante hasta que este concepto sea implementable.
Pero creo que el futuro de las aplicaciones de negocio deberá ir por ahí - no se puede aguantar que cada implantación de ERP sea como un parto. Estamos en la prehistoria o en el Ford de 1904, donde todos los coches salían iguales y del mismo color, y el que lo quisiera distinto pues a modificarlo.
La Ingeniería del software y de las aplicaciones de negocio en particular, no ha resuelto todavía este gran problema de la adaptabilidad a infinidad de requerimientos particulares. Se intenta resolver desde el lado de la aplicación únicamente (OO, SOA, BPMs, ...) pero no se ataca el lado del usuario/empresa - estandarización de procesos sectoriales y horizontales, iteroperabilidad de formatos, ...
Nos queda un largo camino, ... afortunadamente para los consultores, ... ;-))
Saludos
Tic, creo que el desarrollo basado en «componentes» reutilizables, reemplazables, readaptables… (CBD, OOP, SOA, ESB) es un buen enfoque para facilitar mucho esos "partos". Ya hay aplicaciones de negocio que lo aplican. Por este lado creo que se va avanzando en el sentido correcto.
También me parece que la implementación en el business software de los procesos operacionales o de negocio se va a facilitar mucho mediante herramientas tipo BPM y, más recientemente, con las propuestas DaaS que antes comentábamos. Puede que no valgan directamente para aplicaciones transaccionales heavy duty, pero sí para congigurar los muy diversos componentes (módulos encapsulados a nivel bastante desagregado) de los ERPs.
Opino que lo que se puede estandarizar se puede mecanizar (y hay muchos ingeneiros que se dedican a eso). También que los consultores podrán dedicarse más a ayudar a los empresarios a entender mejor las necesidades de los clientes y a diferenciarse de los competidores.
Muy de acuerdo contigo JoséM en que es una buena dirección, aunque en mi opinión estamos aún su infancia más temprana.
Desde mi punto de vista de consultor lo que más me gusta de estos enfoques es que se desacopla la capa tecnológica de la capa de procesos, liberando así a los usuarios de negocio de servidumbres de las aplicaciones que soportan esas capas de negocio - los próximos años van a ser apasionantes en el desarrollo de estos conceptos... nos vamos a divertir sin duda
Gracias por los comentarios
Publicar un comentario