In an earlier post on the Scrum development process, I outlined why I felt a lightweight agile process was a good choice for the IngentaConnect engineering team. This set me thinking that the way we express our architecture is similarly minimal, with many of the same desirable features, such as ease of adoption and consideration of needs outside the engineering team. However, while Scrum is very much in the public eye and receives ample press, the architectural model we use, Kruchten's 4+1 View, doesn't seem to have had its fair share of the limelight.

The 4+1 view was designed by Philippe Kruchten, and like Scrum one of its guiding principles was to address the needs not just of one specific group, in this case software architects, but all the people with a vested interest in the work. Krutchen describes these folk as stakeholders. These are the developers who will write software, the integrators who will manage servers, the project managers and the product clients. The concepts in 4+1 aren't all new, but they are a unique blend. The UML offers a smorgasbord of diagrams and documents to express an architecture, Krutchen's model distils the multiple representations into just four core models, or views, reinforced by a suite of worked examples or user scenarios.

The logical view is concerned with user features, services and functional requirements. The view illustrates key concepts, or abstractions; these become the software building blocks that will be needed to deliver features.
The development view, is focused on implementation, and the organization of the software. This includes grouping of code into easily managed units, determining functional layers and the interfaces between them.
The physical view illustrates where software components are actually deployed (in simple terms which machines they run on) and considers communications between software services. It is intended for system engineers and integrators, and is likely to present a number of variations tailored to different needs, for example test systems and production systems.
The process view takes abstractions from the logical view and considers how they will behave when executed, including issues like synchronisation and concurrency. This is achieved by breaking each process into tasks whose interactions may be more readily examined.

I've mentioned the four views, what about the +1? The plus one element is a set of user scenarios, or use cases. Although as vital as the views, they are denoted by '+1' because the model is already complete without them, there should be no new architectural information contained therein. The plus one element does however play a crucial role. It illustrates and communicates the architecture, concrete examples reinforce the modelling concepts in the views, and for those not familiar with modelling diagrams they provide an idea of what the architecture can achieve. User scenarios also serve to test and verify the model; working through a realistic set of interactions can expose new concepts, and generate confidence in those already identified.

So that’s 4+1 in a (rather small) nutshell, but what does is it bring to Ingenta’s technical products such as pub2web? The value of software architecture has parallels to the value of building architecture. It provides a vision of what is being built, defining boundaries, layout and interactions. The product shape is described even though the nuts and bolts aren’t. Despite this, the architecture provides enough detail to drive component design and implementation. The discipline of 4+1 ensures that non functional requirements such as scalability and fault tolerance are considered from the outset. In short; good architecture answers questions the architects did and, crucially didn’t, expect to be asked.