Microservicios y sentido común

 A propósito de microservicios, comentados en otras recientes oportunidades, un par de observaciones de Mika Yeap en Medium. Aquí se menciona el monolito más como una antiguedad que como una aplicación que integra todo en un sólo ejecutable. Esto tiene más sentido y va en la dirección en la que los mocroservicios actúan, o deberían, cuando corresponda.

Una razón que Yeap reconoce es la escala. Arquitectura distribuida y microservicios para atender el crecimiento de elementos y operaciones en el sistema del que se trate. Pero al hablar de escala, habla de escala global, de decenas o centenas de millones de nodos participantes:

There’s a multitude of reasons you’d need to use distributed architecture when you get big enough. The catch is most of us will never get big enough. I mean, how close are you to Amazon’s numbers? Or how about Netflix? That’s what I thought.

Yeap recuerda que trabajar con microservicios no es simple, y requiere disponer antes una organización robusta, disciplinada, con conocimiento y recursos. Aún así, recomienda pasar a una arquitectura distribuida sólo cuando sea imprescindible, y conservar "el monolito" mientras sea viable: 

...it’s best to challenge this beast only if you’re prepared. Skills. Talent. Organization. You need lots of things in the right flavor to do this well. If you think you can show some engineers a couple keynotes then send them off to split all the things, you’re in for a nasty surprise. My team and I weren’t prepared, so I would know. I mean, what does a startup without product-market fit or money have to offer against microservices? Just a month’s supply of ramen to feed five people. In other words, not much but goodwill and some elbow grease. Which wasn’t enough.So as far as I’ve learned, you should only be building microservices if you’ve got a gigantic user base, or the resources to support the specialized development. And even in the first case, you don’t necessarily have to go distributed immediately. In fact, even AirBnB was powered by a monolith until just recently. A monolith written in Ruby on Rails, no less. And it seems to me that their product worked just fine.

Yet many people truly believe distributed architecture is a superior alternative to a monolithic one. People actually think they’re two equal solutions to the same problem. Which is absurd, since they’re actually solutions to different problems.

...Y recuerda que la arquitectura distribuida no es simple, en absoluto. Podemos decir que cada punto que merece foco en su implementación requiere soluciones complejas. Pone como ejemplo las transacciones distribuidas:

Microservices promise to solve all sorts of problems, depending on who you ask. When in reality, they only exacerbate them when you don’t know what you’re doing. How? Well, just two words can send chills down any microservice veteran’s spine: Distributed transactions. How’s that for a nightmare? I promise you, once you have to configure orchestration-based sagas just to update one property on a single object, you’ll be begging for a good old boring monolith.

En fin, microservicios suena genial, pero antes de emprenderlos, piense y haga números.

 

¿Monolitos? ¿Qué monolitos?

 Si atendemos a las definiciones de sus propios favorecedores, creo que se aboga por microservicios apoyándose en una entelequia que poco tiene que ver con el mundo real de las aplicaciones corrientes. Tomado de A Deep Dive Into Microservices vs. Monolith Architecture, por mencionar un caso que dice apoyarse en los estándares (aunque no menciona a Martin Fowler):

What are monolith architecture?

Monolith simply refers to one block containing all in one piece. According to Wikipedia, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

Y siguiendo su referencia a Wikipedia:

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

A monolithic application is self-contained and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function.^[1] Today, some personal finance applications are monolithic in the sense that they help the user carry out a complete task, end to end, and are private data silos rather than parts of a larger system of applications that work together. Some word processors are monolithic applications.^[2] These applications are sometimes associated with mainframe computers.

In software engineering, a monolithic application describes a software application that is designed without modularity.^{[citation needed]} Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement.

Modularity is achieved to various extents by different modularization approaches. Code-based modularity allows developers to reuse and repair parts of the application, but development tools are required to perform these maintenance functions (e.g. the application may need to be recompiled). Object-based modularity provides the application as a collection of separate executable files that may be independently maintained and replaced without redeploying the entire application (e.g. Microsoft "dll" files; Sun/UNIX "shared object" files).^{[citation needed]} Some object messaging capabilities allow object-based applications to be distributed across multiple computers (e.g. Microsoft COM+). Service-oriented architectures use specific communication standards/protocols to communicate between modules.

In its original use, the term "monolithic" described enormous mainframe applications with no usable modularity.^{[citation needed]} This, in combination with the rapid increase in computational power and therefore rapid increase in the complexity of the problems which could be tackled by software, resulted in unmaintainable systems and the "software crisis".

Es decir, si vamos a considerar "monolito" a una aplicación que en un solo ejecutable procesa los datos, define toda la lógica, y contiene la propia interfaz de comunicación con el mundo, probablemente haya que remontarse a 1970 o poco más (the term "monolithic" described enormous mainframe applications with no usable modularity).  Con seguridad, hace cuarenta años que ese paradigma no existe, salvo que incluyamos en él a las corrientes "apps" moviles. Como el propio artículo de Wikipedia menciona, simplemente la modularidad y la posibilidad de mantener una aplicación separada por responsabilidades de servicio existe no menos que desde los 80 del siglo pasado, y más atrás desde que lenguajes de alto nivel como el COBOL existen. Sólo un mal diseño, pésimo diseño, podría poner  todos los aspectos de una aplicación en un solo componente: podemos decir que existen otros modelos distintos que practican la modularidad y la separación de responsabilidades desde mucho antes de que se hablara de microservicios. 

Oponer Microservicios/Monolitos es sesgado y parcial. Otras arquitecturas/tecnologías se han desarrollado y perfeccionado para combatir los indudables perjuicios de un "monolito". Si vamos a la discusión del artículo en Wikipedia (siempre hay que ir a la historia y a la discusión), los observadores críticos del artículo así lo hacen ver:

The article lacks proper references and has a down view of the concept instead of explaining what it is. The article is also very focused on explaining what modules are and why they are good, getting out of the topic. I would go a step forward and say that this article has wrong information. 

El artículo de Wikipedia habla de "data silos". Este es un punto muy interesante y hay que verlo por separado, en otro momento. 

Pero establecer un paradigma opuesto que sea la panacea, requeriría un poco más de trabajo. Podemos decir que contra esa figura de "monolito" se ha trabajado durante treinta o cuarenta años (por ejemplo OOD/OOP), antes que se proclamara que los microservicios  son la solución.

 

Elemental, Watson

 Leyendo publicaciones técnicas hoy, tan pronto como levantan la vista al nivel de arquitectura, parecería que lo único que existe es una arquitectura basada en microservicios, y lo demás es monolitico y repudiable (o peyorativamente, simplemente monolitos de la prehistoria). Dice Atul Mittal, en Medium:

Is it always necessary to have Microservice Architecture instead of Monolithic Architecture?

The answer is NO, BIG NO. You should very understand the efforts and the value your product brings in. Generally, at first, implementing Microservice Architecture is a very tedious task, you need to have a separate Team/Architecture for each component that you need to have in your Application and a lot of thought process goes into that which might not be a viable option for small companies or Application built in very less budget, so there comes a saviour way to create Applications in “Monolithic” fashion or you can also say “traditional” way of creating Applications. If there are not so many components in that case also, you can think to adopt a “Monolithic’ way of doing things. But keep in mind, to modularize your application as much as possible so that later in case you want to redesign it in a “Microservice” way you don’t face many challenges in doing so.

Objeciones a SOA

Johannes Ernst dedica una nota breve a SOA, explicando algunas razones por las que podría decirse que SOA está muerto ("SOA Is Dead; Long Live Services"):

Some of us, including your’s truly, always felt like cringing when overzealous IT architects would sing SOA’s praises — long before anything got delivered to anybody that actually worked. Some risk factors were obvious:

• How can you hope to glue together system A and system B in any way unless you have a very clearly articulated and jointly managed cross-system information model?
• Same about event models, security models, etc.
• Far too little attention was paid to release management of services supposedly usable by other people. As a result, many composite applications were almost never up, because interfaces kept changing. This is not an easy one for corporate IT that does not usually have the funding or expertise for that kind of thing. (Side note: we now have the same problem, internet-scale, with OpenID, OAuth, and the like. Nobody has solved that one either, which is why often, "OpenID does not work" for some user who uses an unusual IdP/RP combination)
• Caching. Any production implementation has to consider that servant systems are not always going to be available, that they might not be able to bear the load at all times, that they may not always be fast enough, and that whatever information is obtained from them has to be related (and thus cached, and kept consistent!), to information in the client app. Otherwise there is no point to do it in the first place. Not an easy problem to solve.

Plex 7.0 disponible

Desde hace unos pocos días está disponible la versión 7.0 de Plex, con buenas novedades especialmente para la variante .NET, soporte de Azure, servicios web, java/JEE (pensado para java 7), y el uso incrementado del API de Plex. Un aspecto que especialmente valoro es que su aparición mantiene un ciclo relativamente corto de actualizaciones.
La persistencia en el trabajo sobre el API del modelo facilita además la labor de partners, que pueden crear extensiones con mayor control sobre el modelo. Podemos decir que Plex sumado a las extensiones que explotan el API abierto, permiten cubrir ampliamente las plataformas existentes y las emergentes. En particular, estoy esperando en algunos días ver el primer ensayo sobre Windows 8 Metro, la ejecución de una aplicación construída con WebClient (Plex generando Java, HTML5, JavaScript, y CSS3). Considerando la evolución de Windows 8, creo que tenemos garantizada una nueva actualización de Plex en un ciclo más corto que el anterior.
Un documento de presentación está disponible en el sitio de CA.

Plex: A tres días de la conferencia

Esta semana, desde el 23 hasta el 25, se desarrolla la cuarta CA 2E/Plex Worldwide Developer Conference. No estaré, pero espero que el próximo año sea distinto. En el sitio de la conferencia puede consultarse el programa de sesiones para los tres días (a propósito, la grilla del programa de actividades está hecha con Plex y XML).
Quisiera destacar de su contenido, la nota inicial de Simon Williams, capaz de dar una visión en perspectiva del producto, considerando que es su constructor inicial. Y luego, la gran cantidad de material sobre la orientación de Plex a servicios Web y aplicaciones Web: Plex y WCF, desarrollo con Ajax, Plex y XML, y otras de mucho interés. Se puede observar una gran potenciación de la actividad de terceros, tanto empresas como usuarios individuales.
Trataremos de disponer aquí las presentaciones o sus enlaces públicos tan pronto estén disponibles.
La conferencia en la Wiki (estarán seguramente aquí las presentaciones).
La conferencia en Facebook.

El desarrollo guiado por modelos está muerto?

En los últimos días, se han extendido dos o tres certificados de defunción; rápidamente se ha dado por muerto a SOA, y ahora (bueno, ya hace uno o dos años algunos teóricos darían por muerta alguna variante) también al desarrollo basado en modelos (MDA, MDD, MDE y otros semejantes). En la muy reciente Model Driven Software Network, se ha abierto una discusión sobre este asunto, que tiene la virtud de exponer los puntos débiles del paradigma, o estándar, según cuánto esté cada uno adherido al estándar MDA de OMG. La crisis económica sin duda empuja a la simplificación de costos, y esto alcanza a las "olas" de novedades tecnológicas: sólo lo que tenga verdadero valor quedará, o al menos, rebrotará.
¿Es MDD una ola comercial?. Claramente, no. MDD es la etapa actual (seguramente no la última) de esfuerzos comenzados hace quizá más de veinte años, con la aparición de las herramientas CASE. Puede extinguirse una rama de desarrollo, un punto de vista de cómo lograr el objetivo, pero la meta en sí ha sido reafirmada contínuamente por la industria y la comunidad académica. Puede incluso que se demore o estanque su crecimiento bajo las actuales circunstancias, pero no más.
Repasando la discusión en curso en The Model Driven Software Network, las principales objeciones van encaminadas particularmente al punto de vista MDA (Model Driven Architecture), y dentro de él, a la capacidad de UML de representar la dinámica de un modelo; UML, se afirma, es capaz de generar clases basadas en el modelo estático, pero luego es necesario completar el código generado escribiendo código que describa su conducta (behavioral). Así, Vlad Varnica afirma que el modelo UML suele ser abandonado tras la primera iteración ("The model driven and the iterative approach are not compatible"), porque la regeneración de código elimina el código manual, que debe ser reinsertado. Esta y otras participaciones en la discusión ponen el acento de las dificultades de adopción en este punto. Tiempo atrás, esta fue una objeción de los proponentes del modelo Software Factory (Jack Greenfield, Steve Cook, Keith Short), cuestionando en bloque la capacidad de UML para facilitar el modelado y la generación automática de código (En realidad, SF tampoco promovería simplemente la generación automática de código, sino una combinación de agentes, que no descartaría el código manual).
Creo haber comentado en distintas ocasiones que la herramienta que utilizo (Plex) no requiere centralmente UML; puede interrelacionarse con un modelo estático UML, pero no lo necesita: El modelo construído en su caso puede expresar igualmente su aspecto estático, pero, fundamentalmente, es capaz de expresar su aspecto dinámico dentro del modelo con toda la precisión que se necesite. En ocasiones puede requerirse código manual para acciones muy específicas, pero integrado de tal manera en el modelo, que no es afectado (no es sobreescrito) en una regeneración (una iteración). De tal forma, se logra un objetivo fundamental: que dada una aplicación, ésta sea expresada en el modelo de manera prácticamente completa. Esto tiene dos consecuencias muy importantes: es posible derivar del modelo la aplicación a distintas plataformas, y es posible modificarlo (sin temor a la regeneración del código).
¿Y a qué viene este comentario? A que el punto básico cuestionado a MDA/UML, que es su baja capacidad de describir las acciones, métodos, eventos, puede ser resuelta por alguna vía. En fin, que no se trata de un desarrollo en vía muerta, sino de un desarrollo que todavía debe encontrar el medio de resolver un obstáculo. Podríamos decir que uno de sus cuestionadores más agresivos del último tiempo, Software Factories, hoy está más comprometido que su escarnecido rival (MDA), a tal punto que los grandes críticos hoy vuelven a UML...

Plex Beta 6.1

En un mejor ciclo de desarrollo que en releases anteriores, la versión 6.1 de Plex está en Beta, por un mes más, aproximadamente. En estos días estoy ocupado probando. Para cualquier interesado ajeno a Plex, lo más interesante en el 6.1, es el desarrollo de aplicaciones para SOA. Del documento de sumario del release:

Model-Based Service Development
This feature strengthens CA Plex support for SOA development by providing model-based service development capabilities directly in the product. Services are represented as objects within the Plex model, using the component modeling approach already established for COM and EJB objects.
WCF service generation is supported with this release and a plug-in architecture enables developers to create their own service generators.
WCF Service Generation
Windows Communication Foundation (WCF) is a new communication
subsystem within the Microsoft .NET Framework that unifies several different communication technologies such as web services, .NET remoting, message queuing, and so on.
The WCF service generation in CA Plex r6.1 enables you to present business logic as services based on WCF. This can include business logic developed in the Plex model and logic from third-party applications.
Service Wrappers and Cross-Platform Interoperability
The new WCF service generation is designed to support the convenient wrappering of existing applications as services. This includes Java, i5/OS, and .NET programs. Generally, this means that the target of a FNC implemented by FNC triple can be a Java or RPG function. In the case of RPG, the target function can correspond to an i5/OS program developed outside CA Plex, such
as i5/OS programs or programs developed with CA 2E.

Hay otras mejoras, en Java, en Iseries, en el manejo del modelo. Pero esto es particularmente interesante.

Code Generation 2008 finalizada

A finales de junio se efectuaron las sesiones de Code Generation 2008, anunciada aquí dos o tres veces. Centrada en las distintas variantes de desarrollo basado en modelos, ha continuado progresando en extender su uso, y en debatir el peso y alcance de las distintas vías de construcción de software. Las sesiones predominantemente ocuparon las dos tendencias corrientes en modelado: las distintas variantes del estándar de OMG, Model Driven Architecture, y las distintas ofertas de Domain Specific Languages; dos temas relacionados de particular interés, también tratados, son las relaciones con Lineas de Producto Software, y la aplicación a arquitecturas orientadas a servicios (SOA). Comentarios de algunos de sus participantes, en los blogs de Mark Dalgarno y Pedro Molina. Las presentaciones están disponibles en el sitio de la conferencia. El programa, mencionado en alguna nota anterior, da una idea del alcance de la conferencia.
Steve Cook y Bran Selic estuvieron a cargo de las keynotes. Y un excelente grupo de investigadores tomó a su cargo cada tema.

UML, DSL, y Microsoft

En junio ya hemos conversado sobre el repentino interés de Microsoft en UML. Anticipado por el propio Bill Gates en su keynote de Microsoft Tech-Ed 2008, la noticia ha hechado a rodar con amplitud, y hará más camino seguramente. Es interesante el párrafo que Gates le dedica al tema:

[Respondiendo a una pregunta sobre UML] we'll have additional support for UML in Visual Studio 10 for the specific modeling tools that are there. Then as we move forward and take the modeling platform to the next layer, we'll get even more ability for you to create your own models.

So, you're absolutely right that the modeling world is fairly disparate today. Even at Microsoft our people who do our business applications have some of their modeling environment. Excel in a sense is a pretty limited modeling type environment.

The thing that we've recognized is that by bringing those things together we can actually enable new things like what you do across the lifetime of an application. And underneath these models we actually use UML.

We think it's very rare -- a very rare person would actually want to look directly at the UML because it's so kind of abstract, but underneath, both in terms of exchange with other people's products and some of the exchange we're doing between our own products, we do have UML based subscriptions of these models.

Jack Vaughan y Michael Meehan han dado su opinión sobre este interés, y algo de sus dichos creo que da en el clavo: luego de alentar DSL versus UML, realmente una herramienta que articule la totalidad de un modelo es necesaria (And underneath these models we actually use UML...). DSL es un concepto positivo y conveniente, pero hacer pasar todo por lenguajes específicos de dominio es inapropiado, probablemente difundido más como una operación comercial que como una realidad. Primero, no todo dominio será expresado en un DSL, y segundo, sigue quedando en pie cuál será el pegamento que englobe conceptualmente el conjunto como un sistema; ¿la factoría de software?, o dicho de otra forma, ¿el Visual Studio Team System?.
Parafraseando a Jacobson, Vaughan dice:

Noted software technologist Ivar Jacobson, one of the original "Three Amigos" responsible for UML, said the problem of transforming representation between specific domains is not trivial.

"With DSLs, the problem is you need to have underlying semantics in common. You have a serious transformation problem across domains," said Jacobson, head of Ivar Jacobson International. "UML has a profile that allows you to have specific language constructs, but it has the same underlying model."

With DSLs, common semantics are very difficult to achieve.

Meehan va en la misma dirección a propósito de SOA; su punto de vista es que no es casual que al intentar poner un pie en SOA, sea necesario un medio de expresar lo que haya en común:

Yet Oslo is Microsoft’s Hail Mary pass over the rest of the SOA market and apparently the company has decided to end its religious differences with UML for the sake of giving Oslo mass appeal. Previously Microsoft had been pushing domain specific languages (DSLs) as an alternative to the general purpose format of UML. Unfortunately for the folks in Redmond, DSLs have failed to gain much traction. Part of the problem is getting the people who form a domain to agree upon a standard syntax. Another part is having that DSL interact with anything outside of its domain. Those things surely will come with the march of time, but the uptake has been painfully slow.

SOA demands some commonality, that everyone stop trying to be so special and idiosyncratic. Microsoft has always understood that on some levels, but it’s got skin in the proprietary software business (actually it’s got skin, blood, muscle, bone, you name it). Its maverick tendencies have often led to it offering users products that do SOA the Microsoft way. That is in stark contrasts to the company’s Web services tooling, which has for the most part embraced open standards and heterogeneous systems (most notably Windows Communication Foundation). This is where I remind some readers out there that, yes, there truly is a difference between SOA and Web services.

In fact, one way to look at Oslo, which supposedly will offer a Community Technical Preview in September, is that this is Microsoft’s flag in the ground for SOA. It emphasizes the importance of modeling, attempting to bring the technology as close as possible to the business. As such, UML represents an excellent choice. It should create interoperability between Oslo projects and those built with rival modeling tools (e.g. IBM Rational). And Eclipse’s Modeling Development Tools Project will have a UML2 component ready by the end of the month.

UML gives Oslo a reach it never would have had if it were based on a proprietary modeling language. The UML foundation means Oslo stands a chance of being truly universal, which is as SOA a concept as you can get.

Así, comenzamos a dejar de ver al UML y su significado básico como bosquejos escritos en servilletas a la hora de conversar...

Réquiem por BEA

Stefan Tilkov, inventor anticipado de las entradas de blog mínimas, suele exponer material más que interesante, particularmente en temas de arquitecturas orientadas a servicios, especialmente, sobre REST. Ayer publicó una con un nombre apocalíptico (The Day that Middleware Died), que remite a la reflexión de Stuart Charlton sobre la absorción de BEA por Oracle. Dos tipos de observaciones son de interés en su Oda a BEA: su análisis sobre las causas de la caída de BEA, y sus observaciones sobre arquitectura.
Sobre BEA:

(...) by late-2006 I felt BEA was losing its way. The initial AquaLogic push was good, but it spread our engineering resources thin. BEA's SOA vision, which started well, became something of an empty marketing slogan, like how '.NET' was destroyed within Microsoft.
(...) One could see Oracle's acquisition as the culmination of BEA's failure to emerge from the dot-com bubble burst. I don't entirely buy it -- Alfred managed to grow the company to $1.5b from $950m in 2001 when Coleman, then CEO, left. That's quite an accomplishment, if short of expectations. BEA was still performing, people were still buying its products, and a lot of the b.s. about JBoss or other competitors eating its lunch are rather exaggerated, in my opinion. I claim no real insider information, and am speaking for myself when I say, there is one primary, clear, reason for BEA's failure, in my opinion, and anyone "on the ground" in the company would likely agree with it: after the early-2000's recession, finance & legal -- the bean counters -- became the kings of the company. In other words, I believe BEA's wounds were self-inflicted.
Once the goal ceased being innovation & great software, it was about a pristine balance sheet, milking the support organization, and onerous following of extremely conservative accounting guidelines. There were still leaders -- Alfred Chuang still had fire in him, some product executives like Guy Churchward were bright spots, Paul Patrick in the architecture organization was also a great source of ideas (but given power far too late). Many in the sales organization knew how to make customers feel valued, and were rewarded righly. But all of them were beholden to the bean counters. Oh yeah, and there was an options scandal that one hoped would shake the power of the finance department. (It didn't.)
(...) WebLogic Server continues to be, in my opinion, the gold standard of J2EE application servers (and I've used most of them). Yet it's maddening that something as important as their management console -- arguably the defining feature of the product vs. open source alternatives! -- became dog slow. WebLogic Workshop was productive for specific products but made the transition to Eclipse years later than it should have. AquaLogic Service Bus was a visionary product, and has some great understated features for validating the dependencies amount service artifacts. But it's lack of support for RESTful services is also maddening, considering how little work would need to be done (for starters, just enable PUT and DELETE, folks!). AquaLogic DSP was another visionary product, but way too programmer-centric in a world where programmers don't give a crap about data. They needed to target the DBA or the RESTful crowd, but the small & dedicated team was too busy trying to improve the core engine with the resources they had. BEA WebLogic Integration v8.1 SP2+ was the swiss army knife of integration tools, and probably the best game in town circa 2003-2006. WLI could smoke Oracle BPEL on performance, usability, and complex transformations. But v9 was disastrous. WebLogic Portal had one of the most ambitious set of goals, and an extraordinarily bright team. But they too were plagued with quality issues, arguably due to a lack of bandwidth, and a need to compete with Plumtree internally. The Plumtree team got off to a great start with the PEP products, but I doubt if we'll ever see the fruition of that idea.

Sobre arquitecturas:

One could say that it's "the day that middleware died". Perhaps that's a good thing, in the long run. In many respects, we have a new approach to middleware that surrounds us, if only we'd take advantage of it.
(...) It also didn't help that I had stopped believing that SOA would make anyone's life any easier, and reading some of the ITIL v2 material that was guiding our efforts also really just seemed to reinforce that we were following in the grand tradition of "smart people building skyscrapers to nowhere"

En cuanto a Stuart Charlton, agregado al Reader.

Las últimas adquisiciones de empresas de software

Comentado ya por medio mundo, sólo dos palabras: Sun compra MySql, y Oracle compra BEA. Continúa la tendencia a la concentración de operadores en cada área, aunque en este caso se trata de modelos de negocio distintos: abierto o propietario.
La noticia de SUN/MySql:

"The combination of MySQL and Sun represents an enormous opportunity for users and organizations of all sizes seeking innovation, growth and choice," said Marten Mickos, CEO, MySQL. "Sun's culture and business model complements MySQL's own by sharing the same ideals that we have had since our foundation -- software freedom, online innovation and community and partner participation. We are tremendously excited to work with Sun and the millions of members of the MySQL open source ecosystem to continue to deliver the best database for powering the modern Web economy."

La noticia de Oracle/BEA:

On January 16, 2008, Oracle announced that it has entered into an agreement to acquire BEA Systems, Inc., a leading provider of enterprise application infrastructure solutions. The proposed transaction is subject to closing conditions, including regulatory, shareholder and other approvals. Until the deal closes, each company will continue to operate independently, and it is business as usual.
The addition of BEA is expected to accelerate innovation by bringing together two companies with a common vision of a modern service-oriented architecture (SOA) infrastructure and will further increase the value that Oracle delivers to its customers and partners.

Leído en El Economista, Pensamientos ágiles, Wall Street Journal, James Gosling, entre muchos otros.

La red en el futuro

Que la creciente importancia de la web está cambiando ampliamente la construcción y utilización del software, es indudable. Cambian arquitecturas, posibilidades, instrumentos, recursos, y participantes. El grupo de tecnología de Wharton comenta uno de los aspectos que prefiguran claramente cambios en la ubicuidad y movilidad del uso del software: la integración de las aplicaciones de escritorio y la web. En su artículo sin firma, Wharton balancea a los principales contendientes y los distintos puntos de vista para lograr este objetivo, y también juega una opinión.

On October 1, Adobe Systems announced an agreement to buy Virtual Ubiquity, a company that has created a web-based word processor built on Adobe's next generation software development platform. One day earlier, Microsoft outlined its plans for Microsoft Office Live Workspace, a service that will combine Microsoft Office and web capabilitiesso that documents can be shared online. Recently,Google introduced a technology called "Gears" that allows developers to create web applications that can also work offline. The common thread between the recent moves of these technology titans: Each company is placing a bet on a new vision of software's future, one which combines the features of web-based applications with desktop software to create a hybrid model that may offer the best of both worlds.

Wharton ve dos estilos, uno que viene de una historia basada en el escritorio, y otra que nació en la Web, de tal forma que el acento está puesto en la red o en la estación local (desktop/Webtop). Su idea es que ninguno de los dos es suficiente:

But as this drive toward hybrid desktop/webtop software illustrates, there are limits to both approaches, and the future for software may be a blend of the best features of both.
(...) The most likely outcome is a hybrid future where desktop and web-based software and services become intertwined to the point where users won't know the difference between the two, suggest experts at Wharton and elsewhere. "We believe that the future of technology at work will be a combination of local software on PCs, along with services," said Jeff Raikes, president of Microsoft's Business Division, in a question and answer session at the announcement of Office Live Workspace on September 30. "Think of it as a continuum, ranging from pure software to pure services approaches. Most customers will be somewhere in the middle."

Los profesores Eric Clemons y Kartik Hosanagar, apunta a los aspectos más diferenciadores de esta tendencia:

(...) this model is likely to develop in two phases. "In the first phase, applications will provide essentially the same features as a desktop application, only you will now be able to access them from anywhere. Current web-based apps are good examples of this." For example, Yahoo Mail looks a lot like Microsoft's Outlook email program. Google Docs and Adobe's Buzzword mimic Microsoft Word and add perks like the ability to access your documents from any computer.
In this phase, occurring today, Hosanagar says desktop applications will offer more features than web-based software, but over time that advantage will erode.
In the second phase of this hybrid model, web applications and desktop software will co-mingle, says Hosanagar. "What's likely to be more exciting is the next phase, where these web-based applications can interact and share data with each other and become platforms [that developers can use to build more software]. Facebook has already become one such platform, as has Salesforce.com on the enterprise side. In the next phase, far more interesting things will happen as these web apps start talking to each other."
Clemons notes that another critical factor for the evolution of software will be mobile applications. "My bet is that desktop software will be used for home operations, and webtop software will be used for mobile applications," says Clemons. The key will be synchronizing desktop and web software wherever a person goes. "None of us has a good idea what these mobile applications will be, but they may provide real value."

Krishnan Anand agrega otro elemento, "pay-per-use":

Anand says another model that's likely to emerge is one that is based on usage. In this model, a person who used a program infrequently could employ the web-based version for free or a small fee. Heavy users would pay more based on usage. In this model, which would apply to both web-based and desktop software, Anand likens software providers to electric utilities. "The notion is you can charge different prices based on levels of usage," he says.

Sin embargo, la confiabilidad sigue siendo débil:

"Reliability is critical for many of us. Even now, networks crash and I can't access files. I still have to make sure I have a copy on desktop. Until that changes, I don't see an advantage to web-based applications."

Tercera reunión anual mundial de usuarios de CA Plex/2E

En septiembre se realizó la tercera reunión anual mundial de usuarios de CA Plex/2E, es decir, la tercera de CA destinada a estos productos. Existieron otras, pero bajo la promoción de Sterling y Synon, anteriores dueños de los productos.
En la Wiki de Plex están disponibles las presentaciones, de interés para quienes trabajan con los productos, tanto como para quien quiera conocer cómo funcionan, y qué alcance tienen. Es destacable el material de Austin ADC y Websydian, en el terreno de desarrollo orientado a Web, y el soporte de arquitecturas orientadas a servicio (SOA).

Reunión de usuarios de Plex en Madrid

Este 17 de mayo Dominion convocó una reunión para presentar la versión 6.0 de Plex. La reunión sirvió también para convocar un encuentro de usuarios, junto a representantes de CA (Paulo Colaço Dias) y de Websydian (Mikkel Schnack y Søren Madsen), y discutir aspectos de la evolución futura de Plex y 2E.
En el sitio se pueden descargar cuatro presentaciones; dos específicas sobre técnicas de aplicación de 2E, y dos sobre Plex y Websydian, respectivamente. Los cuatro aspectos más destacables de la presentación de Plex: el soporte del generador para C# y la arquitectura .NET, el soporte de ANT, el soporte de SOA, y el respaldo a Websydian. La reunión forma parte del cronograma europeo. El programa, y otras presentaciones, pueden consultarse en la Wiki de Plex.

MDA y Open Source

FTP On Line publica una nota introductoria sobre MDA (Model Driven Development para quienes lean aquí por primera vez) con la particularidad de que discute la idea de aplicar MDA a las arquitecturas orientadas a servicio (SOA). Dado la arquitectura de cualquier generador basado en MDA, no cabe duda de que esto es posible. Así presenta el tema Steve Andrews, autor de la nota:

Despite the advances in SOA technologies and techniques, a composite application is only as good as its underlying individual application services. In this article you'll explore how raising the level of abstraction and using model-driven techniques can address the most common issues associated with building applications.

Luego de destacar los principales elementos de un modelo desarrollado bajo MDA (un modelo conceptual (CIM), un modelo independiente de la plataforma (PIM), un modelo asociado a cada plataforma de implementación (PSM), un modelo de transformación (TM), Andrews apunta a SOA:

Model-driven development (MDD) enables a more rapid, complete and direct path from a business problem to an executable business solution. MDD transforms the business knowledge in a PIM into a PSM based on knowledge about a technical platform, and then transforms the PSM into a PSI that can be deployed to a run-time environment. The fidelity of the transformation model determines how rapidly and completely this process can be completed. A PSI can be developed manually based on a PIM and PSM, but it will take longer and may introduce human error (see Figure 1).
You can employ several MDD strategies. For example, architected model-driven development (AMDD) combines application frameworks (which handle common application infrastructure concerns) with MDD generative techniques. AMDD further decreases the amount of manual development that must be done by raising the level of technical abstraction. Ultimately, all MDD variants are focused on delivering business results without letting the technology get in the way.
MDD is not a silver bullet that obviates the need for solid software engineering fundamentals. Good requirements that unambiguously define the problem are still important, as their fidelity in the CIM determines the potential fidelity of the PIM. Luckily, since MDD compresses the actual coding time, it frees up more time to devote to understanding user needs.
Over time, as transformation- and platform-specific models evolve, the need for higher-priced development resources will decline. Since the application architecture is "baked into" the generated PSM, you can focus on writing business logic almost exclusively. For example, if part of the application architecture exposes behavior using Web services, you can encapsulate the rules for generating Web service interfaces in the transformation model one time and apply it many times. Your alternative is manually re-implementing the Web service technical details for each service, which takes away from time spent focusing on the services' business logic.

Pero lo más interesante del caso, es que Andrews es autor de un proyecto MDA de código abierto: Atlas. Existen actualmente muchos desarrollos de código abierto que representan una oportunidad única para elevar el nivel de productividad de un equipo, y aprender un enfoque superior de desarrollo de software. Muchos pueden encontrarse en Code Generation.

Enfoque interdisciplinario: OOD y SOA integrados

Un bien desarrollado artículo sobre arquitecturas orientadas a servicio, va contra la difundida idea de que la orientación a objetos no es adecuada en el marco de SOA.

While the SOA approach strongly reinforces well-established, general software architecture principles such as information hiding, modularization, and separation of concerns, it also adds additional themes such as service choreography, service repositories, and the service bus middleware pattern.
A structured approach or analysis and design method is required to craft SOAs of quality. As none of the existing approaches met the authors requirements on recent SOA projects, they suggest combining elements from well-established practices such as OOAD, EA, and BPM, complementing them with innovative elements upon demand.

Qué implica SOA (orientación a servicios) desde el punto de vista del diseño:

In anticipation of the discovery of new business opportunities or threats, the SOA architectural style aims to provide enterprise business solutions that can extend or change on demand. SOA solutions are composed of reusable services, with well-defined, published and standards-compliant interfaces. SOA provides a mechanism for integrating existing legacy applications regardless of their platform or language.
Conceptually, there are three major levels of abstraction within SOA:

• Operations: Transactions that represent single logical units of work (LUWs). Execution of an operation will typically cause one or more persistent data records to be read, written, or modified. SOA operations are directly comparable to object-oriented (OO) methods. They have a specific, structured interface, and return structured responses. Just as for methods, the execution of a specific operation might involve invocation of additional operations.
• Services: Represent logical groupings of operations. For example, if we view CustomerProfiling as a service, then, Lookup customer by telephone number, List customers by name and postal code, and Save data for new customer represent the associated operations.
• Business Processes: A long running set of actions or activities performed with specific business goals in mind. Business processes typically encompass multiple service invocations. Examples of business processes are: Initiate New Employee, Sell Products or Services, and Fulfill Order.

  In SOA terms, a business process consists of a series of operations which are executed in an ordered sequence according to a set of business rules. The sequencing, selection, and execution of operations is termed service or process choreography. Typically, choreographed services are invoked in order to respond to business events.

From a modeling standpoint, the resulting challenge is how well-designed operation, service, and process abstractions can be characterized and constructed systematically. The related issues currently are among the most frequently discussed ones in industry and academia. We are not aware of any recent SOA project or workshop in which such service modeling aspects have not been a major topic, giving fuel for numerous debates. So let us take a closer look.

Problemas de diseño orientado a objetos para la orientación a servicios:

The main issue with current OO design practices in relation to SO is that its level of granularity is focused at the class level, which resides at too low of a level of abstraction for business service modeling. Strong associations such as inheritance, create a rather tight coupling (and, consequently, a dependency) between the involved parties. In contrast, the SO paradigm attempts to promote flexibility and agility through loose coupling. There, currently, is no cross-platform inheritance support and first-class notion of a service instance in SOA in order to avoid having to deal with service lifecycle housekeeping issues such as remote garbage collection.
These considerations make OO difficult to align with the SO architectural style straightaway. However, OO still is a valuable approach for design of the underlying class and component structure within a defined service. Furthermore, many OOAD techniques such as classes, responsibilities, and collaborations (CRC) cards can be leveraged for service modeling, if elevated up to a higher level of abstraction.

La solución propuesta es un híbrido, Service-Oriented Analysis and Design (SOAD):

The basic concepts of Service-Oriented Architectures (SOAs) and Web services are becoming part of our everyday language and recognized as a suitable architectural style for crafting modern enterprise applications. In this context, the underlying issues of: what makes good services are becoming increasingly critical for ensuring the successful implementation of SOAs.
Existing modeling disciplines such as Object-Oriented Analysis and Design (OOAD), Enterprise Architecture (EA) frameworks, and Business Process Modeling (BPM) provide us with high-quality practices that can go a long way in assisting with the identification and definition of appropriate abstractions within an architecture. However, experience shows that these practices fall short when being applied independent of each other.
In this article, we will investigate suitable elements from OOAD, EA, and BPM. We will also motivate the need for a hybrid approach that combines elements of all of the disciplines, with a number of distinct, new elements. The resulting, interdisciplinary OOAD method facilitating successful SOA deployments, which we refer to as Service-Oriented Analysis and Design (SOAD), has yet to be formally defined. We merely take first steps into the SOAD space.

(...) The SOA vision is accepted rather easily, as its technical foundation is well-known. For example, applying general software architecture principles and OO techniques is a valid start in any SOA effort. However, as already stated, the question most frequently asked by early adopters is how to identify the right services. As stated earlier, OOAD, EA, and BPM cannot supply a satisfying answer when applied in isolation from each other, as we will explain now.
The OOAD methodology introduced in the seminal books from Booch and Jacobson (issued about a decade ago), provides an excellent starting point in defining SOAs. As such, OOAD is concerned with micro-level abstractions such as classes and individual object instances, although applying OOAD techniques and the Unified Modeling Language (UML) notation on the architectural level has been common practice for many years. As a standalone use case model is frequently created per problem domain, and consequently, application development project, the enterprise-wide big picture gets blurred in many cases. Furthermore, for various reasons the use case models are not always synchronized with their BPM counterparts.
EA approaches, such as Feature-Oriented Domain Analysis (FODA), and Zachman add a city-planning level viewpoint on top of solution architectures, but do not address how enterprise-wide abstractions of quality facilitating reuse and longevity can be found.
While BPM approaches such as BPMI do provide an end-to-end view on functional units of work, they typically do not reach into the architecture and implementation domain. For example, until the arrival of languages such as the Business Process Execution Language for Web Services (BPEL), BPM notations were missing operational semantics. Moreover, we have seen many cases in which the process modeling and the development initiatives were separated from each other.
Finally, none of the existing disciplines address how existing applications can be enabled for SOA; a top-down process is employed most of the time. Existing systems typically hold large amounts of critical data and business logic, and cannot simply be replaced. Hence, a bottom-up analysis of these systems also has to be conducted in order to investigate wrapping and refactoring strategies. Taking existing applications into account, therefore, leads to a meet-in-the-middle process.
A hybrid SOAD modeling approach is required for these reasons. The approach comprises elements from OOAD, BPM, and EA in a best-of-breed fashion, and complements them with certain innovative elements.

Este resumen es sólo introductorio, con el propósito de destacar aspectos de la arquitectura, y las exigencias que deben resolverse al pensar el diseño. El artículo es insustituíble, tanto en sí, como por su bibliografía.

MDA y SOA en una discusión

Hace tiempo que tengo pendiente mencionar una línea de discusión abierta en el grupo Service-Orientated-Architecture de Yahoo en Agosto del año pasado, sobre las relaciones y oposiciones entre la arquitectura orientada a servicios y el diseño orientado a objetos. Participan en el debate varios conocedores del problema (Gervas Douglas, Eric Newcomer, Stefan Tilkov), que permiten tener una visión detallada del alcance de la arquitectura, y cómo el diseño orientado a objetos encaja en SOA, disparada por un comentario del moderador del grupo, Gervas Douglas:

Model-driven and event-driven architectures are two technologies expected to have a big impact on developers over the next decade. And while many IT professionals are in the dark about much of Gartner's "Hype Cycle for Emerging Technologies," these architectures, along with AJAX apps, have very bright futures.
(...) Event-driven architecture (EDA) is a common style for distributed apps that are typically designed into modular, encapsulated, shareable components with event services. The services can be created through an app, an adapter or agent acting non-invasively. According to the report, those in the financial trading, energy trading, telecommunications and fraud detection industries have begun using EDA technology, along with the Department of Homeland Security. But Gartner says EDA is at least five years from mainstream maturity.
(...) As for Model-driven architecture (MDA), a technology from the Object Management Group, the process will turn the heads of developers simply for its increased flexibility through SOA. The technology distinguishes biz-level functionality from the technical complexity of its implementation, enabling the apps to be modeled by standards like Unified Modeling Language. This allows the models to operate free from potential platform limitations and instantiate them into specific runtime implementations using a target platform of choice. Fenn says
both MDAs and EDAs will find their niche with developers largely thanks to SOA and their bottom-line boosting perks.

...Y aquí comienza todo. Eric Newcomer desaconseja UML como elemento de diseño de servicios, y Tilkov y Steve Jones, le replican.

Newcomer:

I just want to point out that MDA is not a good fit for SOA since it's based on UML, which is object-oriented, not service oriented.

UML has some value for whiteboarding and design, but in general OO analysis and design is overly complex for SO.
(...en otro párrafo...) UML is a great whiteboarding language but not more. Its contribution to the industry is a consolidation of what previously were multiple varying design notations. UML is not, and never was, an executable language, and attempts to make it so are inevitable failures.

Jones:

I wouldn't be so quick to rule out MDA for SOA, we've had some great success with using MDA as an implementation approach for SOA. We model the services in our architecture approach and then massively speed up the delivery of them by using MDA. I don't think Gartner are suggesting that MDA is for the whole of an SOA, they talk about it being for a niche. If you view SOA as being architectural and MDA/EDA/SOAP/REST as being software implementation/architecture then MDA is a real contender in terms of productivity gains and quality control.
One word of warning though, MDA does require high quality people who can deal at the abstract level and still create a system that works operationally.

Tilkov:

First of all, MDA is not necessarily based on UML, it can also be used with MOF. For example, Eclipse's EMF, which contains an implementation of EMOF, can be used to build domain specific modeling languages that are not object oriented. These can then become part of an automated tool chain that would clearly qualify as "MDA compliant" (although there is no such thing).
Secondly, it's perfectly possible to use UML to model services. You model classes, including attributes and associations, and specify them as types for the single parameter in service classes' method signatures. What's not service-oriented about this?
Thirdly, what's the (simpler) modeling alternative you suggest?
MDA, or in fact any form of model-driven software development, has many pros and cons. There's also a lot to be said against UML (e.g. its complexity and number of features which are largely unused in practice); its OO features are, IMO, definitely not a problem for applying it to SOA, though.

La respuesta de Newcomer pone sobre la mesa la validez en este contexto, del diseño orientado a objetos:

Certainly you can use UML to create services - as has been mentioned many times in this forum you can really use any technology, including procedure oriented technologies such as COBOL or PL/I.

I agree EMF is simpler and it is easier with EMF to create a modeling language for services, and we are currently currently working along those lines at the Eclipse STP Project. Microsoft has recently also released a Web service software factory, which also looks on first glance to be more service oriented.

But the point is more about what's better suited to service orientation, and because UML is object oriented it forces the same kind of mental translation as you'd have to do in going from procedure orientation to object orientation or service orientation. Why not work with tools more suited to the SO concept?

Objects are really overkill for software design. I believe it's time to basically turn back the clock and reject objects as the conceptual basis of modeling software. OO creates more problems than it solves. (Implementing services using objects, procedures, queues, etc. is ok but let's not design them that way.) It is much better to model, design, and develop using services natively. Most software applications are designed around implmenting functions rather than things.

Tilkov defiende su concepción:

I honestly don't see this point. In OO modeling with UML, an interface containing methods (or operations, if you prefer) is a first class concept. As is something that implements this interface. Sounds very service-oriented to me.
You can use a UML class model to describe a graph of data objects, or entities, or whatever you prefer to call them. There's not a 1:1 mapping to XML, but many (excluding me) agree this is not a SOA requirement.
(...) If you argued that it's better to develop Web services are better developed starting with explicit XML document design, I would probably agree - but describing SOA as an abstract, architectural concept, and then rejecting a general,
abstract modeling language such as UML, seems contradictory.
What methodology (and *available* tooling) would you recommend to
someone who wants to model services now?

Jerry Zhu amplía la defensa de OOD:

The way I look at the SW technology evolution is that three layers from bottom up OO objects, Component Orieation objects (EJBs and COM) and Service Orienation objects (such as Web services).
You need OO concepts to build EJBs or COM objects that support a critical concept called Automation which support programmability. Service technoloygy is build on the Automation by replacing scripts with XML messages. By having a service layer on top, we can build new applications quickly by recomposing services through creating new XML documents that in turn reassemble EJB objects.
Without Service layer, when building new applications, we have to program using APIs that means learning curve and development experience. With Service layer
we only compose XML documents and the computer will do the API wiring for us therefore significant resource saving. This is only possible when we have complete
business/technical coverage by all the OO and CO objects.
Some may have two layers: procedural languages and Services. It is a short cut. It may work for building a Scooter but not a Jetfighter.
Accordingly I would say Service technology is a newer technology than Component technology (EJB/COM). It is not that Service technology has been around long time.
The appearance of Service technology is years after the appearance of EJB and COM.

Anne Thomas Manes puntualiza un aspecto limitante de SOA:

When building service-oriented systems, you don't want to make everything a service. Only those bits that are reusable should be exposed as services. Unfortunately, most of the current tooling out there tends to simply convert object interfaces into service interfaces.

Ashley McNeile agrega otro enfoque:

I don't know whether the work I have been doing is of interest in this context, but it may be. So here is a short description and references to some material.
I have had a long standing interest in behaviour modelling, and languages that support direct execution of such models. Recently I have been working with colleagues on a concept called "Protocol Modelling" that is based around the idea of composing partial behavioural descriptions using the parallel composition ideas of CSP (Tony Hoare's process algebra).
This approach leads to a programming style in which partial behavioural descriptions (which can, in theory, be built using any notation you like) are combined in the manner of "mixins", giving an expressive power that is similar to multiple inheritance.
The challenge in developing the approach has been to allow these mixins to be re-used safely across the definition of multiple behavioural entities (be they objects or processes -- we don't really distinguish between the two). The approach works well, but does lead to a radically different view of what is meant by "inheritance" and the mechanisms for achieving it. However, I think we are on the right track, as attempts to include the inheritance of behaviour into conventional inheritance schemes leads to nasty complications.
The resultant paradigm for defining executable behaviour models is as different from conventional OO as OO is different from 3GL.
The following two papers will give you some idea of what we have been doing. Both are referenced from the "News and White Papers" page of the Metamaxim website (http://www.metamaxim.com/pages/news.htm):
1. The paper "State Machines as Mixins" (see "Metamaxim article in The Journal of Object Technology" under January 2004)
2. The paper "Protocol Modelling" (see "Formal Semantics" under November 2004).
The first of these is a more general motivation of the ideas -- please read this one first. The second is an attempt to put the ideas on a more formal footing.
It is too early to say whether this approach has useful application to SO (in particular, process modelling), but I suspect that it does.

Invito a leer y analizar la discusión, que es una fuente de ideas sobre los alcances de las arquitecturas orientadas a servicios, y también sobre las fuerzas y debilidades de la orientación a objetos.

SOA: interesante análisis de sus puntos flojos en Wikipedia

En la entrada de SOA (Services Oriented Architecure) de la Wikipedia en inglés, entre otros materiales de real interés, se destaca su puntualización de aspectos problemáticos de la arquitectura (o estilo):

One of the criticisms of SOA is that the addition of XML layers introduces XML parsing and composition. In the absence of native or binary forms of Remote Procedure Calls (RPCs) applications may run slower and require more processing power, which increases costs.

Another criticism of SOA is that the services are just stateless. According to www.xml.com, Stateful service is difficult to avoid in a number of situations. One situation is to establish a session between a consumer and a provider. A session is typically established for efficiency reasons. For example, sending a security certificate with each request is a serious burden for both any consumer and provider. It is much quicker to replace the certificate with a token shared just between the consumer and provider. Another situation is to provide customized service.

Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. The drawback of this constraint is that it may reduce the overall scalability of the service provider because it may need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.

Another concern is that WS* standards and products are still evolving (e.g., transaction, security), and SOA can thus introduce risk unless properly managed and estimated with additional budget and contingency for additional Proof of Concept work.

An informal survey by Network Computing placed SOA as the most despised buzzword (November 2006).

Some critics feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc).

Lamentablemente, la Wikipedia no publica los nombres de los colaboradores que intervienen en cada artículo. En este caso, hubiera sido conveniente.

Breve introducción a las arquitecturas

Dejando de lado las referencias más específicas a Websphere, un artículo de Bobby Wolf en el sitio de IBM dedicado a desarrolladores ofrece una introducción al alcance de las arquitecturas de software. Cuatro aspectos de interés:

• La descripción de las organizaciones con una arquitectura no planificada, espontánea o no-arquitectura.
• La breve historia de las arquitecturas en general adoptadas
• La definición de un arquitecto de IT
• ...y la introducción a las arquitecturas orientadas a servicio (SOA)

En principio, una definición:

The architecture of a system is the highest level of shared understanding of that system by the experts who create it. It is the main parts of the system that need to be understood so that the system, the main components, and how they relate and interact can be understood. An architecture is whatever the expert designers find important at the top level; the architecture drills down into important details while less important ones are determined at lower levels of design. (...)
If the entire system is considered the topmost level of interest, that's the enterprise architecture. If you're focusing on the hardware and low-level software the system runs on, you're concerned about the infrastructure architecture. Even that may be high level for someone focused on the network architecture, in which the network is considered the highest level of interest. Others focus exclusively on the storage architecture. Operations architecture involves keeping the production system running smoothly even during challenges like load spikes and outages.

Una arquitectura no planeada, cae en alguna de estas categorías, según Wolf:

There are three general types of these non-architected architectures, each with its own derogatory yet memorable name:

Big ball of mud (a.k.a. Shantytown) -- This kind of system contains large segments that are unused. Yet the unused parts are so enmeshed with everything else that they're impossible to identify, much less remove.

Spaghetti -- This is a system with no logical flow, where any part may be connected to any other part. In such a case, most of the parts share some dependency on many or most of the other parts, even if such dependencies make little difference to the overall functionality of the system.

House of cards -- With this non-architecture, every part depends on many others, so that a change to one part breaks several, and fixing one problem introduces many more.

Many systems with the properties of one type tend to have the properties of the other two types as well. The figure below shows an example architecture that has characteristics of all three types.

Sobre la historia de las arquitecturas:

The following are major milestones in IT architecture, listed in roughly chronological order:

• Mainframes. The first applications ran on one central computer. Users connected through dumb terminals or teletype machines. Architecture was simple: The application did everything beyond the operating system. For persistence, there was no external database like IBM DB2® or Oracle--the application stored its data in files itself. There were no messaging systems, no GUIs, no shared data, and no interaction between applications.
• Workstations. As desktop computers became common, so did applications that ran on them. These are personal productivity applications like VisiCalc, WordPerfect (now published by Corel Corporation), and the Microsoft® Office applications. These were personal applications; each user ran a locally installed copy and quit it after its use. No data was shared; it was stored in files on local disk and only distributed by sneaker-net.
• Networking. Networks connected workstations to each other, to shared server computers, and to mainframe-style central processing computers. This enabled e-mail capability within an enterprise and sharing files on a file server.
• Client/server. Networking enabled client/server computing, where the application no longer ran completely on a central computer or on a workstation, but was split across the two. Original client/server applications ran on the workstation but accessed centralized data from a database server. Later architectures split the application itself into two parts: a shared component for business logic that ran on the server and local clients that implemented the user interface. The need to host this central business logic led to the development of application servers for running and managing the server part of the application.
• N-tier. A client/server architecture is said to be a two-tier architecture. When the database server runs on a different host computer from the application server, that's a three-tier architecture. As network-based applications became more sophisticated, designers divided the application stack--from the GUI to the database--into more processes on both the client and the server. Such a multiple-tier design became generically known as an n-tier architecture.
• Internet. The Internet is networking on steroids, a global network. The Internet is actually older than the networks in most enterprises, but it was impractical to access it in the business world until an enterprise constructed an internal network that could connect to the Internet. The Internet enabled communications and information sharing not just between users in an enterprise, but between users anywhere in the world.
• World Wide Web. The Web made the Internet graphical. It enabled authors to publish words and pictures--using Hypertext Markup Language (HTML)--as a combined document that could be viewed by anyone anywhere in the world. These HTML documents contained hyperlinks to other documents, so any reference to another document became active and provided the reader direct access to the referenced source. This was the beginning of information on demand, to links being as important as nodes.
• Browser GUIs. The Web introduced HTML browsers for viewing static HTML documents. This paradigm was quickly adapted to provide interactive GUIs for accessing remote applications. This was a return to the centralized computing model. It wasn't actually a client/server model, because practically none of the application ran on the client except for HTML rendering and some simple scripting. Even the validation of input values had to be performed on the server.
• Web services. The Internet was created to connect applications, but the Web connected people to static content and to server applications. Web services use the Web to connect applications so that one application can invoke behavior in another application through a Web connection.
• Web 2.0. This is the application of Web services to Web sites. The user of a Web site is no longer a person, it's another application.
• Service-Oriented Architecture (SOA). Applications have tended to be monolithic, running entirely either on a central computer or on a workstation. Client/server and n-tier architectures distributed application layers; browser GUIs moved the application back to the server. Even with n-tier architectures, this architecture was still rather monolithic because the run-time stack is self-contained; applications at best interacted as peers. SOA divides an application into a service coordinator (the top set of consumers in a composite application) that represents user functionality and service providers that implement the functionality. While the coordinator tends to be unique to a particular application, a service can be reused and shared by multiple composite applications.
• Event-driven architecture. With SOA, the service coordinator explicitly specifies and invokes the desired services. With event-driven architecture (EDA), an application detects an event and emits a notification; other applications have handlers that can receive the notifications and react by invoking services. In this way, the detection application doesn't have to know all the services it should invoke in response to an event; it can simply announce the event and let the other applications decide which services to invoke in response.

La definición de IBM sobre quién es un arquitecto (seis disciplinas):

1. Enterprise architecture. An enterprise architect focuses on mapping IT capabilities to business needs. The architect is responsible for an enterprise's full range of software-intensive systems, including the relationship between multiple applications, data shared between applications, integration of the applications, and the infrastructure to run applications.
2. Application architecture. An application architect focuses on the design of applications to automate business processes and provide functionality that helps users perform business tasks. The architect's responsibilities include designing the application to meet user functional and quality of service requirements including performance, availability, scalability, security, and integrity. Responsibilities also include evaluating and selecting the software and hardware necessary to run the application, as well as the tools and methodologies to develop the application.
3. Information architecture. An information architect focuses on the data used by multiple applications, including the structure, integrity, security, and accessibility of that data. The architect's responsibilities include designing, building, testing, installing, operating, and maintaining the systems for managing that data. Design of these systems must account for data requirements such as source, location, integrity, availability, performance, and age.
4. Infrastructure architecture. An infrastructure architect focuses on the design of hardware and server software including server computers, storage, workstations, middleware, non-application software, networks, and the physical facilities that support the applications and business processes required by the enterprise. The architect's responsibilities include evaluation and selection of these components; modeling, simulating, and testing to validate the designs and selected products; and performance, availability and scalability of the resulting infrastructure.
5. Integration architecture. An integration architect focuses on the design of solutions that enable existing applications, packaged software offerings, networks, and systems to work together within an enterprise or among enterprises. These solutions may use different technologies, vendors, platforms, and styles of computing.
6. Operations architecture. An operations architect focuses on the design of solutions to manage the infrastructure and applications used by the enterprise. The architect's responsibilities include defining plans, strategies, and architectures for the installation, operation, migration, and management of complex information systems.

These architects do not work independently because their domains overlap. The infrastructure architect designs the foundation the systems run on. The application architect designs the programs for users, the integration architect makes sure the programs can be integrated, and the information architect makes sure they have data. The operations architect makes sure it all runs properly, and the enterprise architect oversees all of these aspects and ensures that they all come together.

SOA es desarrollada por separado, en un área completa