Software Architecture: Past, Present and Future

http://blogs.msdn.com/b/diegumzone/archive/2006/11/10/software-architecture-past-present-and-future.aspx

Software Architecture: Past, Present and Future

Diego Dagum - MSFT

9 Nov 2006 11:32 PM

• 2

 What  is exactly software architecture? Do we really need it? Why have we only recently been discussing it? Is there suddenly a contagious fever about software architecture infecting those who claim to be architects? Who are they actually: gurus, just senior developers, or maybe smooth-talkers?

These are questions that developers, junior and senior, are asking about software architecture and software architects. In this article we, the members of the MS Architecture Strategy Team, will answer all of them and even more: we will face the forbidden question "Can a developer become software architect?"

 

 

 

The Need for Software Architecture

A longtime ago, programming platforms were more self-sufficient than nowadays. From robust and complex environments like mainframe COBOL to light and easy to understand xBase languages, the most important technical decisions were already taken. In terms of software projects, that implied both benefits and deficits. 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 solutions model was adequate and successful for a long time. But it was a deficit as well, because at the largest companies, 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 self-sufficient platforms to play togetether.

Thus, component-oriented software was born with the goal of a new agility in scaling applications. This style of applications enabled us to choose among a broad set of platforms, to produce modular pieces (or components) ready to be used by other components made by us or bought from third parties. Once we could prove that integration was not an issue, this feature gained popularity in the enterprise, where the technical decision makers discovered the advantage of using the right platform and tools as solutions for specific problems. However, eventually the need to plan and manage components became evident to guarantee the 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 to learn for many developers. Thus, one of the first objectives of a good architecture was  to gently hide  the complexity of new platforms and APIs behind simpler ones, more focused in the context of the problem being solved (typically a business problem), and, most of all, easily understandable by regular programmers.

That way software architecture became a highway to develop business solutions in a timely, secure, accurate manner. Under the pavement of that highway is nothing but technological decisions, the critical ones. Decisions the architect had to take to make the developers' tasks easier.

The difference with past platforms is that now, rather than buying general purpose software from a vendor, an organization's members make the decisions regarding the function of the business solution to be developed.

 

 

What Software Architecture Used To Be

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

·         Design Patterns. The legend started with a book called simply  "Design Patterns" (http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612) 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 the problem at a small scale, but surely this book sowed the seed 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," at http://www.skyscrapr.net/blogs/solution/archive/2006/07/30/248.aspx


Figure 1. The Strategy Pattern, as explained in MSDN Magazine (July, 2005)

·         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, granted the responsibility of user interaction handling to a component which played a role known "the View." "The Model" component had the responsibility of consistently keeping the business model state. A third component, called "the Controller" interpreted events originated from the View, promoting changes in the Model state accordingly. This pattern permitted very inexpensively interchanging components of any role, 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 isn't just a discussion about Oracle versus SQL Server versus IBM DB/2 versus MySql vesus whichever. Think also of legacy mainframe environments or 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. An interesting reference of this pattern is available at http://www.skyscrapr.net/blogs/solution/archive/2006/08/07/262.aspx. But MVC was just the beginning, because since the middle of nineties a series of books appeared to classify and organize many other architecture patterns. We must merely mention and recommend the POSA books (Patterns of Software Architecture), 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.) For more information visit http://msdn.microsoft.com/practices/


Figure 2. The MVC Pattern, as explained in MS Patterns & Practices' book "Enterprise Solution Patterns"

·         Anti-patterns. A counter-concept grew in parallel with the concept of patterns. If a pattern is seen as 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 architect all and every software component. This is commonly specially seen in the need of adopting immediately the new version of everything without actually considering if its benefits are helpful. Perhaps 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. For a discussion about this, we suggest this article http://www.skyscrapr.net/blogs/solution/archive/2006/08/28/282.aspx.

·         Frameworks. In a remarkable effort of enabling large scale 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 don't 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

The considerations of economical changes like globalization and technological achievements like the Internet's impact 0n 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) to provide for business applications' high availability. 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 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 also known as Application Architect). Examples of such applications are: Internet banking, companywide knowledge sharing portal, and distributed point of sales 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 be a bridge between business leaders, development, and operations to ensure that mutual understanding is achieved, goals are realistic, and expectations are properly managed. 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 as Strategic Architect. What is expected is that a Solutions Architect or Infrastructure Architect becomes Enterprise Architect.

 

 

What Software Architecture worry about nowadays

Recent years have been really challenging for software architecture. An elemental concept like service-oriented components (and its, as time goes by, more winner implementation: the 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.


Figure 3. A Service-Oriented Architecture as told in the MS Architecture Journal (January, 2004)

Former silos like company CRM, ERP, and every line of business (LOB) application, are expected to enable their functions to the others for synergy and mutual profit. The SOA challenge is scattered in five major problems to address:

·         Federated Identity and Access: How to manage the authentication and authorization systems in a centralized way, available for every application? Once the user logs in, how to propagate his identity to every service? How to treat external customers with respect to internal users? As just another role or maybe a completely different policy should be considered?

·         Federated Data. How to keep the distributed repositories synchronized? How to gently gather enterprise entities by data aggregation? Which levels of redundancy are reasonable? How to 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 a 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 better discussed at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnbda/html/SOADesign.asp.

·         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 about these capabilities: http://msdn.microsoft.com/architecture/solutions_architecture/default.aspx.

 

 

Where Software Architecture Goes from Here

While now concepts like patterns and SOA became or are becoming mainstream, software architecture continues evolving and expanding to new spaces. Because of space, we cannot discuss some other software architecture trends which build on SOA, like model-driven architecture (MDA) or software factories, but you can find more information at http://msdn.microsoft.com/architecture/factories/default.aspx.

However,  there are two particular topics, not yet massively embraced, but watched very closely by the industry. (Usually, the industry is interpreted as the most important companies, IT analysts, and global system integrators.) They are:

·         Software as a Service (SaaS). A new software delivery model, where companies don't really hold their line-of-business (LOB) software bits, but only its right of use. That way, 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 to combine an SaaS application, for instance, in the company's SOA? How to 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 modification. Perhaps even more pertinent, how to scale the environment for a growing number of tenants? The MSDN Architecture Center granted this topic its own space: http://msdn.microsoft.com/architecture/saas/default.aspx.

·         Web 2.0. Another area of architecture research is how to get the most of the writable Web, Web based on participation. We talk about the 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 to offer "the long tail" of those goods and services, each of which individually may not be the most wanted (possibly the least), but surely all of them together are becoming important in terms of revenue.

 

 

Conclusion

Some pundits wonder if being an architect is a condition they are born with or if it's something acquirable with discipline and practice. In Microsoft, at the Architecture Strategy Team (AST) we are convinced that being an architect is a condition you can gain. SkyScrapr, http://www.skyscrapr.net/, is a community space for aspiring architects to share ideas, common knowledge, experiences, and - most of all - to discuss architectural issues.

Here we have reviewed how software architecture evolved from what software engineering was realizing about its existence.

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 real scientific discipline. Microsoft is contributing with the generation of a common space, an architecture collective community to make this real.