En la segunda etapa se logró visualizar en el 2014, lamentablemente se escucho el problema con las integraciones tecnológicas y el diverso software que se construyo que era productivo pero no esta ínterconectado con el núcleo central (por el problema de la curva de aprendizaje con la tecnología propuesta, esto también pasa con tecnología de IBM/Oracle/Microsoft), la dirección fue cada dependencia debe construir de acuerdo a un esquema de datos propuesto por GOB.MX, esto era un poco problemático para sistemas financieros ya que estos emplean un gran cantidad de reglas de negocio por detrás y aplicar una reingeneria podría ser muy costoso, pues si bien se logró modelar un interface de los núcleos contables y financieros para cubrir dicho requerimiento, asombrosamente hay dependencias de gobierno como IMSS donde si cumplieron y cumplen con los lineamientos de Gobierno Federal, el modelo esquema de tramites lo encuentras en el diseño de sus base datos y sistemas (aunque hay que señalar que en IMSS hay muy poco presupuesto para tecnología y en su caso se ven muy recortados en comparación con otras dependencias que manejan valores monetarios, lo único que hace funcionar tecnológicamente dichas dependencias es su gente que asombrosamente hacen maravillas con lo poco que tienen), otra competencia que tiene en esta segunda etapa fueron los ingenieros “full stack” mayores de 35 años que tiene habilidades de diseño y construcción muy avanzandas, ellos pueden sacar un casos de uso complejos en menos de 1 semana y gracias a su amplia experiencia hacen la instalación hasta producción de su desarrollo, este tipo de mecanismo hizo que algunos proyectos que se sumaron a GOB.MX salieran a luz y por primera vez se viera la intención del proyecto.
La tercera etapa fue la especificación de software, esto considero una gran táctica para salvar el proyecto aunque puede ser rudimentaria y simplista para otros, se podrán notar que en algunas dependencias se empezó a encontrar areas UX (User experience) -felicidades por ello- , son cédulas que se componen de equipos de 3 diseñadores gráficos (como mínimo), líderes de negocio y gerentes de alguna linea de negocio quienes se componen en una etapa del proyecto para realizar el diseño de la interfaz gráfica de casos de uso, aquí fue donde GOB.MX dio en el clavo, si se revisa la especificación de software de interfaz se encuentra publicada en su sitio, es una librería con css, js, jquery y bootstrap básicamente en IMSS sacaron juego los ingenieros "full stack" ventajas para construir con servicios rest (mvc) y dinámicamente producir formularios web adaptables (se puede encontrar interfaces elegantes con la poca infraestructura tecnológica que poseen); el fenómeno que se logro observar es adaptabilidad, el organigrama de trabajo es imprescindible en una organización por lo que si involucras a los distintos equipos para simplificar el diseño y desarrollo se puede lograr un cambio; otro punto importante fue no solo agregar una hoja de estilos al sistema si no lograr integración y modularidad en el diseño de posteriores pantallas, también se hace revisión de protototipado de interfaz, desde el lenguaje empleado en pantalla hasta revisión con abogados de los datos que se exponen, eso fue una actividad importante a capturar y copiar.
Hay distintas historias en el proyecto, en mi curva de aprendizaje obtenida por participar en dichos sistemas con dependencias quienes resolvieron el problema adaptándose a factores internos y externos; consultores, líderes, gerentes y directores a quienes agradezco la oportunidad que me brindaron al ser parte de su proyecto y que indudablemente tratan de hacer un Mexico mejor a costa de su salud y bienestar personal y familiar.
Fin
Best regards,
Hace algunos años tuve la oportunidad de ser parte en el desarrollo de algunas integraciones con GOB.MX en el Servicio de Administración Tributaria de México y en Instituto Mexicano del Seguro Social, proyecto que si bien era muy ambicioso por la idea de centralizar todos los trámites de diversas dependencias de gobierno en un solo sistema único, por lo que todas las dependencias brindaran interfaces de servicio para dar el soporte de sus reglas negocio, si no tuviera conocimiento o no hubiera sido participe en proyectos de gobierno federal diría que no es una tarea compleja, bueno pues resulta que la lógica, reglas, secuencia, flujos de cada tramite suelen ser complejos unitariamente, si lo pensamos de cierta manera son esos libros de legislación de mas 800 páginas que se convierten en sistemas; en mi opinion personal GOB.MX se puede dividir en 3 etapas para el hecho de salvar sus iteraciones, bueno inicialmente la idea era la centralización de tramites, lo siguiente fue normalización de distribución de tramites en dependencias y por ultimo convertirse en una especificación de diseño de sistemas, ¿Que ocurrió con la idea innovadora y revolucionará de reducir el proceso?, bueno fueron muchos factores a mi punto de vista y a mi parecer mas buenos que malos, ademas de la curva de aprendizaje obtenida la cual fue interesante.
En el año 2013 me encargaba de la construcción de aplicaciones a nivel back-end, mi primer contacto con el equipo GOB.MX de Guadalajara fue asombroso y de respeto mutuo ya que me toco entablar dialogo con un equipo joven, lleno de muchas expectaciones y energía, manejaban tiempos apretados en las primeras etapas de construcción pero si bien con gestión e ingeniera logramos exponer en tiempos las interfaces que era solicitadas, uno de los problemas en lo que yo llamo la primera etapa fue la tecnología propuesta, algunos sabemos en que tecnología se estaba construyendo el núcleo central de aplicación y el service bus que se empleaba, recuerdo haber aplaudido la tecnología propuesta (software libre -gemas y mula-) la razón es que era una curva de conocimiento innovadora en su tipo y en México era primeriza ya que es muy poco conocido que se apliquen dichas tecnologías integrar y manejar amplio volumen de información; otro problema en la primera etapa fue que no aplicaron una táctica en proyectos “primero conoce tu ambiente”, si bien hay diversas dependencias de gobierno con diversos niveles de presupuesto desde la secretaria de economía hasta la secretaria de salud, puedo decir que cada una posee diversas infraestructuras tecnológicas y niveles de transacción que pueden ser con un nivel de concurrencia de 1000 hasta 1 por sistema, digamos facturación electrónica y patronatos de salud son grandes sistemas en la federación, la función requerida era estudiar dichos sistemas para revisar sus procesos con el fin de obtener sus puntos fuertes y construir una estructura genérica de arquitectura tecnólogica, mesas de trabajo donde debió ser requerido entablar relaciones con los creadores de dichos sistemas para homogeneizar un común denominador entre sistemas de amplio volumen y después hacer sintomatología con sistemas de mediana y pequeña escala en donde se podría apreciar si el diseño prototipo podría funcionar, hay dependencias donde hay manejo de php, java, .net, cobol y python e inclusive hay dependencias en donde hasta aceptan completamente nuevas propuestas tecnológicas (principalmente se interesan en BPMN y Service bus) virtualmente es una tarea difícil y es requerido arquitectos con amplia experiencia, con aptitudes y cualidades para analizar el problema muy rápidamente con el fin de diseñar y construir soluciones en base a su amplia experiencia profesional, básicamente lo que tenían que aplicar que aplicar era la ciencia de datos, científicos de datos que compusieran una mecánica, arquitectura y especificación de software, pero realmente ¿existe este tipo de personas en gobierno federal?, la respuesta increíblemente es si y son asombrosos, normalmente los tienen escondidos y reservados para los grandes proyectos, en la Secretaria de Salud (IMSS) hay científicos de datos (consultores, maestros y doctores de alrededor de 45 años que revisan y construyen las “arquitecturas"), en Servicio de Administración Tributaria de México hay grupos de líderes de proyecto, gerentes, directores y consultores que están haciendo muy bien su trabajo (están dando de que hablar en otras dependencias y empresas privadas por su buen servicio), Secretaria de energía y economía existen otros proyectos ambiciosos donde se pudo haber obtenido el común denominador de sistemas distribuidos y con amplia recolección de información; puedo decir que en lo que llamo la primera etapa fue la vision del proyecto lo que falto analizar y desarrollar.
Fin de primera parte.
Best regards,
Hace algunos años tuve la oportunidad de ser parte en el desarrollo de algunas integraciones con GOB.MX en el Servicio de Administración Tributaria de México y en el Instituto Mexicano del Seguro Social, proyecto que si bien era muy ambicioso por la idea de centralizar todos los trámites de diversas dependencias de gobierno en un solo sistema único, por lo que todas las dependencias brindarían interfaces de servicio para dar el soporte de sus reglas negocio, si no tuviera conocimiento o no hubiera sido participe en proyectos de gobierno federal diría que no es una tarea compleja, bueno pues resulta que la lógica, reglas, secuencia, flujos de cada tramite suelen ser complejos unitariamente, si lo pensamos de cierta manera son esos libros de legislación de mas 800 páginas que se convierten en sistemas; en mi opinion personal GOB.MX se puede dividir en 3 etapas para el hecho de salvar sus iteraciones, bueno inicialmente la idea era la centralización de tramites, lo siguiente fue normalización de distribución de tramites en dependencias y por ultimo convertirse en una especificación de diseño de sistemas, ¿Que ocurrió con la idea innovadora y revolucionará de reducir el proceso?, bueno fueron muchos factores a mi punto de vista y a mi parecer mas buenos que malos, ademas de la curva de aprendizaje obtenida la cual fue interesante.
En el año 2013 me encargaba de la construcción de aplicaciones a nivel back-end, mi primer contacto con el equipo GOB.MX de Guadalajara fue asombroso y de respeto mutuo ya que me toco entablar dialogo con un equipo joven, lleno de muchas expectaciones y energía, manejaban tiempos apretados en las primeras etapas de construcción pero si bien con gestión e ingeniera logramos exponer en tiempos las interfaces que era solicitadas, uno de los problemas en lo que yo llamo la primera etapa fue la tecnología propuesta, algunos sabemos en que tecnología se estaba construyendo el núcleo central de aplicación y el service bus que se empleaba, recuerdo haber aplaudido la tecnología propuesta (software libre -gemas y mula-) la razón es que era una curva de conocimiento innovadora en su tipo y en México era primeriza ya que es muy poco conocido que se apliquen dichas tecnologías integrar y manejar amplio volumen de información; otro problema en la primera etapa fue que no aplicaron una táctica en proyectos “primero conoce tu ambiente”, si bien hay diversas dependencias de gobierno con diversos niveles de presupuesto desde la secretaria de economía hasta la secretaria de salud, puedo decir que cada una posee diversas infraestructuras tecnológicas y niveles de transacción que pueden ser con un nivel de concurrencia de 1000 hasta 1 por sistema, digamos facturación electrónica y patronatos de salud son grandes sistemas en la federación, la función requerida era estudiar dichos sistemas para revisar sus procesos con el fin de obtener sus puntos fuertes y construir una estructura genérica de arquitectura tecnólogica, mesas de trabajo donde debió ser requerido entablar relaciones con los creadores de dichos sistemas para homogeneizar un común denominador entre sistemas de amplio volumen y después hacer sintomatología con sistemas de mediana y pequeña escala en donde se podría apreciar si el diseño prototipo podría funcionar, hay dependencias donde hay manejo de php, java, .net, cobol y python e inclusive hay dependencias en donde hasta aceptan completamente nuevas propuestas tecnológicas (principalmente se interesan en BPMN y Service bus) virtualmente es una tarea difícil y es requerido arquitectos con amplia experiencia, con aptitudes y cualidades para analizar el problema muy rápidamente con el fin de diseñar y construir soluciones en base a su amplia experiencia profesional, básicamente lo que tenían que aplicar era la ciencia de datos, científicos de datos que compusieran una mecánica, arquitectura y especificación de software, pero realmente ¿existe este tipo de personas en gobierno federal?, la respuesta increíblemente es si y son asombrosos, normalmente los tienen escondidos y reservados para los grandes proyectos, en la Secretaria de Salud (IMSS) hay científicos de datos (consultores, maestros y doctores de alrededor de 45 años que revisan y construyen las “arquitecturas"), en Servicio de Administración Tributaria de México hay grupos de líderes de proyecto, gerentes, directores y consultores que están haciendo muy bien su trabajo (están dando de que hablar en otras dependencias y empresas privadas por su buen servicio), Secretaria de energía y economía existen otros proyectos ambiciosos donde se pudo haber obtenido el común denominador de sistemas distribuidos y con amplia recolección de información; puedo decir que en lo que llamo la primera etapa fue la vision del proyecto lo que falto analizar y desarrollar.
Best regards,
