Life is not easy for today's enterprise application architects. In today's IT world, the architect not only has to design solutions for a plethora of interdependent systems (as is obvious from the job description and title), he or she also has to conform to the ever-evolving standards in a shorter API life cycle, plan for the not-too-distant future, collaborate with business and technical environments, and work on a feasible roadmap for his or her application/application portfolio.

In large organizations, standards for various facets of business and technology are already laid out and managed between several competency centers/centers of excellence, and strict governance is often in place to ensure consistency throughout the organization. To successfully deliver products against hard deadlines, the architects have to make sure that everything complies in the governance process.

With the advances in software engineering, especially in component-based and service-oriented architectures, common guidelines have emerged in the form of design patterns. These design patterns help architects leverage what others have learned in their software design journey. The Java platform is an obvious example of the application of design patterns. Before distributed platforms such as Java came along, the number of folks who could spell "design pattern" was limited to the few who had read the Gang-of-Four book, and that was just a handful of developers in any organization. With Java - Listeners, Proxies, Observers, Factories, Delegates, Facades - all these became a part of the designers' common vocabulary. Reference architectures, frameworks, and plug-and-play followed soon after. Although Java is not solely responsible for this, it has definitely played a big part in the promotion of these concepts. Add UML and RUP to the mix and you not only have the toolkit, but also the ability to document and manage your application's development in a common way.

With all these wonderful tools in the architect's toolkit, why is the job still so complex? Given the tools at hand, an application architect should easily be able to develop applications that leverage:

• Application frameworks
• Architecture blueprints
• Adaptive architectures
• Reference architectures
• Prescriptive architectures

The basic problem is that the guidelines and patterns, though invaluable, are created outside the application domain. Although they do address the needs of applications, that need is addressed across a number of applications. After all, it's the only way that reuse can be promoted. In this editorial we are focusing on the application architect. The architects in competency centers and standards groups focus on promoting reuse. The focus of the application architect is on leveraging reusable components and leveraging documented patterns to solve a business problem. However, unless a clear path is laid out for navigating through the available choices, he or she may easily choose to develop alternatives in order to meet the demands of the application.

This impasse between the prescription of reuse and its feasibility in the application's context needs to be carefully addressed. Just as the design principles that apply to a broad range of applications are made available for the applications, a guidebook that navigates through these principles should be developed for the application/application portfolio. This guidebook should focus on application design, treating the application as the center of the universe. Then clear governance practices should be established around exporting the reusable artifacts, learnings, and application patterns that emerge out of each application design cycle. These should then be incorporated into the rationale for selecting design patterns published by groups external to the application. After all, communication is a two-way street. Design patterns are no exception.