That’s fine and is certainly the way that the IEEE 1471 standard views the world.

The problem with this is that you tend to get a lot of duplicated information between views – that’s what lead us to the idea of perspectives. We suggest that you need one definitive set of views to define the structures and you don’t want duplication between them.

That said, in our real work both of us often create other architectural representations for specific groups of people. For example, you might have a formal UML model for your system components forming the core of your functional view and that’s the “real” description. But to explain the system’s main functions to (say) your IT auditors, you create a simplified picture in PowerPoint. As long as you’re clear about which is the “master” definition then this is no problem at all. The Powerpoint is discardable once you’re done with it, the functional view is maintained over time.

I certainly don’t think you’ve missed anything – you’re doing exactly the right thing and thinking carefully about the way you use these ideas and tailoring them for your environment.

What you’re doing is certainly using perspectives, you’re just extending them to have their own views associated with them. As long as you manage that redundancy and consistency between them, I’m sure this will work well.

> The key difference is that a perspective doesn’t result in a view.

Ok. That was clarifying. Thanks.

So you kind of apply a perspective to your architectural work to ensure that a particular quality attribute has been met. And that application might entail changes to one or more views. Hm. Fair enough, if I understand it rightly.

I’m trying to reconcile this with the way we’re working. We would define viewpoints that correspond to stakeholders concerns. Often the concerns would essentially be questions that pertain to some quality attribute. We could have a a scalability viewpoint for example. Then, we’d go about creating views upon our models (and possibly refine or extend the models (and codebase) themselves) which would reveal to what extent we cover the stated stakeholder concern.

Or to put it another way, we don’t use standard 4+1 viewpoints (or similar) as such, because they’re (often) not tightly enough connected to an expressed concern. And that makes the architectural work less cost-effective. In a sense, we cannot afford it.

Does this make sense? Does this reveal there is something we haven’t understood? Is what we do related to perspectives?

We don’t really get too steamed up about this one way or the other. It’s people doing good architectural design that matters and if they find the content useful and want to call them “viewpoints” that’s OK. However, we did separate the two for a reason ….

For us, a viewpoint tells you how to define an architectural structure. The Functional structure (i.e. components, interfaces, …) the Information structure (entities, data ownership and flow, …), the Deployment structure (nodes, system software mapping components to runtime environments, …) and so on. So an architectural view (in your architectural description) corresponds to a viewpoint and contains models that define one of the structures in the software architecture of the system.

We defined a perspective as being a collection of activities, checklists and so on that guides an architect to help them make sure that their architectural design will exhibit a particular quality (performance, security, scalability, availability, …)

The key difference is that a perspective doesn’t result in a view. Rather you apply a perspective (its process, activities, checklists etc) to your architecture, normally as described in a set of views. For example, applying the security perspective might mean that you end up changing the functional view to partition components differently to allow them to be secured (and maybe add a security manager component) you change the information view for similar partitioning reasons and you change the deployment view to add in security mechanisms to the system’s runtime structure.

So using a viewpoint results in a new view (a model or maybe a set of models). Using a perspective (probably) results in changes to one or more views in your architectural description. It doesn’t result in a new architectural structure itself.

Now this *is* an extension to IEEE 1471, but it’s one we’ve found useful.

I’ll try to put something on my blog about this in the next day or two.

Best wishes,

Eoin.