The Gartner Group has three interesting papers entitled “Application Architecture Overview, Part 1, 2, and 3”. Each deal with looks at the scope of application architecture content and its relationship to other types of architecture (Part 1), how the roles of solution architect break down to handle the project and overall scope, and a detailed look at the various roles played by other roles (Part 3).
Overall, I found these papers interesting in that they provide a very systems engineering like analysis to job of helping the customer/sponsor define the capabilities of the system, deriving requirements from those capabilities, developing a conceptual design, finalized system architecture and a finished system.
The paper breaks down this process chain into a series of well thought out steps that make the development process easy to understand. In part 2 Garner explains how the various roles map to the parts of the development team. They then go on to explain the role of the solution architect in a great deal of depth. I like that the report focuses on the need for the solution architect to create repeatable logical standards and guidelines (solution patterns) and how these patterns help software developers build their products. The Open Group has referred to these as architectural patterns in their TOGAF documentation, but not done nearly as good a job as Gartner in explaining their relevancy to solutions architecture.
In part 3, Gartner focuses on roles of the solution architect and the application architect. The paper breaks down both the scope and the role of the solution and application architect within a project, where they may over lap and where they are distinctly different.
Part 3 goes on to examine types of projects and how these work within the boundaries of size relevant to the need and scope of the solution and application architects involvement. I found it interesting that Gartner recognizes the model-driven analysis and design methodologies and their relevancy to solutions and applications development. Many projects are being too complex to be handled with Word, Excel, and PowerPoint, that model driven development has the capacity to handle that complexity.
All in all, this was an excellent summary of application architecture.