How different architects work together to define software system architecture?

The involvement of various architects in the system architecture definition process is given in the responsibility assignment matrix (RAM) in the table 1. All the architects work together to define the software system architect.

Table 1. RAM for architects.

Architect	IV	FV	CV	Dev.V	DV	OV
SA	C	C	C	AC	C	C
AA	I	A	I	I	I	I
DA	A	I	I	P	P	P
IA	I	I	I	P	P	P
INA	I	I	A	P	I	I
SECA	P	P	A	P	P	P
PA	NA	NA	NA	I	I	I
NA	P	P	P	P	A	A
SEA	P	P	P	P	A	A
WRA	P	P	P	P	A	A

Table 2

*Code*	*Description*	*Comments*
A	Accountable	Responsible for success/failure of this activity
P	Participant	Actively participates in the activity
NA	Not applicable	This person is not applicable for this task.
I	Input Provider	Project Team needs input from this person in this activity
S	Sign-off Required	Must sign-off the appropriate document
C	Co-ordination	Co-ordinates and Leads the effort.

Table 3

SA	System Architect
AA	Application Architect
DA	Data Architect
IA	Information Architect
INA	Integration Architect
SECA	Security Architect
PA	Process Architect
NA	Network Architect
SEA	Server Architect
WRA	Web Runtime Architect

Table 4

IV	Information Viewpoint
FV	Functional Viewpoint
CV	Concurrency Viewpoint
Dev.V	Development Viewpoint
DV	Deployment Viewpoint
OV	Operational Viewpoint

What is software system architecture?

Software system architecture is collection of viewpoints. The types of viewpoints depends on the type of systems. Software system architecture for a typical web application contains information and functional views primarily focuses on the structural (or static) representation of the system and the deployment, concurrency and operational views are the behavioral (or run-time/dynamic) representation of the system and the development view is guidelines. Views are instance of viewpoints. Viewpoint is a set of standards, guidelines, templates, patterns for constructing a view.

Functional viewpoint:
The functional viewpoint represents the business processes and function elements of the system. It is mandatory for all web development projects since all web projects are executed to meet a set of functional requirement.
Information viewpoint:
It represents the data and flow of the data within the system. The data or information is integral of the web system.
Deployment viewpoint:
The typical web environment contains minimum a web server with internal disk, domain name server, web browser, inter network or intra network. The environment could be complex for a transaction application. It contains quite few infrastructure components like web server, router, switches, firewall, application server, domain name server, intrusion detection devices, messaging services, storage management systems, load balancer, ssl accelerator, external cache devices etc. It is essential to understand the deployment view of the system upfront during the architecture definition phase of the software development life cycle.
Development viewpoint
In an enterprise environment, there are set of standards, policies, patterns, anti-patterns, reference models, lessons learned, domain knowledge, reference architecture and etc. The development team is expected to reuse the existing references. These artifacts are provided to the application developed team by the centralized architecture team. With recent success of the outsourcing development model, the development viewpoint is required to be part of the architecture.
Concurrency viewpoint:
The functional elements of the system are to be served simultaneously for concurrent users in the web environment. It is required to study the behavior of the concurrency structure of functional elements. It enables to create the necessary environment setup like thread configuration for the operational viewpoint.
Operation viewpoint
The gap between the application development process and the infrastructure management process is quite significant in the industry in spite of the well known IT infrastructure management frameworks like ITIL being in place and adapted widely. The longevity, sustainability, maintainability of the system are determined how the operation views are analyzed and designed during the architecture phase of the project. It may be optional if the web application is developed for a limited time.

Software system architecture definition model

Consistency and repeatability in the architecture definition process is a must have requirement in an organization. It is like parents teaching some moral lessons to the kids. Kids will watch the parents if parents do practice what they teach them. If parents does not practice what they teach the kids, the kids are not going to buy-in to the parent’s teaching. Same situation with the architects. Architects emphasis and promote consistency, repeatability, efficiency and etc to the project team and if they do not practice those imperatives in their process and work product, it is going to be a hard sell for them.

Picture speaks more than thousand words. The above diagram illustrates a model, software system architects would follow to define the architecture blue print. The architect’s tool box are the knowledge gained through the internal process, individual experience, continuous improvement. The reference model and pattern catalog provides a framework for repeatability in the architecture definition process and in return implements those imperatives in the end product of the process. ie. software system architecture blueprint.

Software System Architecture definition process

Software System Architecture definition process defines solution blue print for a system requirement. The architecture blue print consists of various view points of a solution. Architecture is not detail design. The blue print is a guidelines for the detail design. It ensures all the constraints and the requirements are met before any signficant work (like detail design) is done. It is an iterative process. The blue print consists of view points like information, technology,development,deployment, functional, concurrency and etc. The different types of view point of the blue print depends on the type of systems. For instance, embedded system architecture blue print generally emphasis on concurrency,functional, deployment,technology view points and where as a financial system does not emphasis on concurrency view point. The system architect shall decide the required view points for the system requirements.

The blue print will be analyzed and validated from a different perspective like security, compliance and it is part of the architecture blue print validation process.