The second edition of Software Systems Architecture, published in November 2011, includes major updates to the discussion around architecture for Agile projects, a new System Context viewpoint, a new lightweight validation methodology (TARA- Tiny Architectural Review Approach) and updates to the models to UML 2. The core focus of the book is Architecture Documentation, specifically the catalogue of viewpoints and perspectives which was introduced in the first edition.
Software Systems Architecture is a comprehensive discussion of the field of software architecture meant to be a handbook for software architects to understand and execute on the lifecycle of an architecture beginning with stakeholder interaction for requirements management through continual improvement. One of the highlights of the book is the recommended set of modifications in the approach depending on the size, risk and development methodology for a project. The book covers a lot of ground but this interview focuses on some of the new topics addressed in the latest edition.
InfoQ: Why the need for a new viewpoint and perspective catalog in the presence of existing frameworks such as "4+1", RM-ODP etc?
We didn't initially set out to create a viewpoint set, or indeed write a book. The book came about because when we started, in 2000, there weren't many software architecture books aimed at practitioners, so this led us to write one. We'd discovered the IEEE 1471 standard (which standardises the concepts of view and viewpoint) and we thought that it would provide a good framework to organise our ideas. Hence the idea of creating a viewpoint set was born. We had practical experience of using "4+1" successfully, but found that in the kind of work we were involved in (enterprise information systems) it wasn't a perfect fit. So we created our viewpoint set as a very direct extension and tailoring of the already successful "4+1" set, aimed at the needs of those building enterprise information systems, based on our experience doing so.
The idea of perspectives didn't exist before our first edition in 2005, so that's something that we contributed to the field. We hope that others find it useful. We do! The reason we created perspectives was that we needed a structure that allowed us to capture advice relating to achieving quality properties such as scalability or security that could apply across a number of architectural views. This is something that we and most other architects were doing implicitly, sometimes without really thinking about it. Perspectives just formalised the approach, so that we could define a simple framework for doing it along with guidelines and checklists for the different types of quality property.
InfoQ: Why was the context viewpoint added to the catalog?
When we wrote the first edition of the book, we had a strong-minded view that the system context diagram and external interface definitions were part of the system's requirements. So you'd have those in hand before getting the architecture effort under way. Of course, the world typically doesn't work that way: the most important architecture work is done early in the lifecycle, when uncertainty is at a maximum and scope and requirements often haven’t been discussed or agreed. We found ourselves creating a context diagram as part of our architectural description on almost every project we worked on. So in defining a context viewpoint, we've just faced up to reality!
InfoQ: How is the role of the architect affected by the wave of IT consumerization efforts through mobile and cloud technologies and increased focus on user experience(UX)?
Consumers tend to be much less tolerant of slow, unavailable, unstable, insecure or unusable systems than enterprise users, who typically have much less choice and have to use what they're given. Achieving quality properties like this is a primary goal of software architecture, so the importance of software architecture probably grows as IT becomes more consumerized. While in one sense we still have the same problems and pitfalls, the move to Internet- centric deployment, with cloud-based servers and mobile devices, introduces many new intriguing architectural options and associated tradeoffs. For example, we now find ourselves thinking more about eventual consistency (e.g. the BASE architectural style) rather than always using “ACIDic” transactions and considering the new deployment options available when deploying to a cloud environment, rather than a traditional data centre. We think that as an industry we're only beginning to understand the implications of this and the future looks as if it's full of exciting developments triggered by these new options open to us. Such radical new options and the associated tradeoffs have profound architectural implications for our systems, so everyone is going to need to be thinking more architecturally as this shift to the cloud occurs.
InfoQ: For Agile teams, you recommend that the architect should align his/her work with the sprints and focus on minimal effective architectural effort through creation of executable models. Can you exemplify executable model?
We don't necessarily recommend creating executable models. For some people they may be very useful and work very well, but for mainstream enterprise systems development we've yet to see this in practice. What we mean is that the architect should be producing something useful that "runs" and that people can use. It might be a prototype spike, an implementation of the core domain model, a "walking skeleton" initial system implementation, a proof of concept exercise, some executable failing tests that you want focus on or a performance model implemented in Excel. The key point is that it needs to be useful and executable so that people can use it in a practical way immediately.
InfoQ: One of the issues with software projects is continued compliance with the predefined architecture as product development work proceeds. Are there a recommended set of tools and processes to ensure compliance and consistency between the various views and the ongoing development work?
Quite honestly there isn't a strong set of proven tools and practices that we can recommend for these concerns. There are two problems here. Firstly, how do you check that your views are consistent with respect to each other? Secondly, how do you check that the implementation matches the architecture that the system needs? The first problem isn't solvable by machine unless your views are all machine- readable and most views aren't - they're a mix of relatively formal notations like UML, informal notations and natural language. So we've defined a set of rules for checking compliance between views created using our viewpoints, which is useful, but the checking has to be manual. When it comes to checking that the implementation matches the system's desired architecture, there are a number of approaches that can help with aspects of this including architectural assessment methods, static analysis (e.g. Structure 101, Lattix, SonarJ, Axivion Bauhaus) and module systems (like OSGi or Impala for Java). In reality though, checking compliance with anything apart from the simplest aspects of an architecture is a really hard problem that current tools and techniques don't really address. Today, expert review and judgement is still probably the best tool we have.
About the Book Authors
Nick Rozanski has worked in IT since 1980 for several large and small systems integrators, including Logica, Capgemini, and Sybase, and end user organizations including Marks and Spencer and Barclays Global Investors. He has taken senior roles on a wide range of programs in finance, retail, manufacturing, and government. His technology background includes enterprise application integration, package implementation, relational database, data replication, and object-oriented software development. He is also an experienced technical instructor and certified internal project auditor.
Eoin (pronounced “Owen”) Woods is a lead system architect in the equities technology group of a major European investment bank with architecture and design responsibility for a number of the organization’s key systems. Prior to this, he led the application architecture group at Barclays Global Investors and has worked as a software engineer for Group Bull, Sybase, InterTrust, and Zuhlke, as well as through his own consultancy company, Artechra.
