Recently I was involved in an architectural assessment at a financial services company. Part of the assessment involved interviews with management, business, and technical staff. While digging into the details of a major application, I asked the technical lead to describe the logical structure of the application. I was somewhat surprised that nobody on the team was able to do this, even though they had spent the last year implementing it. They were able to describe the physical structure of the application (servers, protocols, technology), but could not describe the logical functions that were performed by each of these parts. Unfortunately, this is all too common.
Application architecture seems to be one of the most misunderstood aspects of architecture, often confused or overlapped with the technical architecture. When we talk about enterprise architecture, we often talk about several constituent architectures that together comprise EA. Typically, these are business architecture, information (data) architecture, application architecture, and technical architecture. Each of these architectures provides a different perspective on the enterprise and each is required to meet the overall enterprise goals. To better understand what application architecture is, let’s start by looking at its goals.
For a single application, the goal of the application architecture is to structure the application so that it meets both its functional and nonfunctional requirements. This means that it has to provide the required business functionality with sufficient performance, scalability, availability, security, and so on. However, enterprise architecture is not concerned with a single application. Rather, it is concerned with the entirety of all the applications. At an enterprise level, the goal of application architecture is to achieve consistency, commonality and interoperability between these applications.
For example, if over time we will build 5 or 10 (or more) different applications that provide a Web interface to existing applications, it probably makes sense to have all of those applications structured alike. This reduces complexity and increases the opportunity for reuse of software and hardware resources. Secondly, if all of our applications have a requirement, for example, to send printed correspondence, we probably want to have a common mechanism for generating and sending the correspondence. (Although I’ve soft-peddled by saying “probably,” it is rare that there is any real justification for not having this consistency and commonality. More often, a lack of architecture and/or forethought just leads to multiple different solutions.) Finally, we will have numerous applications in our enterprise and we will need those applications to interoperate and share information. This is much easier if we plan for it, rather than try to retrofit it later.
The way that we achieve these enterprise goals is by defining an application architecture comprised of architectural elements that have specific roles and responsibilities. These architectural elements are combined to meet the requirements of specific applications. For example, the Web applications mentioned earlier would have presentation elements, user session elements, business logic elements, and enterprise data elements. The responsibility of the user session is to apply personalization to the user experience, maintain state across Web pages, and mediate between the user and business functions. The same user session could be used across a variety of user devices (e.g., wireless), not just a Web page. In other words, the roles and responsibilities have purposely been defined to be applicable across a range of applications.
Similarly, the same business logic elements could be used across a variety of access channels including Web pages, B2B, and Web services. This is not just coincidence. The combination of architectural elements for each of these applications would be different, but they would overlap to provide the consistency and commonality required of the enterprise. This is what application architecture is all about.
The key to making this work is to focus the application architecture on the logical aspects of an application. It should describe the functions that application elements perform and what their roles and responsibilities are. It should not focus on whether something is a JSP or an EJB — that is done in one (or more) mappings to the technology architecture (for example, the same application architecture can be implemented with J2EE and .NET). In other words, application architecture must describe what the pieces of an application do, not how they are built.
When we start to concentrate on the logical construction of applications rather than the physical, we begin to make the critical shift in thinking that enables service-oriented architecture (SOA) to be successful. As with application architecture, SOA is not concerned so much with the construction of a single service, but rather the consistency, commonality, and interoperability of services across the entirety of applications. By defining services to follow the application architecture, we can achieve the consistency and commonality. Moreover, by aligning services with the roles and responsibilities of the application architecture, we end up with services that have similar form, function, scope, and concern. This makes it much easier to interoperate between services and to mix and match them in composed business processes.
There are of course many other reasons for the separation of the logical, application architecture, from the physical, technical architecture, but I’ll have to save those for another Advisor. In the meantime, where is the focus of your application architecture?
— Mike Rosen, Senior Consultant, Cutter Consortium