2. Stimulus—a condition that affects the system.
3. Artifact—the part of the system that was stimulated by the stimulus; it may be a collection of systems, the whole system, or some parts of it.
4. Environment—the set of circumstances in which the scenario takes place.
5. Response—the activity that results because of the stimulus. The response consists of the responsibilities that the system should perform in response to stimulus.
6. Response measure—the measure by which the system’s response will be evaluated.
In the environment, the source throws the stimulus and hits the system in the artifact.
The response measure makes the scenario operational. It is not enough to say the system is fast without knowing what the word fast really stands for; for some people this may be in 100 milliseconds, while according to others, it means 2 seconds. The response measure indicates what is acceptable. The important thing to know is that the response measure does not have enough information to evaluate the architecture.
For example, is the response time applied within two clicks from the user?
There are two types of QAS: general and concrete. The former are the scenarios that are general and do not belong to any system. The latter are scenarios that belong to a particular system under specific conditions. General scenarios allow the stakeholder to communicate effectively and help him develop a concrete scenario for the system. In general, QAS can be used as tool by stakeholders to help specify and prioritize the requirements of the architecture.
To conclude, Quality Attribute Scenario is about how a system is required to respond to some stimulus. General concepts of QAS for the availability quality are shown in Table 3.1.
When a stakeholder comes to the architect and says that they want an available system, the architect writes a general scenario for this type of quality. After that, the
3 Understanding and Dealing with Qualities
Table 3.1 General QAS for availability quality
Source
The source can be internal or external, for example, people, hardware, software, physical infrastructure, etc.
Stimulus
Fault
Artifacts
Processors, communication channels, persistent storage, process
Environment
Normal operation, shutdown, repair mode, overloaded operation
Response
Prevent fault from becoming failure
Detect the fault
Recovery from the fault
Response
Availability percentage, for example (99.999%), time to detect fault, time to measure
repair fault, time or time interval in which a system can be in a degraded mode, etc.
Table 3.2 Extracted table
Source
The source can be internal or external. For example, people, hardware, software, physical infrastructure, etc.
Stimulus
Fault: incorrect response, incorrect timing, crash
Artifacts
Processors, communication channels, persistent storage, process Environment
Normal operation, shutdown, repair mode, overloaded operation Response
Prevent fault from becoming failure
Detect the fault
Recovery from the fault
Response
Availability percentage, for example (99.999%), time to detect fault, time to measure
repair fault, time or time interval in which a system can be in a degraded mode, etc.
Table 3.3 Concrete table
Source
Internal hardware
Stimulus
Crash
Artifacts
Processors
Environment
Normal operation
Response
Detect the fault
Recovery from the fault
Response measure
System can be in a degraded mode no more than 15 minutes
stakeholder chooses the parts that he wants to be in his system. For example, the chosen parts from Table 3.1 are put in Table 3.2, and that will lead to the concrete scenario (Table 3.3).
Appendix A shows some examples on general scenarios for qualities and the concrete scenarios that can be derived from them.
3.4 Gathering Quality Attribute Information
45
Table 3.4 Concrete performance QAS
Source
A bus subsystem is the source of this scenario
Stimulus
The event here is sending a message with its location and speed every 15 seconds
Artifact
Artifact will be to the system or part of it here it will be to the central system Environment
It will be during the normal operation
Response
The system will react with these actions so it will produce an estimated arrival time for all relevant display and then send it out The response
The response measure here will be within 30 seconds under normal measure
conditions, and this will be after receiving the message from the bus 3.4.1.1 Example on QAS
Smart city transport system is a simple example of QAS. In this system each bus will have a subsystem that sends its speed and actual location to a central server. The central server then calculates the estimated arrival times for each bus; the performance is the quality that we need in this system. The concrete QAS of the performance quality to a smart city transport system is shown in Table 3.4.
The important thing to know is that a response time of 30 seconds may only be required under normal conditions, and that leads to create a second QAS under peak load conditions where we allow a response of 30 seconds with a jitter of 10 seconds.
A jitter is the delay that varies over time. In the context of computer networks, jitter is the variation in latency as measured in the variability over time of the packet latency across a network. This means that a network with a constant latency has no jitter.
3.4.2 Quality Attribute Workshop (QAW)
Quality Attribute Workshop is a facilitated method and a few-day workshop that is developed by SEI. It connects stakeholders in the early part of the life cycle in order to find quality attributes for the existing system. The system must exist in the real world in order to go through this technique of elicitation.
The important thing to know about QAW is that:
• It is focused on the stakeholders.
• It is scenario based.
• It is used before the software architecture begins.
• It is focused on the system level concerns and on the role of software in the system. Here the term “system level” is used because the development of the soft-
3 Understanding and Dealing with Qualities
ware begins with the description of the system’s operation, a high-level functional requirement, and any constraint on the system if the system is new or legacy.
QAW is one way to find, document, and prioritize the important qualities because quality attributes are often missing in the documentation of the requirement or even if exists they are weakly defined. The purpose of this workshop is to understand what quality attribute requirements important to stakeholders are and then use them as input into the design of architecture.
3.4.2.1 QAW Steps
The contribution of each stakeholder is very important during QAW; all participants are expected to engage or attend the workshop. The QAW involves the following steps:
Step 1: QAW presentation and introductions
Facilitators explain the goal of QAW and explain each step in the method by using standard slide presentation. Next, they introduce themselves and stakeholders do the same. They briefly state their background, their roles in the company, and their roles in the system.
Step 2: Business/mission presentation
The stakeholder represents the business concerns of the system. The quality attribute of the system will be derived from the business mission needs. The manager usually does the representation and it includes the following:
1. The business/mission context
2. The high-level functional requirements, constraints, and quality attribute requirements
Step 3: Architectural plan and presentation
The technical stakeholder will present the system architectural plans according to the early document. It will contain the following information: 1. The strategies on how to satisfy the business/mission requirements 2. Key technical requirements and constraints that will derive architectural decisions
3. The high-level system diagram and context diagram
Step 4: Identification of architectural drivers
The facilitators in this step will share their list of architectural drivers that are assembled in the previous step. The idea is to reach the architectural driver that includes all the requirements, business drivers, constraints, and quality attributes.
This will convince the stakeholders that these concerns are according to the scenario that is collected.
3.4 Gathering Quality Attribute Information
47
Step 5: Scenario brainstorming
After defining the architectural drivers, the facilitator initiates the brainstorming process in which stakeholders generate scenarios. Facilitators ensure that there is at least one scenario for every driver. The facilitators also reviewed the parts of scenario (stimulus, event, response, etc.) and ensure they will be formed well because the scenario is a key step in QAW and must be carried out with care.
There are some suggested points that come from SEI report (by Mario R. Barbacci et al.) to help the facilitator during this step:
• Facilitators should help the stakeholders create well-formed scenarios. For example, the stakeholders write the requirements such as “the system shall produce reports for the users.” This requirement is important but the role of the facilitator is to show the quality attribute of it.
• The vocabulary used to describe qualities varies widely. It is not important what we call “quality,” as long as there is a scenario that explains what is meant by it.
• The facilitator should always refer to the list of architectural drivers generated in step 4 to ensure the scenarios exist for each one.
The facilitator usually plays the role of the team leader who types everything during the meeting
Step 6: Scenario consolidation
This is an important step because facilitators usually ask the stakeholder to identify the scenarios that are similar in contents. Scenarios with similar contents are merged, as long as the people who suggested them agree that their scenarios will not affect the process. The consolidation process helps prevent votes from multiple scenarios which have the same concerns. Actually, very few scenarios are merged.
Step 7: Scenario prioritization
This step is accomplished by allocating each stakeholder a number of votes equal to 30 percent of the total number of scenarios that are created after consolidation.
For example, if 30 scenarios were created, each stakeholder gets 30 × 0.3 or 9 votes.
The votes are counted and the scenarios are prioritized accordingly.
Step 8: Scenario refinement
After prioritizing, the top four or five scenarios are refined in more detail.
Facilitators intricate each one and document the following:
• A clear description of the parts of QAS (stimulus, event, response, response measure, artifact, and environment)
• The business/mission goals that are affected by the scenario
• The related qualities associated with scenario
• The questions and issues of the stakeholders
3 Understanding and Dealing with Qualities
3.4.2.2 Advantages of QAW
QAW has many benefits; the most important ones are:
• Increasing stakeholder communications because it is the first meeting between the participants of the system
• Clarifying quality attribute requirements
• Creating a base for architectural decisions
• Improving architectural documentation
• Supporting analysis and testing throughout the life of the system The results of QAW include:
• A list of architectural drivers
• A list of scenarios and the prioritizing the most important one
• Refined scenarios
And these results lead to:
• Updating the organizational architectural vision
• Understanding the system’s architectural drivers
• Refining requirements
• Guiding the development of prototypes
• Exercise simulation
All the benefits of this information will help the architect design the architecture of the system. The scenario can also be used to evaluate the architecture if the ATAM
is used for evaluation; the scenarios that are generated from QAW will be incorporated with ATAM.
In addition to the evaluation, the documentation has its benefits from scenarios; for example, refined scenario can be documented as a sequence diagram or a collaboration diagram. All stakeholder concerns and any other information should be recorded individually in a form of packet overview documentation.
Also, the benefits of scenarios can extend to the implementation; it can be used to derive test cases development during implementation testing.
3.5 Summary
A quality attribute is a measurable property of the “goodness” of the product in terms of the stakeholders’ requirements. Quality attributes are usually divided in two main groups based on the qualities they are requesting: the first is those that describe the system at runtime (operational qualities), and the second is those that describe some property of the development of the system (development qualities).
49
Software qualities are becoming an important part in architecture, helping the architect to deal with the complexity of large systems. It is the role of the architect to understand the importance and the priority of each quality requirement. He needs to make the appropriate trade-offs in order to meet the quality levels that are expected by the stakeholders.
Software qualities are very important goals for the business for the following reasons:
• Predictability
• Reputation
• Customer satisfaction
A trade-off is a technique of reducing one or more required results in exchange for increasing other desirable results in order to maximize the effectiveness in a given situation. NFR is a type of method that is used to improve the application by structuring goals (nonfunctional requirements) and solutions. In the NFR, the term
“operationalizations” is used.
Quality Attribute Scenario is a technique to gather information for the qualities to build an efficient architecture of the system. A Quality Attribute Scenario consists of six parts:
• Source
• Stimulus
• Artifact
• Environment
• Response
• Response measure
On the other hand, Quality Attribute Workshop is a facilitated method and few-day workshop that is developed by SEI which connects stakeholders in the early part of the life cycle in order to find quality attributes for the existing system; it consists of eight steps:
Step 1: QAW presentation and introductions
Step 2: Business /mission presentation
Step 3 architectural plan and presentation
Step 4: Identification of architectural drivers
Step 5: Scenario brainstorming
Step 6: Scenario consolidation
Step 7: Scenario prioritization
Step 8: Scenario refinement
3 Understanding and Dealing with Qualities
References
L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 3rd edn. (Addison-Wesley, 2013)
I. Sommerville, Software Engineering, 9th edn. (Addison-Wesley, 2011) M. Barbacci et al., Quality AttributeWorkshops (QAWs), 3rd edn. Tecnical Report CMU/ SEI, 2003
On line training from SEI: Software Architecture: Principles and Practices, http://ww.sei.cmu.edu/
education-outreach/courses/online-training
Further Reading
Visiting the on line SEI library and searching on keywords of this chapter you will find a list of references as for example
Achieving Product Qualities through Software Architecture Practices by Linda Northop Toward Deriving Software Architectures From Quality Attributes by Rick Kazman Architecting high quality software: the role of software architecture in system development and evaluation by Linda Northop
A. Chandrasekar, S. Rajesh, P. Rajesh, A research study on software quality attributes. Int. J. Sci.
Res. Publ. 4(1), ISSN 2250-3153 (2014)
M. Barbacci, Software quality attributes and trade-offs, SEI, CMU, (2003) G. Bessin, The Business Value of Business Quality, (IBM Cooperation, 2004) J. Bergey, M. Barbacci, W. Wood, Using Quality Attribute Workshops to Evaluate Architectural Design Approaches in a Major System Acquisition: A Case Study, Technical Report, CMU/
SEI, July 2000
Chapter 4
Achieving Quality Attribute
Abstract Patterns help you build the architecture on the shared experience of skilled software engineers. They capture experience in software development and help to promote good design practice. Every pattern deals with a specific, recurring problem in the design or implementation of a software system. Architectural styles and patterns define the way to manage the components of the system so that one can build a system and also achieve the requirements of the stakeholders. Several architectural styles and patterns exist in the world of the software architecture, so one needs to understand which particular architecture style/pattern will be suitable through building the system. Architectural tactic is a design decision that influences the achievement of quality attribute response. Every pattern deals with many qualities, while tactic deals with a specific type of quality. The important thing to know is that most patterns consist of several different types of tactics that serve a common purpose. The relation between pattern and tactic is described in this chapter.
At the end of the chapter you will learn:
• Patterns and their roles in building architecture
• Relation between tactics and patterns and how to achieve the quality through these tactics
• Meaning of business patterns and the importance of these patterns in business
• The SEI attribute-driven design (ADD) method and how this method works and what it will use for
4.1 Introduction
Architects are the main ones responsible to solve recurring problems through building the architecture. Architects are responsible for making design decisions about achieving things that can only be achieved through architectural structure. So it is often the architect’s first step to start choosing architectural patterns; this will help structure the architecture to solve different problems and then achieve a variety of qualities. This chapter defines what pattern is, the relation between pattern and tactics, and how one can use it to achieve high-quality products.
© Springer Nature Switzerland AG 2020
51
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_4
4 Achieving Quality Attribute
4.2 Architectural Pattern
Architectural patterns are compositions of elements in a way that can be used to solve specific problems. These patterns will be useful over time and over many different domains, and that is the reason why they are documented and then distributed. Each pattern describes recurring problems that arise in specific design contexts and presents a solution for the problem. The definition of pattern can be summarized in one statement: it is a solution to a problem in a context.
The solution part describes the architectural structures that solve the problem.
The actual solution represents the major elements of the pattern and the roles, responsibilities, and proprieties of these elements; it also describes the relation between these elements. Through writing patterns, it becomes easier to reuse the solution. An architect for a software system designs its architectural structures to solve a variety of design problems. The architectural structures designed by an architect are often based on one or more patterns.
Figure 4.1 shows the three types of structures:
• Module structure: it is a static way for considering the system; it shows how the system is structured as a set of codes or units. It is a good way to reason about the modifiability quality.
• Component-and-connector structure: it structures the system as a set of components and connectors. Here, components are runtime behavior, and that is why this type of structure is a good reason for performance, security, availability qualities, and even more.
• Allocation structure: in this structure, the decisions about how the system will relate to hardware and how teams will relate to their environment.
Appendix B shows a table about these structures; it lists the elements and type of relations and what they are used for.
Each pattern consists of a context, problem, and solution. This is shown in the following template (Table 4.1).
It is up to the architect to decide how patterns are initiated.
Component
Module
and
Allocation
Connector
Decomposition
Classes
Client Server
Shared Data
Deployment
Work
Assignment
Fig. 4.1 Examples on software architecture structures
53
Table 4.1 A template for pattern document
Context The situation that gives rise to a problem
Problem Recurring problem that arises in the given context. The description of the problem often includes the quality attributes that must be met
Solution A successful architectural resolution to the problem. The solution describes what quality attributes are provided by the static and runtime elements
4.2.1 Patterns and Their Roles in Building Architecture
To show the role of pattern in building the architecture of a system, an overview of pattern catalogue is needed. The list of the catalogues of this pattern used in this book are the ones that are more useful and used, for example, patterns of runtime such as broker or client-server and patterns of design time such as layer pattern.
Definitions of patterns in catalogues are all strict, but in practice, the architect may choose to violate them when a trade-off is needed. For example, the layer pattern prevents software in lower layers from using software in upper layers, but there may be some cases (e.g., when a performance is needed) where an architect allows a small amount of specific exceptions.
Patterns can be categorized by the control type of elements: module patterns show modules, component-and-connector patterns show component and connectors, and allocation patterns show the combination between software elements (module, component, and connector) and non-software elements.
Let us begin with module patterns.
A common module pattern is the layered pattern: a layer is a coherent set of related functionality. In this pattern, the system is decomposed into a number of higher and lower layers in a hierarchy, and each layer has its own task in the system.
The pattern layer is described as follows:
Context Complex systems need to develop parts of the system independently. Modules of this system may be developed and maintained independently
Problem The software needs to be segmented in such a way that modules can be developed and evolved separately supporting modifiability, portability, and reuse Solution To solve such problem, the layered pattern divides software into units called layers, and each of these layers consists of modules which can offer a set of services. Layers must be unidirectional, and this will be a constraint on the relationship Layered pattern solution
Overview
The layer pattern defines layers (a grouping of modules) and unidirectionality among these layers. These layers are always drawn as a stack of boxes Elements
Layered, a kind of module
Relations
Allow to use relation, which is a special kind and depends on relation Constraints Lower layer cannot use the above layer
4 Achieving Quality Attribute
Weakness
Layers contribute a performance penalty. While it is true that some layered architectures can perform well, the pattern does not lend itself to high-performance applications because it is not efficient to go through multiple layers of the architecture to fulfill a business request
Layers make the standardization easier because the abstraction of each level enables the development of standardized tasks and interfaces. The most stable abstractions are in the lower layer: a change of the behavior of a layer has no effect on the layers below it, while a change of the behavior of a lower layer has an effect on the layers above it, so that it should be avoided.
Networking protocols such as TCP/IP and web application are examples of this type of pattern.
A
B
C
Notation for layered design (Where A, B, C are layers)
From the notation of layer design, you can see three layers: A, B, and C. You can see that layers A and B are adjacent (each layer is a group of modules that presents a set of services). Layer A can use any public interface of layer B, but sometimes modules need modules in nonadjacent layers, and so a bridge layer is needed. If many bridging layers occur, portability and modifiability goals will not be achieved, and this will restrict this pattern. Upward usages are not allowed in this pattern Component-and-Connector Patterns
• Broker Pattern
The broker pattern is used to organize distributed systems with decoupled components, which interact by remote service invocations.
The broker pattern
Context When systems are constructed from many services that are allocated across many servers, then implementing such type of systems will be very complex Problem Structuring distributed software so that service users do not need to know the nature and location of service providers
Solution To sol In such problem, the broker pattern separates users of services ( clients) from providers of services ( servers) by inserting an intermediary, called a broker
55
Broker pattern solution
Overview
The pattern defines runtime components that mediate between clients and servers, called brokers
Elements
Client which requests services
Serve r which provides services
Broker, an intermediate component between the client and the server Client side proxy, an intermediary that manages the communication with the broker Server side proxy, an intermediary that manages the communication with the broker
Relations
Attachment relation is used to communicate clients and servers with brokers Constraints The client can only attach to a broker through client proxy, and server can only attach to a broker through server proxy
Weakness
Many weaknesses can happen to a broker such as:
It may be a target for a security attack
It may be a single point of failure
It may be difficult to test
The pattern provides all modifiability and availability benefits because it is very easy to replace a failed server with another. Performance is also one of the quality features of this pattern because the broker pattern easily assigns works to the least active server. The service-oriented architecture depends on this type of pattern, most commonly in the form of an enterprise service.
An example of the broker pattern is CORBA, for cooperation among heterogeneous systems and web services.
client
Proxy in the side of client
Broker
Proxy in the server side
Server
Notation for broker design
• Model-View-Controller Pattern
In the model-view-controller pattern, or MVC pattern, an interactive application consists of three parts: the model contains the core functionality and data, the view displays the information to the user, and the controller is responsible of the input from the user. The MVC pattern is particularly suitable for multiple graphical user interfaces (GUIs).
The MVC pattern
Context User interface software is the most modified part in the user interface that is why it is important to keep this part separate from other systems
Problem The idea is how to keep the functionality of this part (interface) from the rest of the application. Also how multiple views can appear to the user when the underlying data change
4 Achieving Quality Attribute
Solution This pattern separates the functionality of the application into three main parts: Model which is the brain of the parts that contains the business rules and the application data
View which is the user interface that is displayed on the screen Control which communicates between the user and the model The MVC solution pattern
Overview
This pattern splits the functionality of the system into three parts: model, view, and control
Elements
The model is a representation of the application data as well as the application logic The view is the user interface part in the system
The controller manages the interaction between the previous elements Relations
The notifies relation connects between instances of three parts Constraints There must be at least one instance for each element
Weakness
MVC is not appropriate for every situation; it may be costly and that is not appropriate for simple user interface. Also the MVC parts may not fit to the user interface toolkit
Model
Controller
View
Notation for MVC design
Because these components are loosely coupled, it is very easy to develop and test them in parallel, and any change to one component has the minimal effect on the others.
Usability, changeability, and testability are important qualities in this type of pattern.
Learning unit on patterns for enterprise application architecture is an example to this pattern.
• Pipe and Filter Pattern
The pipe-filter architectural pattern produces a structure for systems that generate a stream of data. The flow of data is driven by data, and the whole system is decomposed into components of data source, filters, and pipes (the arrows between adjacent filters and data sinks). The connections between modules are streams of data which is first-in/first-out buffer that can be streams of bytes, characters, or any other type.
57
Pipe and filter pattern
Context Many systems are required to transform streams of discrete data items, from input to output. Many types of transformations happen continually in practice, and so it is desirable to produce these parts as independent and reusable parts Problem These systems have to be divided into reusable and loosely coupled components with simple interaction between them. The components, being generic and loosely coupled, are easily reused. The components, being independent, can execute in parallel Solution The pipe-and-filter pattern is characterized by successive transformations of streams of data. Data arrives at a filter’s input port(s) is transformed and then is passed via its output port(s) through a pipe to the next filter. A single filter can consume data from, or produce data to, one or more ports
Pipe and filter solution pattern
Overview
Data is transformed through a series of transformations performed by its filters connected by pipes
Elements
Filter, which is independently executing components
Pipe, which is a connector between filters. A pipe preserves the sequence of data items, and does not alter the data passing through
Relations
The attachment relation associates the output of filters with the input of pipes and vice versa
Constraints Connected filters must agree on the type of data being passed along the connecting pipe
Weakness
It is not a good choice for interactive systems
It is not appropriate for long-running computations without the addition of some check point/restore functionality
source
filter
filter
sink
Notation for pipe and filter design
The main objective of this approach is to achieve the qualities of reuse and modifiability.
An important example of the pipe-filter pattern is compiler, where a lexical analyzer analyzes the source file and then sends the resulting tokens to a parser, which sends the resulting parse tree to a semantic analyzer, which produces an augmented syntax tree, that is used by the code generator to produce code, which may be opti-mized, and ultimately translated into machine code.
• Client-Server
A client-server pattern consists of two main components: server component, which supplies services to many components of the clients, and a client component, which requests services from the server component. Servers are active, listening for clients.
4 Achieving Quality Attribute
Client-server pattern
Context Shared resources and services are accessed by a large number of distributed clients to access the quality of services
Problem Managing a set of shared resources and services, modifiability and reuse can be supported, and this is done by factoring out common services and having to modify them in a single location or a small number of locations. Scalabilit y and availability need to be improved by centralizing the control of these resources and services, while these resources are distributed across multiple physical servers
Solution Clients and servers are interacting by requesting services from clients of servers, while the latter provide a set of services. Some components may act as both clients and servers. There may be one central server or multiple distributed ones Client-server solution pattern
Overview
Clients initiate interactions with servers by sending requests to these servers and waiting for the results of these requests
Elements
Client: a component that invokes services of a server
Server: a component the provides services to the client
Relations
The attachment relation connects between the client and server Constraints Clients are connected to servers through connectors
Servers can be clients to other servers
Components of clients and servers may be formed as layers; clients form the higher level, and servers form the lower level
Weakness
The server can be the performance bottleneck
The server can be a single point of failure
It is costly to change decisions after a system has been built
Modifiability and reusability are qualities that are supported by this type of pattern. Scalability and availability qualities can be improved by centralizing the control of these resources and services.
Client
TCP/IP
server
Notation for client-server design
59
• Service-Oriented Architecture (SOA) Pattern
The service-oriented architecture is an architectural design which includes a collection of services in a network which communicate with each other. The service is a kind of operation which is well defined and self-contained and provides separate functionality such as checking customer account details and does not depend on the state of other services.
Service-oriented architecture pattern
Context A number of services are provided and consumed by the service provider and the service consumer, respectively. The service consumer needs to understand and use these services without any detailed knowledge of their implementation Problem The main idea here is how to support interoperability between components running on different platforms and written in different programming languages, provided by different organizations, and distributed across the internet
Solution The service-oriented architecture (SOA) pattern describes a collection of distributed components that provide and/or consume services. These components can use different programming languages and different platforms, and they are usually deployed independently
SOA pattern solution
Overview
Computation is achieved by a set of collaborating components that provide and/or consume services over a network
Elements
Service provider: This provides one or more services
Service consumer: This invokes services directly or through an intermediary Enterprise service bus: An intermediary element that transports messages between service provider and service components
Registry of services: This element is used by the service provider to register the services and by service consumers to discover services at runtime Orchestration server: Coordinates the interactions between service consumers and providers in SOA system
Connectors: Such as SOAP (the standard protocol for communication in the web service technology), REST (representational state transfer), and asynchronous messaging
Relations
The attachment relation connects between different kinds of components Constraints The intermediary components (ESB, registry, orchestration) may be used through connections between service consumers and service providers
Weakness
It is complex to build
The evolution of independent services is not controlled
Because of the shared services between servers and clients, the middleware may act as a performance bottleneck
60
4 Achieving Quality Attribute
Service request
Service provide
Message
Message
provider
consumer
Notation for service-oriented design
Microservices are a modern interpretation of SOA used to build distributed software systems. Services in microservice architecture are processes that communicate with each other over the network in order to reach a goal.
Patterns in the allocation structure are:
• Multi-tier Pattern
In a Multi-tier pattern, tiers can be created to group components of similar functionality, in which case it is a C&C pattern. The reason that makes it an allocation pattern is that the client tier in an enterprise system maps software elements to computing elements because they are not running on the computer that hosts the database.
Multi-tier pattern
Context The infrastructure of the system needs to be distributed into distinct subsets; for example, different parts of infrastructure may belong to different organizations Problem How the system can be split into groups of software and hardware that communicate by some communications media
Solution The system is organized as a set of logical grouping of components, and this is done on criteria such as sharing the same execution environment
Multi-tier pattern solution
Overview
The system is organized as a set of logical grouping of components termed tiers, and this is done on criteria such as sharing the same execution environment Elements
Tier, which is a logical grouping of software components
Relations
Is part of, to group components into tiers
Communicates with, to show how tiers and components they contain interact with each other
Allocated to, in the case that tiers map to computing platforms Constraints A software component belongs to exactly one tier
Weakness
Cost and complexity
4.2 Architectural Pattern
61
Data Tier
Business Tier
Client Tier
Business Logic
database
Multi-tier notation
Two important things must be known on tiers:
• Tiers themselves are not components but are logical groupings of components.
• Tiers are not layers; layering is a pattern of modules, while tiers apply to runtime only.
• Publish-subscribe Pattern
In this pattern, a number of independent producers and consumers of data interact, and because of that the publisher “produces” the messages without knowing the consumer identities (here called subscribers), and similarly, the subscribers receive messages that are of their interest without knowing the publisher identity.
The pattern here is:
Context A number of independent producers and consumers of data interact. The accurate number of the data producers and consumers is not fixed
Problem How can we create a mechanism for communicating the producers and consumers of data?
Solution In this pattern, components interact through messages or events. Components may subscribe to a set of events. Publisher components put events on the bus by announcing them; the connector then delivers those events to the subscriber components that have recorded their interests in those events. Any component may be both a publisher and a subscriber
4 Achieving Quality Attribute
The solution pattern of the publish-subscribe
Overview
The components are produce (publish) and consume (subscribe) to events; once the events are announced by the components, then the connector infrastructure dispatches the event to all registered subscribers
Elements
Publisher ( sender) : Application that tags each message with the name of topic Subscriber ( receiver) : Application that chooses the interesting topic The publish-subscribe connector, which will have announce and listen roles for components that wish to publish and subscribe to events
Relations
Attachment relation that connects components (publisher/subscriber) with the publish-subscribe connector
Constraints All components are connected to an event distributor that may be viewed as either a connector or a component
Weakness
Scalability is affected negatively through increasing latency
This pattern suffers in controlling over ordering messages, and delivery of messages is not guaranteed. This is why this pattern is not suitable for complex interactions
Subscriber 1
Terminal A
Publisher
Subscriber 2
Terminal B
Subscriber 3
Publish-subscribe notation
Patterns address multiple quality attributes. Patterns give pluses to some qualities and minuses to others. A good example is MVC application; the view components are notified when the state of model of the object changed. This pattern is highly modifiable.
The benefits of patterns in general are:
• Patterns are always built to address a recurring problem that arises in a specific design situation.
• Patterns provide common vocabulary and understanding to design principles such as the name of the pattern.
4.3 Tactics and Quality Attributes
63
• Patterns are means of documenting software architecture.
• Patterns help build and manage complex and heterogeneous software architecture.
Pattern systems bind individual patterns together. It describes how the basic patterns are connected with other patterns in the system, how these patterns can be implemented, and how software development with patterns is supported. A pattern system is a dominant mean for constructing software architectures.
In general, patterns differ in scale and abstraction because various ranges of scale are applied at different levels of abstraction; this is why they are classified as:
• Architectural pattern: a set of architectural elements, their responsibilities, rules, and guidelines for organizing the relationships between the elements.
• Design pattern: a recurring structure of communicating elements that solves a general design problem within a particular context.
• Idioms: are patterns specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them.
The three main architectural concepts that are used in this section are architectural structure, architectural pattern, and architectural style. Although these terms are used interchangeably in most books and papers, there is a little difference between them:
• Architectural structure is a set of elements and the relations among them. Three categories of structures are represented here: module, component and connector, and allocation structures.
• Architectural pattern is described in three main dimensions: context, problem, and solution.
• Architectural style is the representation of the architecture in terms of the pattern of organizational structure. It establishes the meaning of components and the relation that is used in the pattern, the constraints on the communication of the parts, and the weaknesses of using such type of style.
In Clements et al. (2011), you can find the difference between an architectural pattern and an architectural style. It argues that a pattern is a context-problem-solution triple and a style is simply a condensation that focuses most heavily on the solution part.
4.3 Tactics and Quality Attributes
Quality attributes are the most important part that the architect focuses on through building the system to get the stakeholder’s confidence. On the other hand, stakeholders always focus on the quality through working with the system. All that will
4 Achieving Quality Attribute
make the quality the major part of the architect’s work. This section will present the technique that an architect can use to achieve the required quality attributes; it is called architectural tactic. I will define the meaning of architectural tactic and then describe how this technique can help to achieve the specific quality. The relation between pattern and tactics will be described as well.
4.3.1 Achieving Quality Through Tactics
Architectural tactic is a design decision that influences the achievement of quality attribute response, and this makes the architectural tactic a means of satisfying quality attribute measure.
When designing the system that consists of a set of design decisions, we must know that some of these decisions achieve the functionality part of the system and other decisions help control the quality control responses. The relationship between
stimulus, tactics, and response is represented in Fig. 4.2.
The important thing to know is that the focus of the tactic is on a single quality attribute response; unlike patterns, they address many quality attributes. The other important thing is that within tactic, there is no consideration to the trade-offs which makes it different from patterns (Fig. 4.3).
Now, given the usability quality as an example, you will see the following tactics
Usability tactics 1:
Support user initiative: usability is giving the user feedback for what the system is doing once the system is executing to allow the user to give the appropriate response. The tactics for that are:
• Cancel: the system must listen for the cancel request; the command being canceled must be terminated; resources used must be free; and collaborating components must be informed.
• Pause/resume: effectively pausing a long-running operation will temporarily free resources so that they may be reallocated to other tasks.
• Undo: maintain enough information about system state so that an earlier state may be restored, at the user’s request.
Tactics to control responses
stimulus
response
Fig. 4.2 Relationship between tactic, stimulus, and response
4.3 Tactics and Quality Attributes
65
User given
User request
USABILITY TACTICS
feedback and
assistance
System
attack
Security tactics
detectcts
,recover from
attack
Response
Event arrive
Performance attack
must be within
a specified
time
Fig. 4.3 Tactics classified by quality attributes
undo
cancel
……...
User initiative support
Usability tactics
System initiative support
Maintain
Maintain
……...
Task model
user model
Fig. 4.4 Tactics for usability
4 Achieving Quality Attribute
• Aggregate: ability to aggregate lower-level objects into a group, so that a user operation may be applied to the group, and this is done through performing repetitive operations or operations that affect huge amounts of objects in the same way.
Usability tactics 2:
Support system initiative: the task must be either undertaken by the user or the system state itself.
• Maintain task model: the system can have some idea of what the user is attempt-ing and provide assistance. For example, capital letter in the middle of the sentence must convert to small letter.
• Maintain user model: the user’s behavior, in terms of expected response time, represents the user’s knowledge of the system, for example, user interface customization for individual users.
• Maintain system model: it is used to determine the expected system behavior, so that suitable feedback can be given to the user, for example, system progress bar.
Note The goal of the usability tactic is that after request it by user, the suitable feedback and assistance must be provided.
Tactics can be the way to satisfy quality attribute response measure; this is done through many ways. The first way is done by manipulating some aspect of a quality attribute model through architectural design decisions. Some quality attributes like performance and availability have well understood such type of models. In such types of qualities, the ideal tactic processes are:
1. Begin with the analytical model for that quality.
2. Identify the parameters of that model.
3. Identify architectural techniques to manipulate the parameters of the model.
Analytic model is a set of equations describing the performance of a computer system. Practically, it describes a collection of measured and calculated behaviors of different elements over a finite period of time.
For example, the queuing model for the performance is represented in Fig. 4.5.
The request arrives, it is put in the queue and then served by the server, so latency (time to compute the result) can change one of the parameters of this model.
The parameters that can be seen in the model are:
• Arrival rate
• The queue
• Scheduling algorithm
• Service time
• Topology
4.3 Tactics and Quality Attributes
67
Queue
Routing of
Arrivals
Scheduling
Algorithm
Messages
Results
Server
Fig. 4.5 Queuing model for performance quality
• Network bandwidth
The queuing discipline can be affected by first come first service (FCFS). The important thing to know is that not all qualities have analytic models. Checklist and thought experiments exist to guide the architect when making the design decisions.
Quality attribute checklists can come from government organizations or from private organization or it can come from industry consortia. For example, there is a security checklist for the financial industry.
On the other hand a thought experiment is the kind of discussions that occur between the developers and architects daily in the offices or any kind of meeting.
The purpose of this kind of meeting is to find confirmation to the nonexistent problems in the quality attribute requirement.
Models and checklists focus on one quality attribute, while thought experiments consider many quality attributes simultaneously and focus on the most important ones.
Depending on the project’s state of development, different forms of analysis are possible, each type of analysis associated with its own cost and level of confidence.
You will see the tactics of other qualities in Chaps. 7 and 8.
4.3.2 The Relationship Between Tactics and Patterns
As said before, every pattern deals with many qualities, while tactic deals with a specific type of qualities such as modifiability, availability, etc. The important thing to know is that most patterns consist of several different types of tactics that serve a common purpose. For example, choosing a particular tactic to make an availability pattern more secure or applying a performance tactic on a modifiability pattern.
4 Achieving Quality Attribute
For example, the layer pattern can be seen as a mixture of several tactics as increased semantic cohesion, restrict dependencies, and encapsulation. As with increased semantic cohesion, the goal of ensuring that layer’s responsibilities all work together is achieved only through choosing responsibilities that have semantic cohesion; for example, responsibilities that deal with hardware must be allocated to a hardware layer not in an application layer.
4.4 Business Pattern
A business pattern is a generalized solution to a common business problem. So to present the architecture of the business you work on, you need pattern in your description because it reflects common solutions to common problems. This definition makes sense that the concept of pattern is same everywhere.
Another definition of business pattern comes from Microsoft: “a reusable approach to the solution of particular business problems, the offered solutions are according on previous success in defining the same solutions. A business pattern can represent a template for a business solution.” The term “reusable” in this definition explains the importance of pattern in the business context.
It takes considerable effort to change from one business pattern to another.
Companies should know the various business patterns and how they can benefit from applying them. By recognizing the various available business patterns, it is possible to solve existing business problems within an enterprise or enable the identification of opportunities to create a significant competitive advantage. A business pattern is characterized by being structural, reusable, proven and lastly as making business sense.
4.4.1 Pattern for Enterprises
Layering technique is one of the most common things that software designers use to break a complicated software system into parts. The class book titled Patterns of Enterprise Application Architecture by Martin Fowler describes set of patterns grouped by layers that form such systems.
Enterprise application is about using a layer structure to present, manipulate, and store large amount of data with a business process that support these data. Such types of applications are financial system and reservation system.
This section is about describing layers of enterprise systems (in an abstract way).
Three principle layers are presentation, domain, and data source layers.
• Presentation layer: is responsible for handling the communication between user and software.
• Domain logic also called (business logic): this is the work that the application needs to do for the domain you are working with. This layer is the real point of the system.
4.5 Importance of Patterns in Business
69
• Data source laye r: for most enterprise applications, the biggest piece of data source logic is a database that is primarily responsible for storing persistent data.
In the domain logic, three patterns are described transaction script, domain model, and table module:
• A transaction script is a procedure that takes the input from the presentation, processes it, stores data in the database, and invokes any operations from other systems. It then replies with more data to the presentation. Book a hotel room and booking for a certain day are two examples on transaction script. The main advantage of a transaction script is that it is suitable for a small and simple application. On the other hand, the disadvantage arises when a system gets larger and the business logic gets more complex, and then code duplication between scripts increases.
• Domain model deals with more complex systems when dealing with objects.
Rather than one routine having all the logic for a user action, each object takes a part of the logic that is relevant to it. A simple domain model looks very much like the database design with mostly one domain object for each database table.
• Table module: here, a single instance will handle the business logic for all rows in a database table or view. A table module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with domain model is that, if you have many orders, a domain model will have one object per order, while a table module will have one object to handle all orders.
One benefit of using layering technique is that you can understand the layer itself as a stand-alone coherent layer without having to know about other layers. Also layers are a good way to standardization.
Layers also have disadvantages. For example, in the encapsulation features of the layer (encapsulation hides some but not everything), any new field in the presentation part must be added into database part and any other layers in between them.
Another disadvantage of layers is that by adding many layers, this will harm the performance. The hardest part is to know what layer to have and also deciding the pattern in the layer according to the complexity of the system.
4.5 Importance of Patterns in Business
What is the benefit of pattern in business? Or why does business follow patterns?
• At the most abstract level, all businesses (or “enterprises”) have the same pattern.
• Businesses in the same industry share common external influences, internal influences, and goals.
70
4 Achieving Quality Attribute
• At the view of improving the design of business, patterns support the reuse feature. This feature has the important benefit of reducing implementation and will lower the costs of maintenance.
• The reuse feature at the more abstract level can enable interoperability between systems that follow patterns.
4.6 The SEI Attribute-Driven Design (ADD) Method
ADD (attribute-driven design) is a method that was developed at SEI to define and design software architecture in which the design process is based on the software’s quality attribute requirements. ADD essentially follows a “Plan, Do, Check, and Act” cycle:
• In the Plan phase: Quality attributes and design constraints are considered to select which types of elements will be used in the architecture.
• In the Do phase: Elements are instantiated to satisfy quality attribute requirements as well as functional requirements.
• In the Check phase: The resulting design is analyzed to determine if the requirements are met.
• In the Act phase: you should act upon the feedback received from the check phase process.
This process is repeated until all architecturally significant requirements are met.
The input for the ADD process is the set of requirements for the project, which contains functional requirements, quality attribute requirements, and design constraints. Also you should know the purpose of the design, for example, to produce a design for early estimation or to design and generate a prototype, etc. The requirements should be described in detail to check if they can be met with the architecture.
ADD version 3 is created to address the weakness of the previous versions. The steps of ADD are:
4.6 The SEI Attribute-Driven Design (ADD) Method 71
Step 1: review inputs
First, the purpose of the design must be clearly defined, and all the drivers of the architecture must be described. At this point, the primary functionality and quality attribute scenarios have been prioritized, ideally done by the most important project stakeholders. Prioritization can be done by techniques described previously. The architect must own all these drivers.
These drivers drive the design, so getting them right and prioritizing them are very important.
Architecture drivers are the questions that arise through building the architecture and these questions categorized as what and why questions. Architectural drivers include design purpose, quality attributes, primary functions and constraints, and architectural concerns (additional concerns to the architecture).
Step 2: establish the iteration goal by selecting drivers
A design round is performed in a series of design iterations; each iteration focuses on achieving a specific goal. Such a goal typically involves deigning to satisfy a subset of the drivers, for example, creating a structure from elements to support a specific scenario for performance.
Step 3: choose one or more elements to refine
Refinement can mean decomposing the elements of the architectural structure either top down or bottom up or it can mean improvement of the previously identified elements. In order to satisfy the drivers of the architecture, you do need to refine the elements of the structure that are identified in the previous iteration.
The elements that you will select are the ones that are engaged in satisfying of the specific drivers. That is why you should understand of such elements.
Step 4: choose one or more design concepts that satisfy the selected drivers Choosing the design concepts is the most difficult decision in the design process.
This is because you need to identify alternatives among design concepts that can be used to achieve the goal of the iteration and to make the selection of these alternatives. The term design concepts is used through the design process; they are building blocks that are used to build the structure of the architecture.
Step 5: instantiate architectural elements, allocate responsibilities, and define interfaces
After defining the design concept in the previous step, you need to make another design decision, which requires instantiating elements of the design concepts that you selected. For example, if you select the layer pattern as a design concept, then you must decide how many layers will be used, then allocate the responsibility of each layer, and then define the interfaces.
Another example is a typical web-based enterprise system: at least three important layers are presented: the presentation layer, the business layer, and the data layer. Each of these layers has a different responsibility; the responsibility of the
4 Achieving Quality Attribute
Drivers
Review Input
Establish Iteration Goal by Selecting Drivers
Choose One or More Elements to Refine
Choose One or More Design Concepts That Satisfy the
Selected Drriver
Instantiate Architectural Elements, Allocate Responsibilities
and Define Interfaces
Sketch Views and Record Design Decisions
Perform Analysis of Current Design and Review Iteration Goal and
Achievement of Design Process
Refine the
Architecture
Fig. 4.6 Attribute-driven design steps
73
presentation layer includes managing the interaction of users, while the responsibility of the data layer includes managing the persistent data.
Step 6: sketch views and record design decisions
After finishing performing the design activities for the iteration, this step is about to sketch the views (the representations of the structure that are created previously), but the views that are created are most of the time incomplete. So all the diagrams that are created have be to refined later in subsequent iteration. You must know that these created sketches are the beginning of the documentation. In addition to sketch-ing the views, recording significant decisions that are made in the specified iteration is also important.
Step 7: perform an analysis of the current design and review iteration goals and achievement of design purpose
In this step, a specific design that addresses the goal must be created for the iteration to avoid an unhappy stakeholder, so once the design is formed in the iteration, it needs to be analyzed by another person or team because having someone with a different view is important to find bugs in both code and architecture. After that, you should review the state of the architecture you built in order to see it if it establishes the purpose of the design.
Step 8: iterate if necessary
You should perform additional iterations for every driver that considers being part of the input. The highest driver priorities should be addressed. Also critical drivers should be satisfied or at least the created design should satisfy them.
The drivers in Fig. 4.6 are design purpose, functional requirement, quality attributes scenario, constraints, and architecture concerns.
4.7 Summary
Architectural pattern introduces a relationship between context, problem, and solution, and this will form the template for documenting that pattern. Complex systems exhibit multiple patterns at once.
Pattern can be categorized by the dominate type of elements as:
• Module pattern
• Component-and-connector pattern
• Allocation pattern
Patterns employed in architecture help us expect which properties will be displayed by architecture. Tactics are fundamental design decisions that influence the responses of the quality attribute; they are the “building blocks” of design from which patterns are created. Most patterns consist of several different tactics.
4 Achieving Quality Attribute
The three main architectural concepts that are used in this section are architectural structure, architectural pattern, and architectural style. Although these terms are used interchangeably in most books and papers, there is a little difference between them:
• Architectural structure is a set of elements and the relations among them. Three categories of structures are represented here: module, component and connector, and allocation structures.
• Architectural pattern is described in three main dimensions: context, problem, and solution.
• Architectural style is the representation of the architecture in terms of the pattern of organizational structure. It establishes the meaning of components and the relation that is used in the pattern, the constraints on the communication of the parts, and the weaknesses of using such type of style.
In Clements et al. (2011), you can find the difference between an architectural pattern and an architectural style: a pattern is a context-problem-solution triple, while a style is simply a condensation that focuses mainly on the solution part.
Moving the definition of pattern to the business, the concept of business pattern arises. It can be defined as a solution to common business problems in any enterprise. The importance of business pattern can be described in the following:
• At the most abstract level, all businesses (or “enterprises”) have the same pattern.
• Businesses in the same industry share common external influences, internal influences, and goals.
• At the view of improving the design of business, patterns support the reuse feature. This feature has the important benefit of reducing implementation and will lower the costs of maintenance.
• The reuse feature at the more abstract level can enable interoperability between systems that follow patterns.
ADD (attribute-driven design) is a method that was developed at the SEI decomposition process to define and design a software architecture in which the design process is based on the software’s quality attribute requirements.
References
L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 3rd edn. (2013) United States H. Cervants, R. Kazman, Designing Software Architectures: A Practical Approach (Addison-Wesley, 2016)
M. Fowler, Pattern of Enterprise Application Architecture (Addison-Wesely, 2003) P. Teale, Business Patterns for Software Engineering Use (Microsoft Corporation, Robert Jarvis SA Ltd, 2004)
75
Further Reading
F. Bachmann, L. Bass, R. Nord, Modifiability Tactic, Technical report CMU/SEI (John Wiley & Sons Ltd, 2007) Chichester, West Sussex, England
J. Bosch, Software Architecture: The Next Step, University of Groningen, Department of Computing. LNCS 3047 (Springer, Berlin Heidelberg, 2004), pp. 194–199
F. Buchman, K. Hennery, D. Schmidt, Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing (Wiley, 2007)
I. Gorton, Essential Software Architecture, 2nd edn. (Springer-Verlag, 2011) Berlin, Heidelberg T. Graves, Everyday Enterprise Architecture: Sensemaking, Strategy, Structures and Solutions (Tetradian Books, 2010). http://www.tetradianbooks.com
N. Harrison, P. Avgeriou, How do architecture patterns and tactics interact? A model and annota-tion. J. Syst. Softw. 83, 1735–1758 (2010). http://www.elsevier.com/locate/jss
S. Kim, Dae-Kyoo Kim, et al., Quality-driven architecture development using architectural tactics.
J. Syst. Softw. 82, 1211–1231 (2009)
A. Moore, L. Bass, M. Klein, F. Bachmann, Security and Survivability Reasoning Frameworks and Architectural Design Tactics, Technical note (2004)
M. Richards, Software Architecture Patterns: Understanding Common Architecture Patterns and When to Use Them (O’Reilly Media, Inc, 2015) Sebastopol, CA A. Sharmaa, M. Kumarb, S. Agarwal, A Complete Survey on Software Architectural Styles and Patterns.4th International Conference on Eco-friendly Computing and Communication Systems, ICECCS, 2015 (Elsevier, 2015)
Chapter 5
Managing Business Qualities
Abstract Business quality is a non-software system quality that influences other types of qualities in the system. This type of quality is very important because it is taken from the market’s point of view. This chapter is going through this type of quality and its goals (business goals). Business goals must be specific, measurable, attainable, realistic, and time bound.
Stakeholders of the system and their relations to business goals will be described in this chapter. Also the approach that shapes the relation between the organization and the stakeholder will be shown.
To enhance the quality of the software, many companies use an approach called software process improvement. This approach can reduce cost or increase their development process through it. It is a way to understand the existing process and then changing it to increase the quality of the product and/or reduce the time of development and cost. This approach will be described in this chapter.
In brief, at the end of this chapter, you will learn:
• The meaning of business qualities and business goals and the main qualities in the business
• The meaning of stakeholders, their types, and their roles in achieving the goals
• The meaning of TQM and its main principles
• The process improvement and its life cycle
5.1 Business Quality Definition
This chapter will focus on a new type of quality, the business quality, which guides the architect to build high-quality architecture. This type of qualities leads to the business goals. The important thing to know is that ASR, previously defined, is related mainly to business goals, and when an architect understands the desired qualities before building the system, then the right architecture will be created.
© Springer Nature Switzerland AG 2020
77
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_5
5 Managing Business Qualities
Business quality can be defined as a non-software system quality that influences other types of qualities. Business qualities are important qualities because they are taken from the market’s point of view. Goals of such types of qualities are centered on the following:
1. Cost and time to market: the budget of the developing system is a very important consideration which must be taken into account through building any system, and of course, the cost is different from system to system. The system that is built to be highly flexible will be more costly than rigid systems. The cost of the system must be with respect to the time to market, and the latter can be achieved by using pre-built elements such as commercial off the shelf (COTS) or the elements that are reused from previous projects.
2. Marketability: building the system with respect to the market competition.
Portability and functionality are two important features that share mass market.
When talking about mass market, product line approach will be considered, and this will be explained in detail in Chap. 6.
Mass markets are products and services that are needed by almost every member of society.
Also when talking about marketability, the most useful quality business is that it will be fit to its purpose and meet the business user’s requirements system. The quality assurance team will then validate the processes, systems, and services.
3. Standardization: manufactures use standards and process improvement methodologies to improve the process and then the product, so here the quality is compliance to the best known standards.
4. The schedule time of building the system: building a system according to the scheduled time is a very important quality in the business point of view, because adding any extra features will usually compromise time to market.
5.2 Business Goals
Business goals are the basic part for building any system. Every architect is interested in business goals. Such goals start with the vision and mission of the company to structure the system. It must be SMART (specific, measurable, attainable, realistic, and time bound). Profit is a common example for the business goals despite the fact that profit is not always the main concern to some organization because they have other concerns in mind. Another example of the business goal is the customer service goals; one of the important goals here is how to reduce the response time in the customer service and improve satisfactions to the customer.
79
Table 5.1 Categories of
1
Contributing to the expansion and
business goal
continuity of the organization
2
Meeting financial goals
3
Meeting personal objectives
4
Meeting responsibility to employees
5
Meeting responsibility to society
6
Meeting responsibility to shareholders
7
Meeting responsibility to states
8
Managing market position
9
Improving business process
10 Managing the quality and reputation of
products
11 Managing change in environmental
factors
Table 5.1 represents the main categories for business goals; they help brain storming and elicitation techniques.
1. Contributing the expansion and continuity of the organization This category discusses how the system being developed contributes to the growth and continuity of the organization. Product lines come up in this category.
2. Meeting financial goals
Profits from systems, costs of developing and deploying the system, and any financial objectives of individuals, for example, managers hoping for a raise.
3. Meeting personal objectives
This category is interested with the goals of individuals that are associated with the construction of the system.
4. Meeting responsibility to employee
Responsibilities for employees involved in development may include a certain type of employees, for example, learning new skills. Another example of responsibilities is when employees operate the system; here, safety, workload, or other things that are related to the system’s work will be considered.
5. Meeting responsibility to society
Some organization serve society; the system under development helps them meet these responsibilities and also ethics; security are under this type of category.
6. Meeting responsibility to state
Government systems are planned to meet the responsibilities to a state or country. Supporting government plans and dealing with the export control are under this type of category.
7. Meeting responsibility to shareholders
There is an overlap between this category and the second one. Shareholders can be defined as any person, company, or institution that owns at least one
5 Managing Business Qualities
share of a company’s stock, also called stockholders. Shareholders are always stakeholders in a corporation but not every stakeholder is shareholder.
8. Managing market position
Strategies that are used to hold or increase the market’s share or time to market are under this category.
9. Improving business process
Improving business process may overlap with financial objectives, dealing with the new market or improving the way to support customers.
10. Managing the quality and reputation of the product
Branding of the product, qualities of existing products, and testing strategies.
11.
Managing change in environment factors
Business context for any system may change this. Encourage stakeholders to consider what the change in the business goals is.
A better way to express business goals is through scenarios. The template of this scenario has seven parts, all related to the system under development. The parts are abbreviated in Table 5.2.
Note If you want to express the business goal scenario, you say: For systems to be developed, the goal subject desires the goal object to achieve the goal in the context of environments and will be satisfied if the goal measured.
PALM (Pedigree Attribute eLicitation Method) is a method used to capture business goals and then document them. Pedigree means that a business goal has a clear derivation or background. PALM consists of seven steps between the architect and the stakeholders, done through a workshop which normally take a day and a half. These steps are:
• PALM overview presentation
• Business drivers presentation
• Architecture drivers presentation
• Business goals elicitation
• Identification of potential quality attributes from business goals
• Assignment of pedigree to existing quality attribute drivers
• Exercise conclusion
Table 5.2 Business goal scenario
Goal source
The source of the goal are people or written artifacts
Goal subject
Stakeholders own the goal and wish it to be true. Stakeholders might be individuals or organizations
Goal object
The entities to which the goal applies, for example, the goal object is developing the organization
Environment
The context of the goal, such as the social environment and customers Goal
This is a business goal
Goal measure
A testable measurement to help achieve the goal
Pedigree and
The degree of confidence of the person who states the goal
value
81
PALM can be used to find the missing quality attribute requirements early in the life cycle and to notify the architect of business goals that directly affect the architecture without needing to quickly find new requirements. PALM can also be used to examine difficult requirements, and finally, because of the different overview of the stakeholders, this method provides the environment for capturing goals to be broadcast and resolved.
Finally, capturing business goals is very important because they will be the key to ASRs that emerge in no other context and they also derive the architecture.
Paul Clements, John McGregor, and Len Bass applied PALM to a system being developed by Boeing’s air traffic management; they call the system TSUC (the system under consideration). This system provides on-line services to the airline companies to help improving efficiency. Two classes for this system of stakeholders: Boeing and airline companies. This exercise helps chief architect and project managers, who previously applied PALM, see the same vision of the TSUC. Some of the uncovered goals through PALM were:
• The possibility of using TSUC in the future
• Impact of this system on both, users and developers
The result is that the categories of business goals must capture the business goals that are relevant to TSUC.
5.2.1 The Role of the Architect in Achieving the Quality
Every architect knows that its role extends from technical activities to being consul-tants. The important thing in business and strategy is predicting the right architectural approach to the customer’s problem. This is why the architect has to be a good listener to the concerns and goals of the stakeholders.
The main principle that declares that it is the role of the architect to achieve the qualities that the stakeholder needs is that the architect is responsible for designing, documenting, and leading the construction of a system. Four main aspects to this role are:
• Identifying and engaging the stakeholders
• Understanding and capturing the concerns of the stakeholders
• Creating and defining architecture that deals with these concerns
• Taking a leading role in the realization of the architecture into system A concern about architecture is a requirement, an objective, an intention, or an aspiration a stakeholder has for that architecture.
5 Managing Business Qualities
Every problem has a number of possible architectural solutions; the architect must select an architecture that is fit for purpose and then document that architecture in an appropriate way. The architect also acts as a mentor working with developers to tackle any challenges that arise. In fact, the architect is involved through the life cycle of software development.
5.3 Definition of Total Quality Management (TQM)
All the definitions of TQM concentrate on reaching high qualities for the products to satisfy the requirements of the customers. It is hard for a company that aims to compete effectively to ignore the use of the concept of TQM. It is for this reason that businesses should not ignore implementing principles of TQM. Hence, total quality management can be defined as integrated efforts to prevent possibilities of errors and improve quality performance at every level of the organization to reach the optimal customer satisfaction. The customer satisfaction is achieved through efficiency and the effectiveness that prevents defects.
The philosophy of TQM began as a result of dramatic changes in the business environment. The customers are usually the basis of any business, whether the business is in the service industry or the manufacturing industry. Customers would always seek for quality in order to be satisfied, but when it comes to the service industry, customers become important and sensitive part compared to the manufacturing industry because the interaction between customers and the companies occurs in the frontline of the company.
The differences between the most important sectors in the business (manufacturing and service organizations) are as follows: in manufacturing, the product is a tangible; it is touchable and can be directly measured, such as clothes and CDs.
Thus, the quality in manufacturing is focused on the features of these tangible products such as reliability, performance, etc. On the other hand, in the service organizations sector, the products are intangible, such as health care and learning at a university (i.e., the final product cannot be seen or touched). The quality of such type of products is focused on consistency (the degree to which all the services are the same at all times), responsiveness to customer needs, etc. Both sectors must satisfy the customer’s requirements.
Benefits of TQM for customers can be shown through quality improvement, design, and service of the product and also in increasing the acceptance of the product in the marketplace. The benefits are also shown economically through reduction of operating costs, field service costs, operating losses, etc.
TQM attempts to embed quality in every aspect of the organization. It is concerned with technical aspects of quality as well as the involvement of people in quality.
5.3 Definition of Total Quality Management (TQM) 83
Table 5.3 Main principles for TQM
Customer focus
The main objective is to identify the customer’s needs
Continuous
The main idea is continuous development
improvement
Employee
Employees are always seeking out qualities, identifying them, and empowerment
correcting their problems
Use of quality tools
Continuously training the employees to use the quality tool
Product design
Designing products to meet the customer’s needs
Process management
Qualities should also be designed in the process
Managing supplier
The concept of the quality must be included in the company’s suppliers quality
5.3.1 Principles of TQM
TQM embeds quality in each part of the organization; dealing with quality management systems not only allows businesses to react to the business changes but also to impose them by controlling the future. There are many principles related to TQM; the ones mentioned here are the ones in the book of operations management.
Managers must understand the following principles to improve the competitiveness of their organizations. The main principles of TQM are shown in Table 5.3.
5.3.1.1 Customer Focus
The goal here is to identify and then meet the customer’s needs, and that is because the quality is customer driven. This can be achieved by communicating with the customers in an organized frame, by involving the customer in the developing process for the product he requires, etc. Companies always need to continue gathering information by means of market surveys and customer interviews in order to stay focused on what customers want.
5.3.1.2 Continuous Improvement
This is a very important principle that most experts consider. Continuous improvement, from the Japanese point of view, is a philosophy of a never-ending process.
The performance must always be evaluated, and measures should be taken to improve it. Two main approaches are used for that: the Plan-Do-Study-Act (PDSA) cycle and benchmarking.
PDSA cycle is a diagram that describes the activities that need to incorporate continuous improvement into the operation, while benchmarking is studying the business practices of other companies for purposes of comparison.
5 Managing Business Qualities
5.3.1.3 Employee Empowerment
This principle focuses on empowering all employees to find quality problems and then correct them. In TQM, employees are rewarded for uncovering quality problems. TQM also empowers workers to make decisions that are relative to qualities in the production process; their assistance is highly appreciated, and their sugges-tions are implemented. In order to perform this function, employees are given continuous and extensive training in quality measurement tools.
TQM stresses that quality is an organizational effort. To facilitate solving any problem related to quality, it places great importance on teamwork. Using techniques such as brainstorming, discussion, and quality control tools, teams work regularly to correct problems. The contributions of teams are considered essential to the success of the company. For this reason, companies set aside time in the work-day for team meetings.
5.3.1.4 Product Design
The important thing in building quality into a product is to ensure that the product design meets the customer’s expectations. This typically needs effort to understand the customer’s language because his language often changes. To produce a product that customers want, a useful tool for translating the voice of the customer into specific technical requirements is produced, and this tool is called quality function deployment (QFD). QFD is also useful in enhancing communication between different functions, such as marketing, operations, and engineering. For example, an automobile manufacturer evaluating how changes in materials affect customer safety requirements. This type of analysis can be very beneficial in developing a product design that meets the customer’s needs, yet does not create unnecessary technical requirements for production. QFD starts by defining the important customer requirements, which typically come from the marketing department. These requirements are numerically scored based on their importance, and scores are translated into specific product characteristics. Evaluations are then made of how the product compares with its main competitors relative to the identified characteristics.
QFD is a method first developed in Japan. Yoji Akao, the original developer of QFD, described it as a “method to transform qualitative user demands into quantitative parameters, to deploy the functions forming quality, and to deploy methods for achieving the designed quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.”
5.3 Definition of Total Quality Management (TQM) 85
5.3.1.5 Process Management
According to TQM, a quality product comes from a quality process. This means that quality should be built into the process. The source of quality is the belief that it is far better to uncover problems and correct them than to remove defective items after production. If the source of the problem is not corrected, the problem will continue to occur. When dealing with the source of quality, the difference between old and new concepts should be illustrated. Old concepts focus on inspecting goods after production; if an inspection discovers defects, then the products are either removed or sent back for reproduction (the new concepts). All that will cost money for the company.
5.3.1.6 Managing Supplier Quality
TQM extends the concept of quality to a company’s suppliers. When materials arrive from the company, an inspection is performed to check their quality. The philosophy of TQM extends the concept of quality to suppliers and ensures that they engage in the same quality practices. Today, many companies have an agent at their supplier’s location, thereby involving the supplier in every stage from product design to final production. In fact, the application of quality management in terms of efficiency is impossible without the existence of these association relationships with suppliers.
5.3.1.7 Use of Quality Tools
TQM employees need to understand how to assess the quality by using a variety of quality control tools, how to interpret findings, and how to correct problems.
Table 5.4 represents the basic tools that can be used through work.
Within these principles, you can see that leadership plays a central role in TQM; it makes the difference between the reputations of industries. Leadership ensures the personal commitment of the general manager and the management structure to be involved in the implementation of the integrated approach to TQM. Leaders involve employees in the implementation of quality management, with an important role in the operation of all the principles underlying quality management.
Some of the basic characteristics of successful leaders are:
1. Listening to customers
2. Encouraging workers by providing resources, training, and a work environment to help them do their jobs
3. Emphasizing improvement rather than maintenance
4. Encouraging collaboration rather than competition
5. Training and coaching, not directing and supervising
6. Learning from problems—an opportunity for improvement
5 Managing Business Qualities
Table 5.4 Quality tools
Cause and
A chart that identifies potential causes of particular quality problems effect
Flowchart
A diagram of the sequence of steps involved in an operation or process; it provides a visual tool that is easy to use and understand
Checklists
A list of common defects and the number of observed occurrences of these defects. It is an effective fact-finding tool that allows the worker to collect specific information about the defects that have been observed
Control
Charts that are used to evaluate whether a process is operating within a set of charts
expectations relative to some measured value such as weight, width, or volume Pareto
A technique that is used to identify quality problems according to their analysis
importance
Histogram
A chart that shows the frequency distribution of observed values of a variable; it shows what type of distribution a particular variable displays, whether symmetric distribution or normal distribution
Scatter
Graphs that show the relation between two variables. They are particularly useful diagrams
in detecting the amount of correlation or the degree of linear relationship between two variables
7. Continuously trying to improve communications
8. Continuously demonstrating commitment to quality
9. Choosing suppliers on the basis of quality, not price
5.4 Stakeholders
The people interested in software system are termed “stakeholders.” Stakeholders can be defined as any person who has a stake in the success and progress of the system, for example, customer, developer, project manager, and even the person who markets the system are also termed stakeholders. Understanding the role of the stakeholder is fundamental to understanding the role of the architect in the development of a software product or system. Some stakeholders are more interested in their roles than others, so part of the architect’s roles is to engage with those people to show the importance of their involvement and to obtain their commitment to the task.
Despite the fact that stakeholders have shared stakes in the success of that system, they have different concerns that they wish the system guarantees. Such concerns include short time to market or low cost of developing the system. Early engagement with stakeholders allows understanding the constraints of the task, negotiating the priorities, and also making the trade-off. So knowing the stakeholder is one of the priorities of the architect. Table 5.5 shows some stakeholders and their interests in the architecture.
87
Table 5.5 Stakeholders and their roles
Analyst
Analyzing the architecture to make sure it meets the quality attribute requirements Architect Making a trade-off among competing requirements, recording design decisions, and providing evidence that the architecture satisfies the list of requirements. The architect is mainly responsible of the system
Designer Understanding how the parts of the system are interacting and communicating; applying the architecture to meet specific requirements of the parts for which they are responsible
Customer Assuring the required functionality is available and estimating the cost and setting expectation of the delivered part. The main responsibility of the customer is paying for the system and ensuring its delivery
User
Might use architecture documentation to see if the specific function is delivered and seeing the major elements of the system
5.4.1 Stakeholders and Business Goals
Stakeholders (explicitly or implicitly) drive the whole shape and direction of the architecture to serve their needs. Of course, without stakeholders, there would be no point in developing the architecture because there would be no need for the system.
Basically, a good architecture is one that successfully meets the objectives, goals, and needs of its stakeholders.
Many times stakeholders will directly say what they need, but often they are not so direct. Thus, one of the important roles of architects is to figure out what are the quality attributes that are going to impact the design of the system.
If the stakeholders tell the architect directly, they give them something to work with. If the stakeholders tell the architect indirectly, the architect has to outline what the impact on the architecture is going to be. Stakeholders have business goals and objectives, and this will lead to quality attribute requirements that will be a key input to the design of software architecture. Collecting requirements, designing, and documenting the architecture will start with stakeholders. The roles of stakeholders differ between businesses, depending on the rules and responsibilities laid out at the foundation of the company.
The example in Fig. 5.1 shows that if the concern of the stakeholder is the integration with other systems easily, then the quality requirements will be interoperability, modifiability, and portability. If his concern is to increase market share, then the quality requirements will be modifiability, usability, and so on.
A collaborative approach will be the shape between stakeholder and the organization, and this type of approach is coherent and driven by business goals especially the long-term ones. The manager is not separate from the stakeholder but is part of it. Thus, the idea of “managing” is viewed as being counterproductive for both the corporation and its stakeholders in the long run.
88
5 Managing Business Qualities
Stakeholder concerns
Quality attribute requirments
Leades to
Fig. 5.1 Stakeholder concerns and quality attributes
5.5 Process Improvement
Many software companies have turned to software process improvement as an approach of enhancing the quality of their software, reducing costs, or accelerating their development processes. Process improvement can be defined as understanding the existing processes and changing these processes to increase product quality and/
or reduce the time of development and cost. The approaches that are used to process improvement and change differ from one project to another. For example, for large projects, the process approach is used; this approach is focused on improving process and project management and introducing good software engineering practice into an organization. For small and medium projects, the agile approach is used; this approach focuses on iterative development in the software process.
The process maturity approach is rooted in the plan-driven development, while in the agile approach, the focus is on the code being developed.
5.5.1 Process and Product Quality
Process quality and product quality are closely related. The benefits of the process improvement occur because the quality of the product depends mainly on its development process.
A good process is usually required in order to produce a good product. There are four important factors affecting the quality of products, whether they are software product or any other intellectual products such as books or films, these are:
• Development technology
• Process quality
• Product quality
• Cost, schedule, and time
An intellectual product is a product of which its quality depends on its design.
89
The influence of each factor depends mainly on the size and type of the project.
For large systems, the principal factor that affects the quality of the product is the software process, while for small projects, the qualities of the people that work on the product (development team) play an important role in these types of projects. If the team is inexperienced, a good process may limit the damage, but it will not lead by itself to a high-quality product.
Irrespective of people, process, or tool factors, if a project has an insufficient budget or unrealistic schedule, poor quality for the product might save the project.
The organization must compete to survive.
5.5.2 The Process Improvement Life Cycle
We all observe the software process in all organizations, these processes differ depending on many things such as the types of products that are being developed and the size of the organization itself (it plays an important role when choosing the software process), and many other things are taken into account when designing the software process. There is no such thing as a standard software process that is applicable in all organizations or for all software products of a particular type. Any change of the processes in the organization must consider the local environment and culture. Each company has to develop its own process depending on its size, the type of software being developed, the skills of its staff, market requirements, and the company’s culture.
Improving the process must be under consideration; specifying the goal from this improvement is very important, for example, the goal might be to improve software quality so you may wish to introduce new process activities that change the way software is developed. Also, if the interest is improving some attributes of the process (such as development time), then you decide which process attribute is the most important to the company. It is difficult to gain all process attributes at the same time.
Process improvement is a cyclic process; it consists of three sub-processes, and these are (Fig. 5.2):
• Process measurement: attributes of the current process are measured. These form a baseline for deciding that improvements have been effective.
GQM (goal-question-metric) paradigm is one of the important measurements of the process.
5 Managing Business Qualities
Fig. 5.2 Process
improvement activity
Measure
Analyze
Change
• Process analysis: the current process is assessed, and bottlenecks and weaknesses of the process are identified.
Questionnaires and interviews and ethnographic studies are the most commonly used techniques of process analysis.
• Process change: changes to the process that have been identified during the analysis are introduced. The cycle resumes to collect data about the effectiveness of the changes.
Improvement identification and prioritization, process change introduction, process training, and change tuning are the important stages in the process change process.
Without concrete data on a process, it is impossible to evaluate the value of process improvement.
Improving the process is a continuous activity; whenever a new process is introduced, it will change the business environment; and it will have to evolve to take these changes into consideration. The important focus of process improvement is on:
• Improving quality
• Reducing costs
• Shortening life cycle time of the project
• Decreasing risk
91
5.6 Important Qualities in Business
At the end of the chapter, we see that the company wins in their competition with others through building high-quality products. From that, you can conclude how qualities are important in the business or even nonbusiness fields because qualities in business not only help the company meet its customer’s expectations but also help to keep costs down. Companies can build their reputation by building high-quality products.
Some of the main important benefits of qualities in business are:
• Meeting customer expectations
• This is the main point from using quality in any company; if customers do not find the qualities they expect from you, they will go to others to gain what they need. Quality products make an important contribution to long-term profits.
• Managing a reputation
• Quality influences the reputation of the company; a strong reputation for quality can make the difference in a competitive market.
• Meeting the standards of the company
• Accreditation to the standards of quality is very essential for dealing with certain customers; it also helps winning new customers and entering new markets.
• Managing costs
• Poor quality will increase the cost; if you do not have quality control, you may gain the cost of analyzing nonconforming services to determine the root causes and then retesting the services after rework; and this process costs effort, time, and money.
5.7 Summary
Business qualities can be defined as non-software system qualities that influence other types of qualities. Business qualities are important qualities that are taken from the market’s point of view, and the goals of such types of qualities are centered on:
• Cost and time to market
• Marketability
• Standardization
• The scheduled time for building the system
