Lina Khalid
ECOMMERCE
BUSINESS
THIS
CHRISTMAS
LET US JUMP START YOURECOMMERCE BUSINESS THIS CHRISTMAS
LET US JUMP START YOUR
ECOMMERCE BUSINESS
THIS CHRISTMAS
∙∙
ISBN
978-3-030-13631-4 ISBN
978-3-030-13632-1 (eBook)
https://doi.org/10.1007/978-3-030-13632-1
© Springer Nature Switzerland AG 2020
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Software architecture has many axes when you first begin with it: the business goals of the system, the architecture requirements of the system, etc. This book is where you can gather all the knowledge on everything you need to know regarding software architecture.
This book, which mainly focuses on software architecture and its relation to business, is for students who just start their studies in software engineering field and are in the first course on software architecture; it helps them know the main concepts on software architecture and highlights their thoughts on relating this concept with business context. It shows that through building high-quality products, it helps the architects in the business field to think more efficiently in qualities through building the architecture of the products.
I have been trying to gather the sum of my knowledge in the software architecture field in one place to make it simple, short, yet thorough, and all-inclusive, and here it is, right between your hands. This is the perfect guide for the beginners in software architecture. The reason why I am proud of what I managed to put together is not only because of the knowledge contained within this book but also because I believe this is suitable for any student especially the beginners in the field.
So, whether you are taking your first class in software architecture or you are new to a job in this field, this is the book for you.
This book has two main pillars: the first one is software architecture and its relation to quality and the techniques that are used to gather information for quality, such as QAS and QAW, and the second pillar is the business world and how to build high-quality products through software architecture, which would make them competitive in the market.
This will be worth your time.
Good luck!
Lina Khalid
See how to do eCommerce business this Christmas
v
First of all, I thank God for answering my prayers and helping me through my journey.
Many thanks to the Springer team for guiding me through this process.
Many thanks go to the light of my life, Leen, for her courage and support and for always giving me a push. Thank you, Leen.
I hope all my efforts yield a well-guiding book for students all over the world.
Lina
vii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Architecture Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Basic Types of Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.4 Modern App Architecture for the Enterprise . . . . . . . . . . . . 7
1.3 Architecture Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Architecture and Requirements . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 The Life Cycle of Architecture . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 Documenting Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Architecture and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Influence of Architecture on Systems . . . . . . . . . . . . . . . . . 14
1.5 Architecture’s Role in Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 What Makes Good Architecture in Business? . . . . . . . . . . . 17
1.6 Architectural Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Business Software Architecture (BSA) . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Business Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 Software Architects Need Business Education . . . . . . . . . . 22
2.1.2 Roles of Software Architects and Business Managers in
Business Software Architecture . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Defining Requirements for Business Architecture . . . . . . . . . . . . . . 24
2.3 Pragmatic Architecture Today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Business Architecture’s Roles in Management . . . . . . . . . . . . . . . . 27
ix
Contents
Understanding and Dealing with Qualities. . . . . . . . . . . . . . . . . . . . . . 33
3.1 Definition of Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Software Qualities for the Product . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Architecture Quality Attribute and Business
Quality Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Architecture and Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Architecturally Significant Requirement (ASR) . . . . . . . . . 38
3.3.2 Qualities and Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Gathering Quality Attribute Information . . . . . . . . . . . . . . . . . . . . . 42
3.4.1 Quality Attribute Scenario (QAS) . . . . . . . . . . . . . . . . . . . . 42
3.4.2 Quality Attribute Workshop (QAW) . . . . . . . . . . . . . . . . . . 45
Achieving Quality Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Architectural Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1 Patterns and Their Roles in Building Architecture . . . . . . . 53
4.3 Tactics and Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.1 Achieving Quality Through Tactics . . . . . . . . . . . . . . . . . . . 64
4.3.2 The Relationship Between Tactics and Patterns . . . . . . . . . 67
4.4.1 Pattern for Enterprises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Importance of Patterns in Business . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 The SEI Attribute-Driven Design (ADD) Method . . . . . . . . . . . . . . 70
Managing Business Qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1 Business Quality Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.1 The Role of the Architect in Achieving the Quality . . . . . . 81
5.3 Definition of Total Quality Management (TQM) . . . . . . . . . . . . . . 82
5.3.1 Principles of TQM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.4.1 Stakeholders and Business Goals . . . . . . . . . . . . . . . . . . . . . 87
5.5 Process Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.5.1 Process and Product Quality . . . . . . . . . . . . . . . . . . . . . . . . 88
5.5.2 The Process Improvement Life Cycle . . . . . . . . . . . . . . . . . 89
5.6 Important Qualities in Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Software Product Line (SPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2 A Framework for Software Product Line Engineering . . . . . . . . . . 97
xi
6.3 Architecture and Software Product Line . . . . . . . . . . . . . . . . . . . . . 99
6.3.1 What Makes a Software Product Line Succeed? . . . . . . . . . 100
6.4 The Quality Attribute of SPL (Variability Quality) . . . . . . . . . . . . . 101
6.4.1 The Goal of Variability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4.2 Variation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.5 Evaluating a Product Line Architecture . . . . . . . . . . . . . . . . . . . . . . 104
Internet of Things (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2 Architecture and IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.3 Basic Qualities of IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.3.1 Interoperability Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.3.2 Modifiability Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.4 DYAMAND: Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.4.1 DYAMAND Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.4.2 DYAMAND Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.5 Evaluating IoT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Service-Oriented Business Architecture (SOBA) . . . . . . . . . . . . . . . . . 129
8.1 Definition of Service-Oriented Business Architecture (SOBA) . . . 130
8.2 Basic Qualities in SOBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.2.1 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.2.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.3 The Impact of Service-Oriented Architecture on Quality
Attribute and Business Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.4 Service-Oriented Business Architecture and the Evaluation
Patterns and Tactics
QAS
Chapter 4
QAW
Chapter 3
Architecture Definition and Types
Chapter1
SPL, IoT, SOBA
Software Architecture for
Systems
Business
Chapters 6, 7, 8
The Book
Business Software
Managing business quality
Architecture
Principles of TQM
Chapter2
Chapter5
A quick tour
Add Featured Samples Of Your Products & Services
xiii
Chapter 1
Introduction
Abstract The importance of the architecture concepts is highlighted through the applications in the market place and through the aim of producing high qualities from it. This chapter is the introduction to the set of definitions of the types of architecture, system architecture, software architecture, enterprise architecture, and business architecture, but it focuses mainly on software architecture. There are many contexts that affect in building the architecture of the system such as technical, business, and background of the architect effects; all of them will be affected by the architecture after build. Marketecture is a concept that describes and gives a structural view of the main components when a quick review of the architecture is needed. Finally, the life cycle of architecture with the methods used for each stage in the cycle is described. Briefly, this chapter gives a good introduction for the basic types of architecture and the most important concepts of software architecture, but what makes it differ from other basic chapters in other books on architecture is that it highlights the modern app architecture which the enterprises need when building their architecture. Modern software architecture features will also be defined.
At the end of this chapter, you will learn:
• Definitions of the basic type of the architecture: software architecture, system architecture, enterprise architecture, and business architecture
• What the modern app architecture for the enterprise is
• The life cycle of the architecture
• The influence of architecture on systems
1.1 Architecture Definition
Software systems are built to achieve the business goals of organizations. The architecture of the system paves the way to achieve these goals. The path seems to be complex, but the life cycle of the architecture attenuates this complexity. Architecture is the basic part of any system. It is embodied in its components, their relationships with each other, and the environment.
© Springer Nature Switzerland AG 2020
Custom PayPal Checkout Integration
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_1
1 Introduction
It is obvious that effective software engineering needs the software architecture for many reasons. First, building the right architecture is very important to the success of the system—the wrong one can lead to catastrophic results. Second, it is very important to build common paradigms so that the big picture of the system can be understood and the new systems, distinct from old systems, can be built. Third, detailed understanding of software architecture allows the software engineer to choose among design alternatives.
1.2 Basic Types of Architecture
Every system has its own architecture, which represents the abstract view of the system, and this is called software architecture. Many other types of architecture are related to software architecture, but they are broader than software architecture.
These include system architecture, enterprise architecture, and business architecture.
1.2.1 Software Architecture
There is no standard definition for software architecture. You can realize that easily through searching. For example:
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of software architecture as the following:
Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.
Mary Shaw and David Garlan, from their early works, defined software architecture as:
Software architecture goes beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem.
Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives
Martin Fowler, in his book Patterns of Enterprise Application Architecture, outlines some common recurring themes when explaining architecture. He identifies these themes as “The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is
1.2 Basic Types of Architecture
3
architecturally significant can change over a system’s lifetime; and, in the end, architecture boils down to whatever the important stuff is.”
The definition that is going to be used in this book is the one that is defined by Bass, Clements, and Kazman in their book Software Architecture in Practice (3rd edition):
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
The above makes the thought of software architecture simpler: it consists of elements and relations between these elements. The main characteristics of this definition are:
1. Architecture Defines Structure
Structure is a set of elements held together by relations. Elements and relations might be runtime related such as a “sends data to” relation between processes or tasks. Elements and relations might also be non-runtime related such as an “inherits from” relation between classes.
Software systems are composed of many structures, and no single structure can hold the architecture. The most important thing for a structure is minimizing dependencies between elements and components, creating a loosely coupled architecture from a set of highly cohesive components. Every system has documentation for software architecture in case people that uses it are long gone and to prevent the source code from being lost.
Loosely coupled architecture is an approach to interconnecting the components in a system or network so that those components depend on each other to the least extent practicable.
2. Architecture Is an Abstraction
Abstraction means that architecture deals with certain information of the elements without going into their details. Through abstraction, dealing with the complexity of the system becomes very easy.
Complexity of the system means that the system encompasses several properties of pieces of software, all of which affect internal interactions.
“Complex” describes the interaction between many entities. Increasing the number of entities will increase the interaction between these entities which increases the complexity which will in turn increase the risk.
1 Introduction
3. Architecture Addresses Functional and Nonfunctional Requirements Reasoning of the system should be an attribute that is important to some stakeholders. This includes functional and nonfunctional requirements.
Functional requirements appear in use cases, while nonfunctional requirements do not. Nonfunctional requirements are related with how the system presents the required functionality.
Finally, a good architecture is the one that allows the system to meet its functional, quality attribute, and life cycle requirements. Also, the most important thing in software architecture is that it highlights on the early design decisions of the work, so architectural design decisions are the result of a software design process.
This will be further discussed in the life cycle of architecture.
1.2.1.1 Modern Software Architecture
Modern software architecture has the following features:
• Changeable: Requirements always change. An architect needs to be flexible with these changing requirements.
• Integration with lots of system applications (many of them are open source) and messages.
• Highly scalable.
• Loosely coupled with SOA and Event-Driven Architecture (EDA) for two main reasons: one is to reduce the complexity and two is to increase the modifiability feature of architecture which enables the design to change, this is crucial for software architecture. Implementing the main principles of abstraction, separation of concerns, and information hiding all leads to loose coupling architecture.
Event-Driven Architecture is a framework that arranges behavior about the production, detection, and consumption of events as well as the response they evoke. EDA compliments SOA because these services can be activated by triggers fired on incoming events.
Those were some of the important features of modern software architecture, but it is important to know that architecture itself is:
• A big picture of the system.
• A set of quality attributes: the most important ones are usability, stability, and scalability.
• Costly to change. This affects the architecture decisions.
1.2 Basic Types of Architecture
5
1.2.2 System Architecture
Architecture is the skeleton of the system; it outlines the elements and their interactions in a system including its hardware and software elements. It includes software architecture in its definition and provides a suitable environment for the software architecture, that is why a system architect should understand not only the individual components but also the interrelationships among them. System architecture is on the top level in system building, strategic decisions, engineering tradeoff, and their associated rationales regarding how the system will meet the allocated requirements. System architecture may dominate functional behavior and emergent behavior. It also provides guidance and structure to later phases of system. In conclusion, system architecture is a way to understand, design, and manage complex systems. The complexity of the system comes from two main aspects:
• Integration of components: With integration, a large numbers of components are interrelated.
• Heterogeneity of components: Many fields need to design complex systems which make it very difficult to have a heterogeneous vision.
One way to understand complex systems is by structuring the system as a hierarchy, layers, etc. It is done through two main types of system quality attributes: modularity and integrity.
Modularity is a technique to divide a software system into multiple discrete, independent modules, which are capable of carrying out tasks
independently.
Integrity is a property of data that is resistant to unauthorized modification.
This must be in relation to a security policy that defines which data should be modified and by whom.
1.2.3 Enterprise Architecture
The meaning of enterprise architecture differs upon the person you ask. “Enterprise”
is any organization or collaborative collections of sub-organizations with the same goals. Previously defined, “architecture” is the structure and behavior of the system.
“Enterprise architecture” is managing enterprise analysis, design, plan, and implementation for successful development and execution. Enterprise applies the principle and practice of architecture to guide the changes for the organization.
The primary reason for developing enterprise architecture is to support the enterprise by providing the fundamental technology and process structure for the strategy of IT.
1 Introduction
Enterprise architecture makes sure that the IT landscape has three main qualities: robust, flexible, and efficient.
Enterprise software architecture is closely matched with the enterprise’s internal organization, business model, and processes. To improve the speed and functionality of the enterprise, enterprise software architecture should have the following characteristics:
• Simplicity: It should be simple enough to facilitate effective communication among key team members. A lot of people with different viewpoints, skills, and roles regarding the software are engaged for deciding the structure and specifying the enterprise software.
• Flexibility and maintainability: Each enterprise system should continuously adapt to the new needs of the evolving markets, business organizations, and legal changes. So, the architect must create a highly maintainable and flexible system.
The architecture should have unique components that could be reorganized. The reorganization should be carried out in a flexible way so that the local modifications done in the system do not influence the system overall.
• Reusability: This can be achieved by developing blocks and constantly reusing them. This can be achieved by providing standard functionality in code libraries, which are used across various projects.
• Adaptation and modification: The final architecture must adapt not only to the changes that occur in technologies but also to the real life cycles of the implemented technologies.
EA is not system information, service, or solution architecture. It is the output of the stakeholder. So architects need to know about stakeholders and their objectives and views (Fig. 1.1).
The organization may develop the architecture using industry mechanisms which include IT industry technique and other methods that are used to develop enterprise architecture.
1.2.3.1 Business Architecture
Business architecture defines the structure of an enterprise in terms of enterprise structure, business process, and business information. In defining the structure of the enterprise, business architecture takes into account some important elements such as customers, finances and the market considerations according to products and services, and other things related to the enterprise itself. It is important to know that the business is not limited by the enterprise; therefore the business architecture must be able to represent parts of the business that are outside of the enterprise and stakeholder interests.
This book will define the role of software architecture in business applications; it will show how software architecture can build high-quality applications, and the last three chapters will explain that in detail.
1.2 Basic Types of Architecture
7
Stakeholders of
The Enterprise
On the left side
you see the
external entities
(stakeholders ) that
Business Strategy
may derive the
of The
business strategy
Organization
of the organization
Enterprise Architecture
Principles of
Architecture with
Technology and
Build Framework of The Architecture
Methodology used
by Enterprise
From
Standard of Enterprise Architecture
Fig. 1.1 Role of stakeholder in the enterprise system
1.2.4 Modern App Architecture for the Enterprise
Software is the critical part that defines the company regardless of the product.
Software is how you connect the customers, reach new customers, understand their data, promote your products, and process their order.
To do this, software is going to be composed of small pieces ( microservices) that are designed to do a specific job. Each service from the microservices is built with all the important components, which makes it able to “run” a specific job. These services are loosely coupled together so they can be changed at anytime.
1 Introduction
Microservice is an approach to application development in which a large application is built as a group of modular services. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services.
Organizations are offering Docker Containers-as-a-Service (CaaS) environment which are standard units of software that look the same on the outside but are different when it comes to code and dependencies of that software. This enables developers and IT teams to move them across different environments without requiring any modifications.
Docker containers provide agility for development teams, control for operations teams, and portability of apps across any infrastructure. With this agility, developers are able to use any language and any tool because they are all packaged in a container, and that makes it standard for all the heterogeneity (Fig. 1.2).
The high level of the containers contains:
• An operating system
• A software that you build such as PHP or ASP.net application
• Dependencies to run the software (e.g., your software requires MYSQL to be the pre-request software to the software application you build)
• Environmental variables
Each container has a name for it.
Keywords of Docker are Build, Ship, and Run anywhere, and these keywords mean that the developer easily builds applications and packages them along with their dependencies into a container, and then these containers can be easily shipped anywhere.
Fig. 1.2 Docker
containers
Container 1
Container 2
Container 3
kernel
1.2 Basic Types of Architecture
9
Fig. 1.3 VM architecture
APP
APP
APP
Guest OS Guest OS Guest OS
VM MOINETOR
HOST OS
SERVER
To concludethe features of Docker’s are:
• Containers make it easier for teams across heterogeneous environments.
• Docker containers can be deployed anywhere, on any physical and virtual machine and even on cloud.
• Scaling is very easy to apply in Docker containers.
Docker Architecture
To understand the Docker architecture, you need to compare it with the previous architecture (virtual machine architecture).
Virtual machine consists of:
• The server which is the physical server that is used to host multiple virtual machines.
• The host OS is the base machine such as Linux or Windows.
• The hypervisor which means virtual machine monitor (VMM) is a computer software, firmware, or hardware that creates and runs virtual machines.
You would then install multiple operating systems such as virtual machines on top of the existing hypervisor as guest OS and then host your applications on top of each guest OS (Fig. 1.3).
Dockers are the modern VM architecture and it contains the following:
• The server is the physical server that is used to host multiple virtual machines.
• The host OS is the base machine such as Linux or Windows.
• The Dockers engine. Dockers run on Docker engine. This engine used to run the operating system
All of the apps now run as Dockers container (Fig. 1.4).
1 Introduction
Fig. 1.4 Docker
architecture
APP
APP
APP
DOCKER
HOST OS
SERVER
The clear advantage in this architecture is that you do not need guest OS. Everything works as Dockers containers.
To make apps smarter, a new technology appears to enhance enterprise applications. This technology is called serverless. Serverless is a software development approach. It first described applications that are significantly or fully dependent on services to manage server logic side which is known as backend as a service or
“BaaS” that make serverless use third party in its architecture. Another meaning of serverless which overlaps with the previous definition is that serverless can also mean applications where some amount of server side is written briefly. This will be called “Function as a service or FaaS.” The most popular implementation of FaaS is AWS lambda. With lambda you can run any type of code; you only upload the code and lambda takes care of everything and scales the code with high availability. AWS
lambda is the newer definition of BaaS.
To conclude:
• Docker is a software container platform; it packages all the tools into one isolated container.
• AWS lambda is the implementation of FaaS; it lets you code without servers.
Serverless cloud such as lambda is built on container, but the advantage is that it does not need to be managed.
1.3 Architecture Life Cycle
It is important to review the software architecture life cycle because the development of architecture would be carried out within. The architecture development life cycle can be seen as a general model which contains all the activities that are needed to develop software architecture.
11
1.3.1 Architecture and Requirements
Requirements are descriptions of the services that a software system must provide and the constraints under which it must operate. Requirements can range from high-level abstract statements of services or system constraints to detailed mathematical functional specifications. All requirements fall under the following classification:
• Functional requirements: These are a set of services the system should provide and the reaction of the system to an input. Sometimes functional requirements may also state what the system should not do. The reaction of the architecture to this type of requirement is the basis of design decisions according to the responsibilities assigned to architectural elements
• Quality attribute requirements: These are the qualification of functional requirements. Qualification is how fast the functional requirement must be performed (e.g., how fast the function is executed). The various structures that are designed into architecture satisfy this type of requirements.
• Constraints: A constraint is a design decision that has already been made such as using a specific programming language or reusing a certain existing module; all these choices are made from the view of an architect. Accepting the design decisions and integrating them with others are the reactions of architecture to this type of requirements.
1.3.2 The Life Cycle of Architecture
The life cycle of software architecture is composed of a set of stages: architectural requirements and analysis, architectural design, architectural documentation, and architectural evaluation. Each one of these stages is supported by a set of activities and methods to ensure predictability, repeatability, and high-quality results
The first stage (architectural requirement) needs a set of activities starting from eliciting requirements, analyzing them, and then prioritizing the most important one. The most important method or technique used to extract these requirements is QAW (Quality Attribute Workshop) . Chapter 3 explains QAW in detail. Architectures are mostly driven by architecturally significant requirements (ASR) which is as set of requirements that influence the architecture. These requirements are captured from requirement documents, by interviewing stakeholders or by QAW.
Next stage is architectural design. This stage also needs set of activities to be completed. These activities start with ASR and derive the set of architectural design decisions which require evaluation at the end. Because of the complexity of the design stage, they are used repeatedly until the architecture is complete and validated. The Attribute-Driven Design (ADD) is an iterative method used in this stage to help the architect to:
1 Introduction
Architectural Requirements
QAW
and Analysis
ADD Method
Architectural Design
UML
Architectural Documentation
ATAM
Architectural Evaluation
Fig. 1.5 Architecture life cycle with methods
• Choose an element to design
• Assemble the ASR to that element
• Design the chosen element
ADD helps produce a workable architecture early and quickly. ADD is explained in detail in Chap. 4.
Architecture design decisions are those decisions that address architecturally significant requirements. These decisions are hard to make and/or costly to change.
The next stage is documenting the architecture. A document has to be created to explore the different structures that make up the architecture.
Architectural view is a representation of the structure written and read by stakeholders.
13
The last stage is the evaluation of the software architecture. This stage focuses on evaluating the software architecture and whether it satisfies the requirements which it is built on or not. The most important method used to evaluate the final architecture is the one that comes from SEI which is called ATAM (Architecture Tradeoff Analysis Method). The main purpose of this technique is to evaluate the consequences of architectural decisions according to the business goals and quality attribute requirements.
According to SEI, ATAM is a method for evaluating software architecture according to quality attribute goals.
1.3.3 Documenting Architecture
Documenting the architectural involves writing the documents that describe different structures that build the architecture for the purpose of communicating it efficiently to the different system stakeholders. An important output of this process is a set of architectural views, which represent the system’s structures, their composing elements, and the relationships among them. Documenting the architecture involves creating a set of related views which can be classified into different types: module views which show the structures where the elements are implementation units, component- and-connector views which show how the elements in the structures behave at runtime, and allocation views which show how the elements in the structures are allocated to the physical resources. Quality view is another type of view which is tailored for specific stakeholders or to deal with a specific concern. For example, security view shows all the responsibility measures to handle the security quality; it will show the components that have some security role and any data repository for security information. UML (Unified Modeling Language) is a way for documenting architecture views.
Documentation is very important to the architects, whether they still work on the system or not. It is used for:
• Construction: Documentation tells the developers what to build, how the elements should behave, and how they connect together.
• Analysis: Analysts will use the documentation to direct the architect for his job specifically to provide the required behavior and quality attributes.
• Education: Architecture documentation can be used to introduce people and new team members to the system.
• Communication: Architecture documentation serves as a primary vehicle for communication among stakeholders.
• Clarifying business goals, requirements, and activities: With a proper documentation, you can share the business goals and requirement with your managers and team so that they have a clear vision and goals.
1 Introduction
Finally, the question is what to document?
When a quick system is needed to be produced, the term “marketecture” appears.
Marketecture describes the main components and perhaps provides a structural view of these components.
The next thing is the needs of the various project stakeholders. Because architecture documentation serves an important communication role between different members of the project team, in a small team a minimal documentation is fair enough because of the interconnection between the team members. However, in large teams the architecture documentation becomes essential. This is why there is no straightforward answer. Documentation takes time to be developed, and it also costs money. It is therefore important to think carefully about what documentation is going to be most useful within the project’s context.
In the market, documentation is important for three main purposes:
• To motivate the user about the product and encourage them for becoming more involved with it
• To inform users exactly what the product does, so that they receive a product according to their expectations
• To compare the product with other alternatives
1.4 Architecture and Technology
Architects make the design decisions of the system early in the life cycle of the project. Many of these decisions are difficult to validate until the final system is built. This is why sometimes building a prototype of a system is useful in the design approach, but it remains difficult to be certain of the success of a specific design choice in the context of the application. Thus, pattern, an abstract representation of architecture, is used. Patterns will be explained in Chap. 4
1.4.1 Influence of Architecture on Systems
Software architecture is influenced by different types of contexts such as technical, businesses, and social contexts. All these influences will affect the architecture in the future. This is why architects need to understand the nature of these influences early in the process.
These influences will be discussed by the following questions:
• Technical: What technical role does the software architecture play in the system of which it is a part?
• Project life cycle: How is software architecture related to the phases of a software development life cycle?
1.4 Architecture and Technology
15
• Business: How does the existence of software architecture affect an organization’s business environments?
• Professional: What is the role of software architect in an organization or a development project?
The important thing to know about architecture in the technical context is that if you care about specific quality attribute, you have to be concerned with specific decisions; all of these decisions depend on the nature of the architecture. For example, if you care about performance, then you should concentrate on managing the time between elements and their use of shared resources. On the other hand, if you care about interoperability, you need to pay attention on the elements that are responsible for external interactions between these elements and so on.
Architects need to understand the goals of the organization in the business context. Many of these goals deeply influence the architecture, while other business goals have no effect on the architecture at all. Business goals are one of the basic drivers for building software architecture.
The architect’s background and experience on building the products is very important for architecture in the professional context; he needs many professional skills to build high-quality products. For example, he needs to know how to deal with customers and to have the ability to communicate ideas clearly.
As a result, architecture has influences that influence its construction, and once the architecture is constructed, it then influences a set of influences which lead to its construction. The cycle of influences is called the Architecture Influence Cycle (AIC) (Fig. 1.6).
Architect
Building The
Architecture
Business, Technical,
Stakeholders
Project Influences
Professional Background
Complete System
Fig. 1.6 Architecture influence cycle
1 Introduction
1.5 Architecture’s Role in Business
The role of software architecture in business is very important to improve the understanding of the business clearly and then to help solve the problems of that business and to support the business and its activities.
Software architecture in business increases the productivity and efficiency of the business and all that is done through following:
• Decision support: This needs understanding of ADD (Attribute-Driven Design) method of the software architecture and also the types of pattern that is used.
According to SEI, ADD method is an approach to define software architecture in which the design process is based on the software quality attribute requirements.
• Availability of using a new way of technologies, for example, the web services that is used in the business to support interaction with suppliers of goods sold by the web shop application.
• The process improvement of the business, which is supported by the software architect, improves the functionality of the business.
For a business manager, the thing he focuses on the most is being able to change the product quickly, and that makes the software architect constantly thinking about changeability quality. The important thing to know is that the software architect needs practical knowledge of the business to make good judgment or design. That is why the software architect must understand business issues well. Understanding the business helps define the design solutions to solve its problems to reach its goals and then choose a good structure for the business.
The architect has five roles in developing a good business:
• Business strategy: The role of this is for business rather than IT. It works on top management which supports decisions around commercial issues of business.
• Business architect: The role of this is for anyone who looks and observes the way of work in business. Also, the business architect has to identify the implementation of the improvements according to the nature of the organization. The software architects use this as a basis for the design of business software solutions.
• Solution architect: The role of this is sometimes synonymous to application architect. This type is one of software architect types when moving from business to software. The difference between a business architect and a software architect is that the business architect architects the business while the software architect architects the software that supports the business.
• Architect of technical infrastructure: The role of this is not directly involved in the software development. This role is needed to deploy a set of solutions that come from the solution architect. This means these two roles must work together to ensure the productivity of the system operators.
• Enterprise architect: The role of this is to collect business, solution, and technical infrastructure roles, depending on how you define the enterprise architecture. This role focuses on the big picture rather than details; for example, the
1.5 Architecture’s Role in Business
17
Business strategy
architect
Enterprise architect
Architect of
Business architect
Solution architect
technical
infrastructure
Fig. 1.7 Architect’s role in business
enterprise architect should know there is a purchasing business process and what this process is used for, but he does not need to know the activities of that process.
Note Each rectangle in Fig. 1.7 represents a role of person that can play, rather than a specific person. Some roles are played by a single person, while others are played by multiple persons.
1.5.1 What Makes Good Architecture in Business?
Nothing can define exactly what good or bad architecture is, but in general a good architecture is the one that allows a system to meet its functionality and quality attributes to reach its goal.
As with business architecture or other types of architectures, there must be set of rules that must be taken into consideration when designing any type of architecture, and some of them are:
1 Introduction
• The architecture should be documented and then evaluated to ensure delivering the system with the specific qualities that we build the architecture for.
• The architect should set and prioritize the most important qualities, and this will give the facts of a trade-off that always occurs.
• Also, good business architecture makes sure that the parts of the project are not be coupled together and that each part has a clear interface.
I agree with the authors who decide that the goodness of software architecture for any type of system does not depend only on the architecture drivers and decisions but also on how business conditions derive these architecture decisions such as the business cost, time to market and the goal of the business itself, and so on.
1.6 Architectural Pattern
Architectural pattern can be defined as the composition of elements to solve recurring problems. The compositions of these elements should be found after a period of time, that is why it will be documented and then disseminated between domains.
Patterns can be characterized according to the type of architectural elements they use. For example:
Layered pattern is a common module type pattern when the uses relation among software elements is strictly unidirectional. A layer is a coherent set of related functionality. Layers are always designed as abstractions that hide implementation from the layer below.
Component-and-connector patterns are:
• Shared-data (or repository) pattern: This pattern comprises components and connectors that create, store, and access persistent data. The repository takes the form of a database. The connectors are protocols for managing this data.
• Client-server pattern: The components are the clients and the servers. The connectors are protocols and messages they share among each other to carry out the system’s work.
Allocation patterns include:
• Multitier pattern: This pattern describes how to distribute and allocate the components of a system in distinct subsets of hardware and software, connected by some communication medium.
• Competence center and platform pattern: This pattern is allocated to sites depending on the technical or domain expertise located at a site. While in platform, one site is tasked with developing reusable core assets of a software product line, and other sites develop applications that use the core assets.
19
1.7 Summary
Architecture in any system is important for many reasons:
• It helps in communication among different types of stakeholders.
• It gives a result of the earliest design decisions through building the system.
• It gives the abstract view of the system.
According to SEI, “software architecture is a set of structures which comprise software elements, relations among them, and properties of both.” This definition encompasses many characteristics in it such as abstraction, addressing functional and nonfunctional qualities, etc. The architect’s role is to select suitable structures to build a system with a high quality. In general, a good architecture is the one that achieves its goal with attention to cost and schedule. Software architecture is influenced by different types of contexts such as technical, businesses, and social contexts. All these influences will affect the architecture in the future.
System architecture is the skeleton of the system; it is the way to describing the elements and their interactions in a complete system including its hardware and software elements, so it includes software architecture in its definition, and it provides the environment of software architecture, that is why a system architect not only knows about the individual components but also understands the interrelationships among the components.
Enterprise architecture is managing enterprise analysis, design, planning, and implementation for successful development and execution. Enterprise applies the principle and practice of architecture to guide the changes of the organization.
The primary reason for developing enterprise architecture is to support the enterprise by providing the fundamental technology and process structure for the strategy of IT.
Enterprise architecture makes sure that IT landscape has three main qualities: robust, flexible, as well as efficiency.
Business architecture defines the structure of the enterprise in terms of enterprise structure, business process, and business information. In defining the structure of the enterprise, business architecture takes into account some important elements such as customers, finances, and the market considerations according to products and services and other things related to enterprise itself.
Modern app architecture for the enterprise is a new concept added to the basic traditional introduction chapters in software architecture books; it shows you that today, software is going to be small pieces that are designed for a specific job, and this is called microservices.
Marketecture also appears in this chapter in architecture documentation, especially when a quick system is needed to be produced. Marketecture describes the main components and perhaps provides a structural view of these components.
1 Introduction
References
There are many good books, reports, papers, and videos available in the software architecture world. Below are some I recommend to expand information
In terms of defining the landscape of software architecture in general, I recommend the following: L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 3rd edn. (Addison-Wesley, 2013) USA
Further Reading
P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford, Documenting Software Architectures: Views and Beyond, 2nd edn. (Addison-Wesley, 2010) USA, Boston US
P. Clements, R. Kazman, M. Klein, Evaluating Software Architectures: Methods and Case Studies (Addison-Wesley, 2002) USA, Boston US
I. Gorton, Essential Software Architecture, 2nd edn. (Springer, 2011) Berlin, Heidelberg L. Homan, Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison Wesley, 2003) Canada
N. Rozanski, E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (Safari book online, 2009) USA Sten and Per Sundblad, “Business Improvement through Better Software Architecture”, Microsoft developer network. https://msdn.microsoft.com/en-us/library/bb266336.aspx
Also you can enter SEI (Software Engineering Institute) library and search on software architecture and any other type of related architecture; you can then find a lot of webinars, videos, and articles, as, for example, SEI, “what makes a good software architect”, 2016
Ph. Kruchten, What do software architects really do. J. Syst. Softw. (2008). www.elsevier.com/
J. McGovern, S. Ambler, J. Linn, V. Sharan, E. Jo, Practical Guide to Enterprise Architecture, vol 1 (Prentice Hall, 2001)
For the part of Modern app architecture, I prefer to read:
https://www.docker.com/ The official site for Docker This site has all information and documentation about the Docker software. It also has the download links for various operating systems.
https://martinfowler.com/articles/serverless/
Chapter 2
Business Software Architecture (BSA)
Abstract Enterprises deploy business architecture capabilities. There is some confusion regarding the definition of business software architecture because it merges two terms: business and software architecture. In this chapter, there will be a brief definition of BSA with all related concepts. The basic roles of a business manager and a software architect are explained. Software architects take up an exceptional role in the world of IT. They are expected to know the technologies and software platforms on which their organizations run as well as the businesses that they serve. The relationship between business architecture and IT is described; the relationship between business architecture and IT is intertwined so that anyone talking about business architecture must be able to address how it is related to IT. Business architecture ecosystem will be defined in this chapter to represent the essence of the business. Also, pragmatic architecture shows how the architect adopts the best approach to the architecture.
At the end of the chapter you will learn:
• The concept of business software architecture
• The ecosystem for business architecture
• Software architect and business managers responsibilities in business software architecture
• The requirements for business architecture
• The concept of pragmatic architecture
2.1 Business Software Architecture
According to John Reynolds, business software architecture is “the structure of any software or set of programs used by business users and their customers to perform various business functions.” It focuses on the long-term maintenance and evolution of the business functionality, rather than simply on the functionality being delivered today. Also he defines a “business software architect” as a person who designs the structure of software that is used by business users and their customers to perform
© Springer Nature Switzerland AG 2020
21
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_2
22
2 Business Software Architecture (BSA)
various business functions, focusing on the long-term maintenance and evolution of the business functionality.
Picture the enterprise being a tree and business being its branches. Business Software Architecture, or BSA, is:
The structure of a business in any enterprise or organization used by business users as well as customers to perform the functions of the business. Software architecture is an important part of this definition because it helps the business reach its goals with a high quality.
This definition shows how software architecture supports building a business, and this is the main focus of this book. In the business world, the architecture of a software system is very important. It has a deep impact on the long-term success of the business using it. Such an impact can change related things such as:
• Costs of maintenance and development
• Availability of skills and expertise
• Competition with other businesses
A good architecture of the software enables a business to respond to the changes with a little additional cost.
2.1.1 Software Architects Need Business Education
In a business enterprise context, the objective of the business organization should be to light the way to an architect to make a decision. Such a relationship between the architect and the business needs the software architect to have some business
2.1 Business Software Architecture
23
education. For example, the business always plans for the desired return on investment (ROI) before the initiation of software development, and that is why the architect needs to understand the desired ROI to avoid making wrong decisions.
Return on investment (ROI) is a performance measure used to evaluate the efficiency number of different investments.
One of the important things that make the business “drive” is that it provides enough information about the effort of software development to make good decisions for that system.
2.1.2 Roles of Software Architects and Business Managers
in Business Software Architecture
Two important roles through building any business software architecture, especially when acquiring a quality from the software architectures, are the roles of the software architect and the business manager.
The responsibilities of the software architect are shown when building any software (including the business software). These responsibilities include:
• Dealing with the complexity of a system by representing it as an abstract view and dividing the system into a manageable model that shows the essence of the system by exposing important details and significant constraints.
• Maintaining control over the architecture life cycle in parallel with the project’s software development life cycle. Although an architect’s role may be obvious during the requirements and design stages of a project life cycle, he also monitors the loyalty of the implementation to the chosen architecture during all iterations.
• Making critical decisions that lead to design specific direction for the system in terms of implementation, operations, and maintenance. The critical decisions must be made by understanding and evaluating alternative options, and these decisions must be well documented.
• Working closely with managers to explain the software architecture solutions. This may be done by participating in business process activities, by using cost benefit analysis method, or by measuring the level of component/
architecture reuse between projects with the help from the software process improvement team.
Cost benefit analysis method (CBA) is an approach to estimate the strength and weakness of alternatives such as transactions and activities. It is used to specify an approach to achieve benefits while protecting savings.
2 Business Software Architecture (BSA)
On the other hand, the responsibilities of the business manager are:
• Managing and controlling a company’s activities and employees. In a big company, managers typically manage an individual department, such as marketing, sales, or production. In a smaller company, the business manager might manage operations in all departments.
• Overseeing the activities of workers, hiring, training, and evaluating new employees and making sure that a company meets its goals.
• Developing and implementing budgets, preparing reports for senior management, and ensuring the department complies with the company policies.
Managers also make sure their employees have the resources to complete their work.
2.2 Defining Requirements for Business Architecture
The important thing for business architects to derive the architecture of the system is what is called the architecture requirements. There are many studies that show that the effectiveness of costs stands on using requirements effectively and caring about the architectural decisions that lead to define goals and constraints. All of that will avoid mistakes in implementation. This is why defining requirements for architecture is very important. The first step is to identify all relevant business processes.
Part of identifying the processes is identifying the stakeholders. Business scenarios and stakeholders’ perspectives must be supported by the underlying structure of the business architecture.
A high-level view of the processes is enough to define the candidate architecture.
The next step is defining the boundaries of the system.
Now, the results are the candidate architecture, a set of identified business processes, and a mapping of those processes onto that architecture—defining the responsibilities of the system. This procedure will continue until meeting the requirements of the business architecture.
In conclusion, developing architecture requirements will provide clarity of the effective “traditional” requirements process for the business.
Another important thing is that the nature of business architecture requires a common approach to represent the essence of the business. Business architecture ecosystem can be adopted for that reason. OMG (Object Management Group), a special group for business architecture, explains business architecture ecosystem by their authors as a set of business artifact domain listed in Fig. 2.1.
Business ecosystem is “one or more legal entities, in whole or in part, that exist as an integrated community of individuals and assets, or aggregations thereof, interacting as a cohesive whole toward a common mission or purpose.”
2.2 Defining Requirements for Business Architecture 25
Units of
Vision
Organization
Projects
Suppliers,
Services and
Customers
Security
Products
Assets
Capabilities
Measures
Information
Rules and Policies
Business Process
Fig. 2.1 Abstract business views
For example, the concepts of capability, business process, semantics, rules, and
decision rules that appear in Fig. 2.1 define what a business does and how it does it.
Metrics and measures provide a way to assess the progress toward goals and track performance. The customer and the supplier are both responsible for the inside and outside of the enterprise. Products, services, and assets define what an enterprise produces, what is delivered to customers, what is received from suppliers, and what are the resources used internally to complete specific tasks and so on for other concepts. Every concept stands for specific task.
The relationship between business architecture and IT (Fig. 2.2) is intertwined so that anyone talking about business architecture must be able to address how these business artifacts are related to IT architecture. For example, application architecture artifacts include all of the business systems and services under the control of the IT organization that are used to deliver value to the business. Therefore, the business
2 Business Software Architecture (BSA)
Business viewpoint
IT viewpoint
Units of
vision
organization
projects
Application architecture artifact
Suppliers
Services and
,customers
security
products
Data architectutre artifact
assets
capabilities
measures
Shadow system artifact
Technical architecture artifact
Rules and
Information
Business
policies
process
Fig. 2.2 The intertwinement between business and IT views Business
Service oriented
architecture
architecture
Value stream
Service orchestration
service
capability
information
data
Fig. 2.3 Business architecture and service-oriented architecture architecture must provide ways in which the business and IT artifacts can be related as necessary to support a given set of objectives for a customer.
At the end, business and IT architecture can be interconnected to assist analysis, planning, and evolution of the ecosystems through visualization and simulation.
Figure 2.2 shows the relationship between business and IT.
Figure 2.3 shows how business architecture is depicted in service-oriented architecture.
2.4 Business Architecture’s Roles in Management
27
2.3 Pragmatic Architecture Today
Architecture definition starts early in the life cycle of the project, where requirements and the scope of the project are still not clear. This is why, when understanding the problem of the project, the architecture stage tends to be a more fluid activity than other stages in a life cycle.
Pragmatic architecture is about adopting the approach that works best for the architect, and what is best for one architect is not necessarily best for another architect. Also, the architectural activities of the adopting approach should be pragmatic because it must take into account the important issues such as lack of time or money, shortage of specific technical skills, and unclear or changing requirements.
The pragmatic architect focuses on essential concrete tasks and prioritizes the work according to the value it brings to the project to achieve the basic goals for functional and nonfunctional requirements. Essentially the pragmatic architect thinks of decisions and the effect of these decisions on the design and then considers these decisions as part of the solution to the problem.
I like the set of goals that is written in one IBM blog. They set the basic goals of p.r.a.g.m.a.t.i.c architectural activities as follows:
P: Promote collaborative work that involves all team members.
R: Reduce risks and uncertainties.
A: Adhere to minimalism and simplicity principles.
G: Gather key elements to outline the architecture during your initial timed-boxed iteration.
M: Modify the design throughout the development life cycle to adapt to emergent needs.
A: Address both functional and nonfunctional requirements.
T: Try out theoretical concepts and leverage past empirical experience.
I: Invest in known requirement instead of hypothetical future needs.
C: Concentrate on tasks that support the development team.
2.4 Business Architecture’s Roles in Management
Business can be defined as an activity that provides services or goods to meet society needs and aims to get profits. Business is classified according to size into types: micro, small, medium, and large. Note that the size depends on the number of employees working in the organization.
Every business in any organization has three main elements in common:
• The business is for the organization and this organization has its own goals.
• Each business has people working together.
• Each business has its own structure.
2 Business Software Architecture (BSA)
Helpful hints from Henry Ford about business:
• Coming together is the beginning.
• Keeping together is the progress.
• Working together is the success.
Important business objectives are survival, stability, growth, profitability, and efficiency.
Business architecture is part of enterprise architecture. The formal definition of business architecture is the one that comes from the Object Management Group. It is defined as “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.”
In order to describe the role of business architecture in the management, some basic concepts need to be explained.
Concept 1: Business architecture and its relation to the business process model
A business process model is the activity of representing processes of an enterprise; it is the most important part of business architecture.
The business process is composed of subprocesses which are composed of sets of activities. The output of the business process is the set of business goals, and from business goals the role of software architect starts.
The software architect derives the architecture from the business goals by choos-
ing the best design decisions according to it (Fig. 2.4).
Fig. 2.4 The relationship
between business
architecture and software
architecture
BUSINESS
ARCHITECTURE
ANALSIS REQUIRMENTS
BUSINESS PROCESS
MODEL
SOFTWARE
ARCHITECTURE
QUETHERING
REQUIRMENTS
2.4 Business Architecture’s Roles in Management
29
The business process is the best way to achieve software business alignment; it is a way to begin building the architecture of software according to business goals.
And if you can do that, the result from business processes is that the architecture will be strongly connected to business strategy.
So the important role of business architecture in management is building a solid architecture and supporting it with software architecture.
Concept 2: The role of the business architect
Business architects focus on business and IT alignment. Their role extends from addressing efficiency of business and IT issues to being involved with more strategic priorities. Also some of them focus on efficiency goals.
Business architects act as a link to the technology groups to enhance the development of business and have skills in business evaluation of technology. According to the business model, the business architect owns and develops business models which will clarify their technology strategy and participate in any business planning activity which makes use of these models.
At this point, it is clear that the business architect plays an important role in business architecture especially through working on process models and prioritizing the strategy.
Successful business architects capabilities should focus on:
• Business design
• Business management and strategy
• Technology strategy
• Portfolio, program, and project management
• Financial methods
Business architects are targeting business effectiveness through:
• Improved EA-business alignment
• Improved IT efficiency
• Improved business efficiency
• Improved business-IT alignment
2 Business Software Architecture (BSA)
Table 2.1 Examples on the success of BA result measures
Category
Metric examples
Business architecture values
1. Number of redundant components that reduced
2. Cost saved
3. Cost avoided
4. Number of identified risks
5. Customer satisfaction score
Business architecture
1. Business architecture stakeholders satisfaction score
progress
2. Number of business architects
3. Number/percentage of business architects trained
4. Number/percentage of required teams integrated with
5. Number of a required domains staffed with a business
architect
• Improved business effectiveness
• Widespread business transformation
Concept 3: Measuring the success of BA
The most important value that results from business architecture is to increase the organizational adoption and responsiveness of business architecture by the business, and this will expand the usage of the business architecture.
Also measuring the progress and effectiveness of business architecture can be useful information for business architecture leaders and practitioners to show the progression to their stakeholders.
There are two ways to measure the results of business architecture: the first is by measuring the effectiveness and the progress of a business, and this will be relatively simple and straight. The second is by measuring the value provided by the business architecture which is more challenging for some reasons, for example, some of business architecture results are intangible, some business results are hard to isolate, etc. Table 2.1 shows some examples on both types of measures..
In conclusion, these three concepts show the importance of business architecture in management; they begin by showing the relation of business goals and building a good software architecture and end with the measurement of a good business architecture going through the role of business architect in a project.
2.5 Summary
Business software architecture is a term that combines two basic concepts: business and software architecture. It is very important for enterprises that need to develop their business continuously to satisfy their customers. It can be defined as the structure of a business in any enterprise or organization used by business users as well as customers to perform the functions of the business. Software architecture is a domi-nator of this definition because it helps businesses reach their goals with high quality.
31
This definition has a deep impact on the long-term success of the business using it. Such an impact can change related things such as:
• Costs of maintenance and development
• Availability of skills and expertise
• Competition with the business
A good architecture of software enables a business to respond to the changes with little additional cost.
Business architecture ecosystem, defined in this chapter, represents the essence of the business. It is one or more legal entities that exist as an integrated community of individuals, or aggregations thereof, interacting as a cohesive whole toward common purposes.
Pragmatic architecture is about adopting the approach that works best for the architect. The architectural activities of the adopting approach should be pragmatic also. It must be pragmatic, because it must take into account the important issues such as lack of time or money, shortage of specific technical skills, and unclear or changing requirements.
Two basic roles of BSA are taken into consideration: they are software architects and business managers.
References
A. Randell, E. Spellman, W. Ulrich, J. Walk, Leveraging Business Architecture to Improve Business Requirements Analysis, A Business Architecture Guild Whitepaper (2014) W. Ulirich, N. Mchorter, Defining requirements for a business architecture standerd, A white paper (2010)
Further Reading
97 Things Every Software Architect Should Know, Collective Wisdom from the Experts (OReilly, 2009)
A guide to the Business Architecture Body of Knowledge http://c.ymcdn.com/sities/www.busines-
sarchitectutreguild.org/resource/resmgr/bizbokv6/bizbokv6glossary.pdf
L. Bass, Designing Software Architecture to Achieve Business Goals (Software Engineering Institute, Carnegie Mellon University, 2010)
R. Kaman, L. Bass, Categorizing Business Goals Software Architectures, Technical report CMU/
SEI (2006)
R. Kazman, L. Bass, Toward Deriving Software Architectures From Quality Attributes, Technical report CMU/SEI (1994)
Measuring business architecture success, whunde kuehn References published on cutter con-sortium (http://www.cutter.com, July 2016) Source URL: https://www.cutter.com/article/
path-successful-business-architecture-practice-491846
2 Business Software Architecture (BSA)
K. Sandkuhl, Aligning Software Architecture and Business Strategy with Continuous Business Engineering, Springer International Publishing, LNBIP 286 (2017), pp. 14–26. https://doi.
org/10.1007/978-3-319-60048-2_2
The Role of an Architect, www.architecturejournal.net, microsoft. 2008
W. Ulirch, Business architecture’s role in re architecturing technology solution author by (http://
www.cutter.com) (2017)
Chapter 3
Understanding and Dealing with Qualities
Abstract Quality attributes are the important factors that are used to establish the architecture. There is a constant need to redesign the systems because they are being difficult to maintain or to scale, they are too slow to continue their operations, or they are easy to hack. These are reasons constrain the quality attributes to be the architect’s goal through building the architecture of the product. Quality attribute is a measurable part to indicate that the system is satisfying the stakeholder’s requirement. The requirements that the architect needs are the ones that directly influence the architecture itself. They play an important role in determining the architecture of the system. Those requirements are called architecturally significant requirements (ASR); such requirements require special attention. Not all requirements have equal significance with regard to the architecture.
This chapter also focuses on the relation between architecture and quality. It shows that the degree of achieving the qualities of the system depends on its architecture; that is why architecture provides the foundation for building high-quality products. The main thing to discuss in this chapter is the meaning of trade-off between qualities and the models that are used to capture them.
Quality Attribute Scenario and Quality Attribute Workshop are two important tools that are used to gather information from stakeholders to reach the important qualities of the system. In this chapter, all the previous concepts will be described in detail.
At the end of this chapter you will learn:
• The meaning of architecturally significant requirement (ASR) and the method that is used to gather this type of requirement
• The meaning of trade-off and the model that is used to capture it
• Techniques that are used to gather information on quality attributes: Quality Attribute Scenario (QAS) and Quality Attribute Workshop (QAW).
© Springer Nature Switzerland AG 2020
33
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_3
3 Understanding and Dealing with Qualities
3.1 Definition of Quality
A quality attribute is a measurable property of the “goodness” of the product in terms of the stakeholders’ requirements (the types of stakeholders will be defined later in Chap. 5).
General software quality attributes include scalability, security, performance, and reliability. These are often informally called an application’s “-ilities.”
The qualities that will be mentioned are the ones that are relevant for the types of systems in the last three chapters of this book.
Quality attributes are closely related to the functionality of the product.
Functionality is what a product does, while quality is how it does it. Sometimes you see the term quality being used synonymously to the nonfunctional requirements in some books or articles. Specialists in this field do not really like this synonym; they say that a quality in its origin is functional and that was a solid reason not to refer to the quality as nonfunctional requirement.
Quality attributes are usually divided in two main groups based on the quality they are requesting. The first group is those that describe the system at runtime (sometimes called operational qualities) such as performance and usability qualities. The second group is those that describe some properties of the development system (sometimes called development quality) such as maintainability, understandability, and flexibility.
Software quality is 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.
3.2 Software Qualities for the Product
According to ISO/IEC 12207:1995, software product is defined as a set of computer programs and associated documentations. This is a very general definition; the product has to be defined from the business point of view as follows: Software product is the application that is built to accommodate the customers’
needs, and from here you can set the specific qualities for that application.
Going back to qualities, software quality for the product (SQP) can be defined as a specific quality for that product, and its specification comes from the stakeholder’s point of view to achieve business goals of the product to enhance its productivity.
To evaluate qualities in the product, quality model is used. Architects always build models in order to understand and measure these qualities. The long-term goal of this measurement is to judge these qualities. Some qualities like maintainability and understandability are very difficult to measure because they are affected by some factors such as user experience and education. This is why their internal
3.2 Software Qualities for the Product
35
External
Internal
Quality
Attribute
Reliability
Cyclomatic Complexity
Number of Error Messages
Reusability
Lines of Code
Depth of Inheritance Tree
Fig. 3.1 The external software quality attributes and their related internal quality attributes attributes such as size and complexity have to be measured first. Figure 3.1 represents the external qualities and their related internal attributes.
Cyclomatic complexity is a software metric used to show the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code. It is computed using the control flow graph of the program. Cyclomatic complexity may also be applied to individual parts in a program such as functions, modules, methods, or classes.
Figure 3.1 shows the relationship between internal and external quality attributes, but it does not show how these attributes are related. Three main conditions should be taken into consideration:
3 Understanding and Dealing with Qualities
• The internal attribute must be measured accurately.
• A relationship between the attributes’ values must exist.
• The relationship between internal and external attributes must be understood, validated, and expressed in terms of model or formula.
There is little information about the current use of systematic software measurement in industry due to many reasons, and some of which are:
• Difficulty in quantifying the return on investment (ROI) of introducing an organizational metrics program.
• Lack of standards for software metrics or standardized processes for measurement.
• In many companies, software processes are not standard and are poorly defined.
There are many other quality models used to measure the qualities; you can find these in suggested references.
No matter the type of business, every industry’s goal is to increase its return on investment (ROI). Software qualities are very important goals for the business for the following reasons:
Predictability: software qualities drive predictability, and architects need to build the system in a predictable way. This means do it once and do it right with less rework and less variation in productivity. The architect’s goal is to always build the product on time with productivity.
Reputation: this reason is a powerful driver. Some companies have a reputation in building their products with high quality, and of course customers always look for this type of companies. A good and solid reputation is hard to establish and easy to lose. Once the company has this feature, it will be a good driver for business.
Customer satisfaction: this is the most important reason from my point of view. The customer’s trust is very important and is strongly driven by the quality of software that the company produces and the services it provides.
3.2.1 Architecture Quality Attribute and Business Quality
Attribute
The general definition of business qualities is those qualities that are applied to a specific product to meet the customer’s expectations, and I think there is no big difference with the other types of qualities. Business quality goals are to add values for the business. For example, any car can take you from point A to B; what makes the difference are the features that are qualities other than transport, such as comfort Business goal is the achievement of the company in a specific time.
Business quality is a quality which satisfies the customer’s need.
37
and the usability of its components. Another benefit for qualities in business is that they reflect the nature of the process in the product; high-quality products always keep the company from wasting time and refactoring and rewriting software.
You should know the difference between business goals and business qualities.
Business goals describe what a company is supposed to achieve over a specific period of time. Businesses usually summarize their goals in their business plans.
While a business quality is a quality which satisfies the customer and aims for a specific purpose, the quality is meaningless if it is not related to a specific function.
3.3 Architecture and Quality
Software architecture base on quality attribute have a strong relationship in any system. This type of relation is specified through deriving software architectures from a concern of the qualities of that system. These qualities (portability, performance, modifiability, and scalability) are thought to be presented in any system, and this is shown when using the architecture.
The conclusion of this relation will be as follows:
• The achievement of the qualities of a system is connected with the software architecture for that system.
• These qualities can be achieved through the appropriate application of a set of operations.
• Specific architectures can be derived from an understanding of the operations, and the qualities need to be achieved by that architecture. Such operations are abstraction, compression, separation, and other process that are used through building architecture.
Fig. 3.2 shows how the architecture is constructed from requirements. The method transforms the requirement into allocations, each one isolated from other and then forming the architecture. The difficult part in defining qualities is that they cannot be described in abstract; for example, it is not right to say portability is the most important feature in the system. Two decisions must be taken into account through building the architecture: the first is determining the required qualities of the system and the second is prioritizing them according to scenarios that are written by the architect.
The important thing to know is that no quality is completely dependent on the design, nor is it entirely dependent on implementation or deployment. Satisfaction is the goal of the architecture, in addition to the correct implementation. For example, performance entails both architectural and nonarchitectural dependencies. It depends partially on how much communication is necessary among components (architectural dependency), partially on what functionality has been allocated to each component (architectural dependency), partially on how shared resources are
3 Understanding and Dealing with Qualities
Fig. 3.2 Software architecture
Requirement
base on quality attribute
Allocation
Allocation
Allocation
1
2
n
Collected
Together
Architecture
allocated (architectural dependency), and on implementing selected functionality (nonarchitectural dependency).
In conclusion, the degree of achieving the qualities of the system depends on its architecture; this is why architecture provides the foundation for building high-quality products, but this foundation will be with no benefit if there is no attention to the details. Also any change to the architecture to achieve one quality will impact (either positively or negatively) other quality attributes.
3.3.1 Architecturally Significant Requirement (ASR)
The architect builds the system in order to satisfy the system’s requirement. The most important thing is that the architect always looks for the specific type of requirements that affect the architecture: architecturally significant requirements (ASRs).
Architecturally significant requirements are those that play an important role in determining the architecture of the system. Such requirements require special notice. Not all requirements have equal significance with regard to the architecture.
ASR often, but not always, takes the form of quality attribute.
Methods that are used to gather ASR are:
3.3.1.1 Interviewing Stakeholders
The first thing the architect does is talking with the stakeholders. The architect starts his work by gathering information that are needed to produce the architecture.
39
have
Stakeholders
Business
Goals
which
lead us to
Quality
Attribute
Software
Requirements
Architecture
which are
the key
input to
Fig. 3.3 Stakeholder and software architecture
Interviewing stakeholders is the main way to learn what they need, to produce the architecture. The result of this interviewing is a set of architectural drivers and set of Quality Attribute Scenario (QAS) that the stakeholder prioritizes. Two important techniques are used to gather information from stakeholders: QAS and QAW.
Figure 3.3 shows that every stakeholder has business goals (sometimes called missions) and objectives that lead to quality attribute requirements and that will be a key input to software architecture.
3.3.1.2 Gathering by Business Goals
This type of method arises because business goals often lead to ASR. You must know that the business goals are the most important reasons for building the system.
Sometimes business goals are related to quality attributes that lead to building the architecture, and sometimes the architecture is built without any relation to quality attribute.
Figure 3.4 shows three output arrows from business goals:
• The first arrow shows that business goals often lead to quality attribute requirements, and this will differentiate the output product from other competitor products and let the developing organization capture market share.
• The second arrow shows that business goals directly affect architecture without needing the participation of quality attribute requirement at all.
• The third arrow shows no influence at all, for example, when needing to reduce cost.
In conclusion, the important arrows to the architect are the solid ones.
3 Understanding and Dealing with Qualities
3
Non architectural
Business Goals
Solution
Lead
ctly
s to architecturethrou
to architecture dire
2
1
gh qua
Leads
lities
Architectutre
Quality Attribute
Fig. 3.4 The ways of business goals lead to architecture
3.3.1.3 Gathering Requirements Through Utility Tree
Utility tree is constructed during ATAM evaluation to elicit and prioritize quality attributes. The word utility represents the goodness of the system. Under each quality there is a specific refinement related to that quality; for example, availability is related to hardware failure and backup/recovery refinements. The refinement you choose should relate to the system you build, under each refinement there is ASR
connected with it.
Note that ASR may exist in more than one place in the tree which means that ASR may relate to more than one quality. There is a scale used to evaluate the importance of the requirements, such as high, low, medium scales.
Utility tree is a way to categorize the quality attributes. Utility is an expression of the overall “goodness” of the system
3.3.1.4 Gathering ASR Through Requirement Document
Requirement documentation is a documentation that contains all the requirements of a certain system (or product). It is the place that records all candidates ASR. Not all requirements specified in the documentation are important to the architect; the architect needs the requirements that affect the design decisions to the architecture.
41
At the end, the ASR can be extracted from multiple techniques, two of which are focused on in this book: QAW and QAS. Other types of techniques are used through other stages: requirement documentation through requirement phase and utility tree through evaluating architecture phase.
3.3.2 Qualities and Trade-Offs
According to the business dictionary, 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.
Every software engineering project that is built or developed for specific customers involves several stakeholders of which the corresponding quality attributes are extracted. It is possible to facilitate existing knowledge and solutions for those quality attributes. Existing knowledge might contain suitable solutions or known conflicts with other quality attributes. The complexity and number of possible conflicts grows with the number of identified quality attributes and the number of ideologi-cally different stakeholders. In the general sense, trade-off means that you get something here, you give something there. The job of the architect plays an essential role between the business requirements and the realization, the implementation needs a person who aims to balance the trade-offs.As with architecture there are common accepted relations between software quality attributes; however, these relations have more or less impact based on what architectural pattern is used for the final solution. The stakeholders and the trade-offs are accepted with conditions, implying that the minimum value of quality attributes they need must be satisfied. If not, then the solution is unacceptable. For example, if usability is the most prioritized quality for the system, it is probable that efficiency may be affected. However, this situation is acceptable, as long as efficiency is still satisfied to the suitable level.
Many models are used to capture the architectural trade-off, for example, NFR
(nonfunctional requirements) framework. This type improves the application by structuring goals (nonfunctional requirements) and solutions. In the NFR framework, the terminology “operationalizations” is used. The solutions can affect the goals depending on the characteristics of the solution and the requirements that are shown through the goals. Figure 3.5 represents the performance goal with two sub-goals in the level below it. The solutions in the third level are associated with sub-goals and how each one is affected.
Determining what solutions affect other requested quality attributes is an essential part of selecting the final architecture to implement.
There are also model- or scenario-based architecture evaluation techniques used to achieve the prioritized quality attributes. Two of these models are SAAM
(Software Architecture Analysis Method) and ATAM (Architecture Trade-off Analysis Method).
The best solution is the one that affects the quality attributes the least.
3 Understanding and Dealing with Qualities
Performance
(quality goal)
space
Respnse time
increase
decresse
increase
Uncompressed format
indexing
Fig. 3.5 Operationalizations technique
3.4 Gathering Quality Attribute Information
As what is mentioned before, quality attribute requirements are very important to design software architecture. These quality requirements and design constraints are the main things for structuring the software architecture in the beginning. The two main techniques are Quality Attribute Scenario (QAS) and Quality Attribute Workshop (QAW).
3.4.1 Quality Attribute Scenario (QAS)
Quality Attribute Scenario (QAS) was first introduced as a technique to gather information for the qualities in an operational form in order to build an efficient architecture of the system. QAS appears to solve the untestable and overlapping concerns. Before going into more details in the concept of QAS, I want to describe what untestable and overlapping problems mean. The system should not be considered robust if it is only robust in one aspect. The quality attribute should be tested in all the circumstances. As for the concern of overlapping, the discussion must focus on which quality a specific concern belongs to. For example, is a system failure due to a denial-of-service attack an aspect of availability, an aspect of usability, or an aspect of performance? All these qualities would claim ownership of a system failure through a denial-of-service attack.
3.4 Gathering Quality Attribute Information
43
Source
stimlus
Artifact
response
Response measure
Environment
Fig. 3.6 Basic parts of QAS
Another problem may appear when each community has developed its own vocabulary.
The aim of a QAS is to capture the explicit and testable quality requirements in the same way use case scenarios do for functional requirements.
QAS consists of six parts (Fig. 3.6):
1. Source—an entity that produces a stimulus such as humans or a computer system.
