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