Working Page for the Views & Viewpoints Working Group – All Materials are DRAFT. 


SEI defines the architectural view as a representation of a set of system elements and the relations associated with them. Moreover, SEI defines software architecture as a set of structures used to reason about the system that comprise various system elements with their relations and external properties. So each software system architectures consists of many system structures. Views and Beyond approach acknowledges that the contemporary software systems occur to be very sophisticated and so as to grasp their complexity recommends architects to focus at one structure at a time. Each structures is in V&B approach represented as a view. Compared to other views and viewpoints approaches such Woods and Rozanski viewpoints sets that prescribe the fixed set of views to engineer and communicate architecture, The V&B adopts the policy that architects ought to produce any views that appear to be useful for the designed architecture and afterwards document all assumptions and design rationale concerning all views. This policy constitutes the core of V&B philosophy. Due to that policy, V&B approach effective and sufficiently general to be tailored to document architecture of any software system. Thus, it is the art and science of which views architects shall pick up to address particular set of architectural concerns and suitable for particular system type. For instance, in the business intelligence industry in which IT systems are described using the data models in E/R notation it’s quite uncommon and rarely encountered to utilize the views depicting code structure or runtime structures and behavior with components and connectors.

The view types utilized in V&B approach.

The V&B views catalog remains practically unlimited. To systemize the open-ended collection views SEI categorizes views according to the types of information they convey into following groups:

Viewpoint Definition
Module Describing the system code units are structured. SEI defines module as code unit with set of coherent responsibilities, its external properties (quality attributes) and interfaces. For instance, Decomposition Module view may show how the system is functionally decomposed into modules and submodules and which modules are visible to which other modules.
Component and Connector(C&C) Views Reflecting system run-time structures and how run-time system elements interact with each other. For instance, C&C view which system run time elements are involved in processing banking online transaction and how such a request is processed.
 Allocation Views  Reflecting how IT system relates to the non-software environment. For instance, which software modules are deployed onto which processing nodes or environment platforms or which system run time elements executes on which processing nodes.


Practically each architecture view may be classified as member of one of that tree groups. Initially the classification outline above may occur to be relatively abstract, but familiarizing with the views specializations within each group – architecture styles – enables architect to comprehend their nature and how effectively utilize them.  Putting it into another words, the V&B view types classify virtually the available architecture structures. The V&B approach defines precisely types of structures utilized by each view type.

Architecture styles

Architecture styles

Each architecture view type utilizes one type of architectural structures. Architecture structure consist of elements, their relations and set of restrictions how architectural elements may be related. For instance, in Module Decomposition views the structure consists of modules – code units with coherent set of responsibilities – combined with is ‘’is part of ” relation – related by the fact that one modules conveys/is decomposed into its submodules. The decomposition view imposes the restriction on the module used in it by requiring that each module can be only part of one parent modules and that there cannot be loops in the decomposition structure. If module A contains the module B and module B contains module C it’s logical that module C cannot contain module A.

The module structure utilized in decomposition module views specializes in some way the general type of module structure utilized in Module views. This specialization is called the architecture style. Architecture style specializes the element types (“legacy application (component type) ”, “services bus(connector type)”), the relation types (“publishes” – legacy application publishes event via service bus, “subscribes” – legacy application registers to service bus to receive events announced by other applications) and imposes some constraints on relations (legacy applications (components – roles subscribers and components) can interact among themselves only via service bus (connector) by announcing events (“publishes” relation) or by responding to the subscribed events (“subscribes” relation)).

The architect selects the module, component and connectors or allocation styles based on design problems he/she attempts to address – especially on quality attributes which are going to be achieved.  For instance, numerous architects utilize the decomposition module style to design and analyze system modifiability by encapsulating changeable aspects of the system in the separate modules. For instance, in metadata-driven data warehouses the general-purpose, “customizable” functionality is encapsulated in the metadata-steered modules, whereas the only changes in the production system are incorporated to its configuration – data warehouse metadata.

The V&B approach documents the most important architecture styles in the style’s guide.  The V&B styles guide indicates the design challenges/issues the style is appropriate/inappropriate to address, notations suitable to capture the views in that style, analytical approaches in which this style is utilized and enlists the other styles it relates to. Comprehending the architecture styles described in the V&B style guide constitutes the prerequisite for the successful application of V&B approach.

It’s worth highlighting that several architecture style may be combined in one architecture view. For instance, in one module view we may capture the usage dependencies between various submodules (Uses style) altogether with system functional decomposition into various sub-modules (Decomposition style).

The V&B style guide encompasses following architecture styles:

  1. Module architecture styles:
    1. Decomposition style.
    2. Uses style.
    3. Generalization style.
    4. Layered style.
    5. Aspect style.
  2. Component and Connector styles:
    1. Event styles: publish-and-subscribe style, others.
    2. Data flow style.
    3. Repository style.
    4. Call-and-return style: SOA style, client-server, peer-to-pear style.
  3. Allocation styles:
    1. Deployment style.
    2. Work assignment style.


Choosing the Views

Choosing the views

The V&B approaches the issue of choosing the appropriate views to design the system architecture based on the stakeholder concerns. The simple, three-step process is outlined below:

  1. Producing a candidate view list by mapping in simple matrix mapping comprehensively all solution stakeholder groups onto the architecture views. The architecture views in various architecture styles are matched with the stakeholder in case they address the concerns of that stakeholder group. The mapping results in the list of architecture views solution stakeholders have vested interest.
  2. Combining the views. The goal of this steps is to reduce the view list to the manageable size. The first stage is to identify the views handling the concerns of the very few stakeholders or concerns not requiring any in-depth analysis. In such cases, these concerns could be addressed by the views with stronger constituency. Combining views reduces the view list to the manageable size.
  3. Prioritizing the views. The goal of prioritizing is determining in which sequence architect will work on the views. Prioritization often depends on the stakeholder importance and the most important quality attributes which have to be achieved.


V&B view templates

No matter which views architect picks up while designing the architecture, the V&B approach advocates the standard organization for documenting the architecture views comprising of seven parts:

  1. A primary view presentation – usually graphical – showing the elements and relationships among them that populating the view, The primary presentation should contain the information architect wishes to convey about the system.
  2. An element catalog elaborating on the elements (and their properties, including interfaces) depicted in the primary presentation altogether with justification of any omission of elements not covered in the view.
  3. A context diagram showing how the portion of the system depicted in the primary presentation relates to its environment and the system as the whole.
  4. A variability guide showing how to exercise any variation points that are part of the system architecture being designed and scoped by the view.
  5. Design rationale. An architecture background – stakeholder concerns, constraints, principles, standards, organizational factors – and rationale outlining why the part of architecture – architecture structures – covered by the was designed in one not other way altogether with various architectural trade-offs which had to be made.
  6. An “other information” section contains items that vary according to the standard practices of each organization or the needs of the particular project. Figure 1 illustrates the template for a view.


Practical considerations

V&B approach is general, coherent, complete, flexible, systematic and comprehensive method for documenting software architectures. It can be successfully tailored and adapted to design and engineering practices specific to any class of IT systems. To my mind, the main challenge, the architect faces while applying the V&B approach is its generality. V&B generality contributes to the fact the architect, especially inexperienced one, is forced to build his/her toolset applicable to the particular class of systems – for instance, figure out which architecture styles and corresponding views occur to be most useful while designing Big Data systems.

Other topics, which are vaguely covered in V&B approach due to its generality, are ensuring consistency between views and how to conduct the quality attributes analysis using architectural views. Other views and viewpoint approaches – such Woods and Rozanski viewpoints and perspectives set – provide more detailed guidelines on how to incorporate the consistency between the views in architecture design and comprehensively approach design challenges aiming at achieving desired quality attributes using architecture views.

The most recommended approach occurs to be combining the V&B with other approaches such as Krutchen’s 4 + 1 or this advocated by Woods and Rozanski.

SEI Module Views introduction

  1. SEI Module Views overview.
  2. Elements – modules and their properties, relations, constrains.
    1. Module views in practice.
    2. Practical considerations and challenges.

Module view elements – practical considerations and challenges:

  • Finding the notation for depicting the module interfaces in views utilizing the UML package elements.
  • Very important! Pay attention to the module definition to have the correct of module in Views and Beyond approach to have the correct understanding of the Module Views.


  1. SEI Module Views application.
    1. Module Views application overview.
    2. Applying module views in practice.

Module Views application in practice:

  • Module views at sufficient granularity level constitute very useful framework for project management and planning/managing development activities. For instance, planning incremental development based on the module views in Decomposition and Uses styles.
  • Module Views can be utilized to model the architecture of the software product stacks as their descriptions submitted by vendors such as QlikView or Oracle.


  1. SEI Modules notations
  2. Module architecture styles Overview:
    1. Where to start when new project is launched

Where to start when new project is launched:

  • Assume that module views design will be performed iteratively.
  • In each iteration precisely define the module responsibilities and their interfaces.
  • Always start with Decomposition style.
  • Consider firstly to introduce the ready off-the-shelf modules from your software platform stack – for instance standard modules from the SQL Server 2014 Enterprise Edition.
  • Secondly, augment your module with the high-level custom modules which will be developed in your system.
  • Apply divide and conquer approach for defining module responsibilities. Perform several iterations decomposing your modules.
  • Design the Module view in layered style.
  • Design the Module view in uses style.
  • Design the Module views in Aspect style – – especially for modules which cannot be explicitly assigned to layers.
  • Elaborate the Module Views to the sufficient levels of granularity. Module views so as to be useful must be decomposed to the
    1. Combining various views.


  1. Module views case studies combining several styles


  1. Simplifying the global data warehouse architecture by eliminating the complexity and reducing module coupling introduced by the regional versions of common dimensions in global retail organization.
  1. Module architecture styles – Decomposition style.
    1. Practical advice.

Decomposition style – practical advice:

  1. Elaborate the view in decomposition style until the modules will be defined at enough detailed granularity so that their implementation could be handed over to developers team or be useful for project planning and management.
    1. Decomposition style – Practical challenges

Decomposition style – practical challenges:

  • Finding ways to define, model and capture the responsibilities.
  1. Decomposition style – Practical case studies.
    1. QlikSense decomposition view – case study how ambiguity concerning the QlikSense product stack elements and functionality was sorted out and enhanced communication by letting the client understand why this tool does not occur to be appropriate for enterprise deployment.
    2. Microsoft BI Stack on premise and in cloud decomposition view – utilizing the module view to understand the difference between Microsoft BI capabilities on premise and on the Azure platform.
  2. Module architecture styles – Uses style.
    1. Practical advice:
    2. Uses style practical case studies:
      1. Decoupling ETL process chains by incorporating metadata-driven modules.
      2. Depicting the impact of lack of semantic layer in QlikSense – application chaining.
    3. Module architecture styles – Layered style.
    4. Module architecture style – Aspect style.
      1. Practical advice.
      2. Aspect style case studies:
        1. Designing common functionality in Data Warehouses – common features and logging for managing the batch processing in enterprise data warehouses.
        2. Designing logging and tracing web service execution in Enterprise Service Bus in SOA architectures.
  • Modeling middleware common services for Oracle Business Intelligence.


  1. Module architecture style – E/R style.
    1. Practical advice.

E/R style practical considerations:

  • Consider utilizing the class diagrams instead of E/R diagrams. UML class diagrams have significantly richer semantics and expressiveness. Furthermore, they can be combined into


  1. E/R style case studies.
    1. Sample data warehousing dimensional model.
  2. xxx

SEI Module Views – Layered Module architecture style

Definition of module – coherent set o responsibilities, interfaces and quality attributes.

The following article aims at introducing SEI layered module views based on the template custom cloud -based application utilizing Azure SQL Database service. The following diagram depicts the layered view of the Azure SQL Database service:

The SEI module views created according to the layered architecture style consists of layers. Layers are defined as grouping of modules offering together cohesive set of services to other layers. The SQL Azure Database Service and any application based on it can be partitioned into following layers providing well-defined set of services:

  1. Custom Application layer – consists of any modules of custom applications utilizing SQL Service Database services.
  2. Client Tool layer – consists of tools utilized by custom applications to connect and communicate directly with SQL Database Service utilizing TDS protocol.
  3. Services layer – The following layers acts as gateway to the Platform layer and provide services related to the connection routing, provisioning and metering.
  4. Platform layer – layer offering services implementing database services and any other supporting ones
  5. Infrastructure layer – layer managing physical hardware and operating systems with Azure’s fabric controller and hypervisor.

The rationale behind such partition is to separate the automated, provided by Azure infrastructure and platform management services from modules created or modified by custom applications utilizing Azure SQL Database Service.

Each layer constitutes the grouping of modules– often quite diverse – providing coherent set of services. Client Tool layer contains diverse tools enabling the connection to Azure SQL Database TDS endpoint such as Azure SDKs, REST APIs, Portals or SQL Server Management Apps.

In the layered system each software module is allocated to only one layer. Decision of allocating module to the layer depends on the type of potential changes or based on cohesion. For instance, while designing web apps utilizing Microsoft Azure, most of modules manipulating the application data directly will be assigned to the Azure Database Service layer in the form of T-SQL database apps to locate together all pieces of software managing and storing the application data. Any changes to the way the information is stored and managed will be incorporated to the custom database applications.

Each layer may consist of other sub-layers (or sub-systems) or be segmented horizaontally. Platform Services consists actually from Azure Elastic DB and Azure SQL Database services utilized by custom application and their Supporting Services such as Elastic Database library allowing applications to create and manage sharded databases.

One of the assumptions associated with layering concept is that each layer will involve independently. In the case of Azure SQL Database Service Microsoft develops the Infrastructure, Services and parts of Platform layers whereas the application vendor focuses on designing modules handling the business logics and user interface interactions in Custom Application layer or information management and storage in Platform layer. Obviously, the application vendor benefits greatly from such arrangement as it does not have to cope with infrastructure and operating system management.

The layers are related with ‘allowed-to-use’ relations. If layer B is related with layer A with allowed-to-use relation denotes that the modules from layer B may use the modules in layer A but not the reverse. In our example, the modules from Custom Application Layer may utilize only services of the modules from Client Tools layer to interact with appropriate SQL databases in the Platform layer. The allowed-to-use relations between layers determine practically the sequence of interactions. The custom application utilizing may utilize the REST API to interact with the Azure SQL Database application. Module handling REST API connection must use the Services Layer to establish and handle the connection to the SQL database. The modules from Services Layer directly pass the database processing requests to the SQL Server databases in Platform layer. The custom application may not bypass services layer and use the SQL Server database in Platform layer directly.

Each layer exposes its services through public interface to the upper layer and dedicated segments of modules within it. The SQL Server database interacts with Services and Client Tools layers over TDS protocol. Infrastructure layers certainly exposes some API accessible to the Supporting Services sublayer, but unavailable to the SQL Server Databases and hence to the custom applications.

Introducing well-thought-out layering into application provides several important benefits:

  1. Separation of concerns – the system is functionally well-structured, less complex due to more transparently and coherently managed dependencies between its modules and cohesive module responsibilities.
  2. Increased modifiability – modules providing similar functionalities are grouped together and modules have cohesively assigned responsibilities. Furthermore, system layers may be modified independently without impact on upper layers unless their public interfaces (APIs and assumptions concerning services and quality attributes do not change).
  3. Increased portability – Each layer may be implemented in different technology and deployed separately.
  4. Simplified design and its analysis – thanks to less complex dependencies between modules.
  5. Supports incremental development and simplifies project management – each module knows the services of which other modules it may use. This fact simplifies the allocation of development tasks to developer teams and managing dependencies between them.


Case Study – SEI Module Views – Applying the Generalization, Layered and Uses architecture styles

Simplifying the global data warehouse architecture by eliminating the complexity and reducing module coupling introduced by the regional versions of conformed dimensions in global retail organization.

Referenced architecture styles: Layered, Generalization and Uses.

Problem statement:  

Global data warehouse in global retail organization consists of the multiple global data marts. Each global data mart contains the fact data concerning one or more business processes – record activity within them. The dimension that are utilized in the data mart describe the context of the business activity being recorded. Each data mart has on average between 10 and 15 conformed dimensions such as time, product, customer etc. However, global dimensions do not suit the local country reporting requirements. Each country – “market” – would like to have its own regional dimension hierarchies. Adding local dimension hierarchies to the global data mart – for instance one dimension hierarchy for customer dimensions for 14 countries – would extremely increase data sophistication, complicate existing ETL processes populating the data warehouse and require developing numerous additional modules processing local dimension hierarchies.  Thus, adding separate local dimensions to the global data marts occurs to be not feasible from technical and financial standpoint.  Alternative solution has to be figured out.

Case study purpose: Depicting how module views were utilized to analyze the consequences of adding additional local dimension hierarchies to the global data marts – conduct the impact analysis – in the global data warehouse utilizing Oracle database and Oracle Business Intelligence EE for reporting.

Case study scenario: To be provided. In progress.


[1].  Kruchten, Philippe, Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50, November 1995.


Marcin Wizgird