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.