Application Architecture

Application Architecture

As mentioned before, I live mostly in the Application Architecture area. Even within this one area, there are several views of the architecture. I like Rational's Four Plus One views.  Rational has refined the definitions several times since Phillipe Kruchten's original paper, but I stick with Frank Dupont, my first Rational trainer when RUP was still in beta:

Logical View	Allocates classes and responsibilities to packages and subsystems.
Development View	Allocates packages and subsystems to layers and components. Also defines the development structure.
Process View	Allocates components to processes.
Physical View	Allocates processes to processors, nodes, networks.
Use Case View	(The Plus One) Captures requirements used to develop and validate each of the other views.

Application architecture can be considered alone, but it makes most sense as part of the pyramid. Applications spring from needs and requirements coming from the business and information layers. Application architects must work with data and infrastructure designers to get their systems working and deployed to their users. Increasingly, new systems use services of existing systems, so application architects must work together to integrate. While Application Architects are more focused on individual systems than Enterprise Architects, the scope of their interactions and interests are often the same.

By the Way, What is an Application?

Back in mainframe and Client-Server days, we knew what "application" meant. It was a collection of programs, or maybe one gigantic client program, that delivered a set of related business functions to the user. One project team usually built an application from end-to-end in one cohesive effort. In my COBOL days, the company imposed a project code in the name space, so for example we knew that every file and program starting with E0186 was part of the Work In Process application.
Nowadays things are more complex. A solid Enterprise Application Integration architecture allows interoperation between nearly any two platforms. A cohesive set of screens or web pages may still feel like an application to the user, but the back-end may combine parts from different systems, platforms and languages with purchased components and software hosted by business partners. It is becoming less useful to talk about "an application" and more useful to deliver increasingly integrated functionality to end users.
This kind of environment has great management and political challenges - who builds what and how does the next system pay to use it - but it really makes architecture fun.

Application Architecture Goals

Since the earliest days of data processing, coders and their managers have struggled to define programming goodness. We can see this in an arc over the years, from Edsger W. Dijkstra's letter "Go-To Statement Considered Harmful" through structured concepts of coupling, cohesion and information hiding, and object oriented encapsulation and whole books of design principles.
Architecture, thinking in larger terms than code, components or individual systems, has its own vocabulary of goodness. I have a list of about 100 possible measures of quality that I pull out for review before starting a project. An organization should decide which ones it believes are important, and set clear priorities, perhaps as enterprise defaults modified by business needs on a project-by-project basis. Here are just a few:

• Meet business goals by enabling software to reduce costs, increase profits or differentiate the company.
• RASP: Reliability, Availability, Scalability, Performance, 
• Usability.
• Extensibility.
• Freedom from defects.
• Low cost and rapid delivery.
• Layered architectures, wherein ...
• Each layer has a clear, focused purpose (high cohesion)
• Layers are cleanly separated and independent (low coupling)
• Conformance to team, department, company and industry standards.
• Practice reuse.
• Contribute components to future reuse.
• Channel independence - use the same components for Internet, fat-client, voice response units, wireless, etc.
• Consistent data and rules across all channels
• Interoperability between disparate platforms, languages, etc.
• Portability
• And many more ...

The Architect's Job

The Application Architect operates nearly as a peer to the project manager. While the project manager deals with budgets, plans, resources and tracking progress, the architect sets the technical vision for the project, mentors the technical staff, and monitors design and implementation artifacts for quality and compliance to standards.