Software Architecture
 Logical View |
|
Software 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.
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.
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:
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.
| Logical View |
