Fe de erratas, omisión... sigo vivo

Ma acaban de reclamar por tener este blog tan descuidado y es que, segun yo habia hecho el anuncio de que iba a estar posteando en el blog de IT Builder, anyway, si por alguna razón usted todavia entra a este blog y piensa que desaparecí de la faz de la tierra, mis mas sentidas disculpas por no haber informado del cambio, por lo pronto voy a duplicar las entradas tambien en este blog.

La dirección del nuevo blog ( bueno, ni tan nuevo, tiene mas de un año) es :

http://www.itbuilder.com.mx/blogs/gabriel.oliva/

Saludos !!!!!
y gracias por seguir leyendo

Ya esta listo ! - Windows XP Service Pack 3 (SP3)

Para aquellos usuarios de Windows XP que constantemente actualizan sus equipos, pero sobre todo para aquellos que tiene la necesidad de soportar interacción entre Windows XP y Vista, Microsoft acaba de anunciar el release del Service Pack 3, el cual incluye algunas mejoras y actulizaciones sin cambiar la experiencia de uso, por el momento pueden descargar el Service Pack desde el sitio de Microsoft Update o desde el Download Center .

Para mas información del contenido de este SP3 para Windows XP :

http://technet.microsoft.com/en-us/windowsxp

Everyone is an Architect !!

Siempre he dicho que cualquier hijo de vecino se autonombra arquitecto de soluciones sin tener la menor idea de lo que eso significa, recuerdo hace algunos años que aquellos programadores Sr. de pronto se volvieron arquitectos y la diferencia entre sus diferentes roles era nula.

Aqui les dejo un excelente articulo que habla un poco acerca de la evolucion de este rol y nos puede ayudar a entender si realmente somos arquitectos o solo nos gusto el titulo (como en su momento lo fue el ser 'lider de proyecto')

have fun and do not adopt titles if you do not know what you're talking about :P

Software Architecture: Past, Present and Future
by Diego Dagum

What exactly is software architecture? Do we really need it? Why have we only recently been discussing it? Has some contagious fever suddenly infected those who claim to be architects? And who are these people anyway? Are they gurus, senior developers, or maybe just smooth-talking self-promoters?

These are questions that junior and senior developers are asking about software architecture and software architects. This article will address these questions and more, asking the forbidden question: "Can a developer become software architect?"


The Need for Software Architecture

Not so long ago, programming platforms were more self-contained. From robust and complex environments like mainframe COBOL to light and easy-to-understand xBase languages, the most important technical decisions were already taken. For software projects, that meant both benefits and drawbacks. A benefit, because where a decision exists, no time needs to be spent in discussions about the best way to do anything.

In non-enterprise environments (academics, small business), this solution model was adequate and successful for a long time. But it had drawbacks at the enterprise level, because there was one notorious downfall - "all-or-nothing" platforms were too rigid to adapt to the competitive, highly changeable environments required by a global economy. Also, during mergers and acquisitions, it's really hard to get two independent platforms to play well together.

Thus, component-oriented software was born with the goal of a new agility in scaling applications. Now we could choose among a broad set of platforms to produce modular pieces (or components) ready to be used by other components that were either made by us or by vendors. Once established that integration was not an issue, component orientation gained in popularity in the enterprise, where the technical decision makers became free to use the best platform and tools as solutions for specific problems, rather than be constrained to a specific platform as before. However, soon it became apparent that there was a need to plan and manage components to ensure success.


Defining Software Architecture

So, thanks to component-oriented software we could choose the platform which best fit a specific problem. Despite that, the paradigm shift of new platforms was difficult for many developers to learn. Thus, one of the first objectives of good architecture was to gently hide the complexity of new platforms and APIs behind easily understandable ones which were more focused in the context of the problem being solved (typically a business problem).

In that way, software architecture became a highway to develop business solutions in a timely, secure, and accurate manner. Under the pavement of that highway we still have pre-made technical decisions that architects had to take to make the developers' tasks easier.

The difference from past platforms is that now, rather than buying necessarily restrictive general-purpose software from a vendor, an organization's members can make their own decisions regarding the function of the business solution to be developed. This means we need to have this decision making ability in house. It means a new role, the Software Architect.


What Software Architecture Used To Be

Software architecture emerged from a bundle of practices applied by senior developers. Some of these merit mention:

Design Patterns. This all started with a book simply called "Design Patterns" that is still a best-seller. These patterns cover highly decoupled, reusable solutions for frequent problems about responsibility assignment in object-oriented programming (OOP). Actually, they merely solve these problems on a small scale, but surely this book sowed the seeds for a new way of thinking about applications, constituting the DNA of several enterprise systems. We suggest as a reading the article "Last Call to Design Patterns".

Architecture Patterns. In the days of Smaltalk, one pattern proposed an extraordinary way of decoupling user experience from persistence mechanisms. This pattern, the Model-View-Controller (MVC), granted the responsibility of user interaction handling to a component which played a role known as the "View". The "Model" component had the responsibility of keeping the business model state consistent. A third component, called the "Controller" interpreted events originated from the View, promoting changes in the Model state accordingly. This pattern permitted interchanging components of any role very inexpensively, thus enabling multi-channel applications (that is, applications available in a vast variety of platforms and contexts). Think beyond the typical dichotomy of client versus server. Think of ATMs, mobile phones, and other platforms. We have just to re-implement the View component in these use cases ("Bill payment," "Book service," and so on). The same applies to the Model. It is not just a discussion about Oracle versus SQL Server versus IBM DB/2 versus MySQL versus whichever. Think also of legacy mainframe environments versus XML files for smaller data repositories (useful to easily mount development environments where the whole infrastructure could not be present). This pattern brought not just execution distribution but development distribution. Development could be better organized in different teams working in an asynchronous manner thanks to the inherent decoupling capabilities of this pattern. Click here to read n discussion of this pattern.

MVC was just the beginning of patterns. Since the mid-nineties a series of books classified and organized many other architecture patterns. We recommend the Patterns of Software Architecture (POSA) books, Sun's Core J2EE Patterns, Martin Fowler's series, and -- with the launch of .NET -- the MS Patterns and Practices guides (which include an interesting, ready-to-use set of application blocks, see Frameworks, below.) For more information visit the Patterns and Practices Center.

Anti-patterns. A counter-concept grew in parallel with the concept of patterns. If a pattern is a best practice, an anti-pattern is a worst one. There is an infamous common anti-pattern, which aspiring architects and junior ones apply all the time: that of over architecting every software component. This is commonly expressed by immediately adopting the newest version of everything without actually considering if it is beneficial. Perhaps this is done with the misconception that doing so will provide a comprehensive, easy-to-change architecture in some near future. But experience is showing that the opposite is happening; nobody wants to touch unnecessarily complex solutions, so they remain "as is" until they are completely replaced. Click here for a discussion about this.

Frameworks. In a remarkable effort to enable largescale software production, a variety of component blocks (better known as frameworks) appeared. There are frameworks to solve the gap between the domain object model and the relational database schema (called Object/Relational Mappers); there are other ones intended to achieve a clean MVC componentization; and recently, a new generation of dependency-injection frameworks is dominating the scene. Dependency injection allows a component to not to be responsible for knowing what its dependencies are, it just has to know which interface they expose. Thus, any tier change will not impact on its associated classes, because they do not know each other directly. The undeniable success of dependency injection frameworks coined a reputation for them as lightweight (application) containers, in opposition to heavy, all-or-nothing solutions. There are some other specific-purpose frameworks: integration, monitoring, and so on. These all share one concept: to keep developers focused on business logic (functional requirements) instead of cross-cutting aspects like security, manageability, and other non-functional requirements.


Emerging Architect Roles

Economic changes, like globalization, technological achievements, and the Internet's impact on the digital economy, pressed for formalizing software architecture as a discipline. Although there is not yet a definite agreement in the distinct roles, we can sketch three major personas:


Infrastructure Architect. These define the platform and other environments (hardware, basic software) for business applications. They must also work with developers to define mechanisms and standards that allow applications to achieve the security, reliability, manageability, transparency, and policy compliance essential to the modern business. It's expected that the natural evolution of a senior IT professional is to become an Infrastructure Architect.

Solutions Architect. These are responsible for the design of one or more applications or services within an organization, usually within the scope of a division (and for that reason the role is also known as Application Architect). Examples of such applications are: Internet banking, company-wide knowledge sharing portals, and distributed point-ofservice (POS) applications. A senior developer is a good candidate to become Solutions Architect.

Enterprise Architect. Their job is to keep the business and its IT systems in alignment. They strive to maximize the return on IT investment by making sure that IT spending is prioritized towards business opportunity, and by optimizing the impact of investments across the organization's portfolios of services, resources, projects, and processes. They must act as a bridge between business leadership, development, and operations to ensure mutual understanding, realistic goals, and properly managed expectations. Enterprise Architecture is about the big picture -- how people and technology work together to produce world-class, long-term results. For that reason, this persona is also referred to as a Strategic Architect. What is expected is that a Solutions Architect or Infrastructure Architect becomes an Enterprise Architect.


What Software Architects are Concerned With Today

Recent years have been really challenging for software architecture. An elemental concept like service-oriented components (and its implementation using Web Services), gave place to a whole enterprise strategy known as Service-Oriented Architecture (SOA). SOA has as a goal the complete connection of the business application portfolio. Former silos like company CRM, ERP, and every other line of business (LOB) application, are expected to expose their functions to the others for synergy and mutual profit. The SOA challenge can be organized into five major areas to address:


Federated Identity and Access: How do we manage the authentication and authorization systems in a centralized way, available for every application? Once the user logs in, how do we propagate that identity to every service? How do we treat external customers compared to internal users? Do we treat them as just another role, or maybe we should consider a completely different policy?

Federated Data. How do we keep the distributed repositories synchronized? How do we gently gather enterprise entities by data aggregation? Which levels of redundancy are reasonable? How do we deal with offline situations?

Business Processes. Service-oriented components are granular pieces combinable in business workflows. Thus, every service could be seen as an activity to be executed in a definite order and upon definite conditions. The workflow engine becomes a sort of infrastructure piece in an SOA.

Service-oriented components. There are four tenets that the pieces must comply with to meet the SOA goals: explicit boundaries, autonomy, contract sharing, and policy-based compatibility. Those premises are discussed in more detail in an MSDN article Principles of Service Design: Service Patterns and Anti-Patterns.

Integrated User Experience. What does an SOA UI look like? There is a new range of UI frameworks around the concept of composed applications. We can find examples of them in CRM solutions and Web portal engines, where the UI is built through a combination of simpler, connected UI components.

The MSDN Architecture Center provides a complete reference of these capabilities.



Where Software Architecture Goes from Here

While concepts like patterns and SOA are already or are becoming mainstream, software architecture continues evolving and expanding to new spaces. Although this article is too short to discuss all of the other software architecture trends which build on SOA, like model driven architecture (MDA) or software factories, you can find more information on the Software Factories page in the MSDN/Architecture Center. There are two particular topics, not yet massively embraced but watched very closely by the industry and worth mentioning, they are:

Software as a Service (SaaS). SaaS is a new software delivery model, where companies do not really hold their LOB software bits, but only its right of use. From this, a new concept of software provider emerges (the so-called SaaS provider). Clearly, from the enterprise perspective, the inclusion of such software implies a certain impact. How do we combine a SaaS application, for instance, in the company's SOA? How do we manage identities, workflows, and so on? From the provider perspective: a multi-tenant issue arises. If the provider is renting the software - its infrastructure - to more than one enterprise customer, how can they enable further customization? Consider as examples various database schema, country policies that impact business processes, and other customer specific modifications. Perhaps even more pertinent, how do we scale the environment for a growing number of tenants? The MSDN Architecture Center granted Software as a Service its own space. Visit this page to learn more.

Web 2.0. Another area of architecture research is how to get the most of the writable Web, that is the Web based on participation. We talk about Web ads, blogs, wikis, and other implementations. Those participative applications have existed for a while. The point is how companies can benefit from them, merging these kinds of community applications into their enterprise architecture. How do we offer "the long tail" of those goods and services, each of which individually may not be the most desirable to implement (possibly the least), but surely all of them together are becoming important in terms of revenue.


Conclusion

We have reviewed how software architecture evolved from what software engineering was realizing about its existence, and the shifting of roles due to componentization. The first software architects were de facto architects, in the sense that nobody officially granted them such titles. It was just a common perception, a sort of consensus. But now software architecture is leaving behind its alchemist stage to become a scientific discipline.

Back From Redmond - [Bill Gates, Helsjberg, .NET ... and a lot of fun]

During the last weeks I've been breathing Microsoft every day [More than usual], I had the chance to assist to the Global MVP Summit 2007 in Redmond Microsoft Headquarters, it was and incredible week meeting experts from all over the world sharing points of view and comments about current and future Microsoft Techonology besides the experience of being at the Bill gates keynote .



Anders Helsjberg.

Vista, y en el futuro movimientos agresivos de Novell y Microsoft

Finalmente y despues de unas semanas verdaderamente extenuantes por fin tuve tiempo de probar algunas de las capacidades de desarrollo sobre windows Vista, la verdad es que estoy emcionado por los features nuevos de Office 2007, sin embargo sigo sufriendo la falta de drivers que sean soportados por la version Ultimate (lo cual es una verdadera lastima para los nuevos equipos HP Pavilion Slimline) por lo que por el momento solo me conformo con ver features de media center e imaginar los de 'aereo', por si fuera poco y para que fuera mas evidente la rapidez con la que la tecnologia se vuelve obsoleta ... Microsoft y Novell anuncian estrategias de compatibilidad cruzada, hace algunos años alguien me preguntaba el porque Novell podria interesarse en comprar SuSe y recuerdo haber mencionado la hipotesis de la integracion entre las 2 plataformas ('mono' ya figuraba en las compras de Novell), por lo visto no me equivoque, asi que esperemos a ver que sucede en algunos años con esta integracion, el crecimiento y evolucion de los productos Microsoft y la batalla de gigantes (Microsoft vs Google) por la conquista de millones de usuarios

The future is here ... and Windows Vista is part of IT

Excelent tour through all the new opportunities that come along with Windows Vista

Open XML Format (Microsoft Office Open XML Format)

I've just seen a very interesting webcast about Open Xml Format for Office 2007 and demos were awesome, and I belive that this new Architecture effort will bring a lot of new oportunities for devs, final users, but also for organizations that align to use this type of technologies, one of the most outstanding benefits is that along with xml sections structures, all office suite includes a ZIP based funtionality that allows to reduce the size of OPEN XML documents a lot more than you can do normally with binary files compressed by any engine.

Lets wait until this is released, but in the meantime you can know more about this topic here ... don't forget to visit source forge Open XML Translator project website

IT Architect Spoke Broadcast (MSDN Latam Webcasts)

Since the birth of this space It's been a personal interest to promote 'Real Architecture Practices', Due to the lack of what I consider Real Architecture Staff in Mexico, I'll start delivering some topics in colaboration with Micorosft MSDN Latam in order to promote the design and use of reusable fremworks and design patterns adoptions.
I'm glad to invite all of 'IT Architect Spoke' readers to the next month Architecture Webcasts, here is the agenda:


Implementación del patrón ‘Inyección de dependencias’ con Spring Framework
Registro en linea: Webcast 1032309109

Código del evento: 1032309109
Fecha inicial: 04/10/2006
Hora inicial: 02:00 PM
Fecha final: 04/10/2006
Hora final: 03:00 PM


Diseño de Capas de Acceso a Datos con la técnica ORM (Mapeo Objeto – Relacional)
Registro en linea: Webcast 1032309113

Código del evento: 1032309113
Fecha inicial: 12/10/2006
Hora inicial: 02:00 PM
Fecha final: 12/10/2006
Hora final: 03:00 PM


Diseño de arquitecturas orientadas a servicio de bases de datos
Registro en linea: Webcast 1032309115

Código del evento: 1032309115
Fecha inicial: 19/10/2006
Hora inicial: 02:00 PM
Fecha final: 19/10/2006
Hora final: 03:00 PM


Creación de modelos de fábricas de software con VS 2005
Registro en linea: Webcast 1032309117

Código del evento: 1032309117
Fecha inicial: 26/10/2006
Hora inicial: 02:00 PM
Fecha final: 26/10/2006
Hora final: 03:00 PM

Be a .NET Protector !! (coding secure .NET apps)

Microsoft ha tomado en serio la seguridad y para muestra basta un botón, visite el sitio de .NET Protector y aprenda paso a paso como generar aplicaciones seguras, el programa sigue el mismo esquema que DCE (Desarrollador 5 Estrellas) y considera los siguientes niveles:

Verde / Aprendiz (1). Un desarrollador en este nivel estará "alerta de la seguridad", y tendrá un conocimiento profundo del "Ciclo de vida del desarrollo de sistemas seguros y confiables". Este nivel cubrirá la siguiente información, e incluirá un webcast y diversos podcasts para complementar la lectura:
a) Un resumen del "Ciclo de vida del desarrollo de sistemas seguros y confiables".
b) El proceso y ciclo de vida de desarrollo seguro.
c) Implementando el ciclo de vida de desarrollo seguro en Microsoft.
d) Resultados de implementar el ciclo de vida de desarrollo seguro en Microsoft.
e) Observaciones acerca de implementar el ciclo de vida de desarrollo seguro en Microsoft..

Amarillo / Héroe (2). El segundo nivel introducirá a los participantes en las nuevas herramientas de seguridad integradas en VS2005. Cubrirá el uso del Code Analizyer, el Application Verifier, Buffer Security Check, las librerías Safe CRT, FxCop, Code Access Security/Least Privilege, Click Once Deployment y Debug in Zone. Un desarrollador que pase este nivel será considerado un "Héroe"..

Azul / Súper Héroe (3). El tercer nivel cubrirá los Fundamentos de seguridad en aplicaciones web, trampas y modelos de trampas de modo de entender las vulnerabilidades de las aplicaciones web, defensas y contramedidas, para proteger sus aplicaciones ASP.NET de los hackers.

Rojo / Maestro (4). El cuarto nivel revisita el mismo contenido de la fase 1, que está basado en el libro "19 pecados capitales de seguridad de software", como así también contenido adicional de "Escribiendo código seguro".

Leyenda (5). El quinto nivel requiere que el participante que ha llegado al 4to nivel transmita el conocimiento en seguridad que ha ganado, a la vez que promocione el programa Net Protector Academy a sus desarrolladores conocidos. También será incentivado a hacer de mentor de otros desarrolladores, ayudándolos a progresar a través del programa. Aquellos desarrolladores que intenten completar este nivel ganarán puntos por todos los participantes que hayan referido al programa, y además ganarán puntos por cada nivel que estos avancen. Además, necesitarán crear contenido en la forma de un webcast, un video "How to", un podcast o un artículo. Este contenido será juzgado por sus pares dentro de la Net Protector Academy, y basados en su respuesta, el participante pasará o fallará en un "examen final". Una vez que el participante gane una cierta cantidad de puntos a ser determinados, se convertirá en un Héroe Legendario del software seguro.

HAVE FUN :)