This chapter also focuses on the stakeholders and their relation to the business goals. Stakeholders (customers, developers, project managers, etc.) can be defined as any person who has a stake in the success and progress of the system.
Business goals are the parts that drive the methods of design and are the elements that shape the architecture. The important thing is that all business goals correspond
5 Managing Business Qualities
to quality attributes. Collaborative approach will be the shape between stakeholders and the organization, and this type of approach is coherent and driven by business goals especially the long-term goals.
Business goals are the state of events that users would like to achieve. Basic categories of business goals are:
• Contributing to the growth and continuity of the organization
• Meeting financial objectives
• Meeting personal objectives
• Meeting responsibility to employees
• Meeting responsibility to society
• Meeting responsibility to shareholders
• Meeting responsibility to states
• Managing market position
• Improving business process
• Managing the quality and reputation of products
• Managing change in environmental factors
StakehStakeholders are those people who have their roles and responsibilities in the success of the system and achieve the business goals. Finally, the importance of qualities in the business are concluded in four main pillars:
• Meeting customer’s expectations
• Managing a reputation
• Meeting the standards of the company
• Managing costs
References
L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 3rd edn. (Addison-Wesley, Upper Saddle River, 2013)
P. Clements, D. John, Mc Gregorand, L. Bass, Software Engineering Institute, Carnegie Mellon University, 14th international conference SPL 2010, Springer LNCS 6287 PP:393–403
L. Khaled, Achieving goals through architectural design decision. J. Comput. Sci. 6(12), 1424–
1429 (2010a)., 2010, ISSN 1549-3636 Science Publications
N. Rozanski, E. Woods. Software system architecture: Working with the stakeholder using viewpoints and perspectives. Prepared for doug.taylor@jeppesen.com. Douglas Taylor (2009)
93
N. Sanders, D. Reid, Operations Management:An Integrated Approach, 5th edn. (John Wiley & sons, New York, 2012). ISBN:9781118122679
I. Somerville, Software Engineering, 9th edn. (Addission Wiesly, Boston, 2011)
Further Reading
SEI on line training from SEI: Software Architecture: Principles and Practices, http://ww.sei.cmu.
edu/education-outreach/courses/online-training
Journal Papers
L. Bass, P. Clements, R. Kazman, R. Nord, Architectural, Business Cycle Revisted, Software Engineering Institute, Carengie Mellon (2009)
D. Gross, E. Yu, Evolving System Architecture to Meet Changing Business Goals: An Agent and Goal –Oriented Approach, University of Toronto. IEEE (2001). http://ieeexplore.ieee.org
L. Khaled, Driving architectural design through bussiness goals, software engineering researcher.
Int. J. Comput. Sci. Inf. Secur. 8(3), (2010b)
I. Liu, E. Yu, From Requirment to Architectural Design -Using Goals and Scenarios, University of Toronto (2001)
V. Omachouno, J. Ross, Principle of Total Quality (CRC Press, 2005) D. Susnienė, P. Vanaga, Integration of total quality management into stakeholder management policy and harmonization of their interests. Eng. Econ 44(4), 71–77 (2005). ISSN
1392–2785. Commerce of Engineering Decisions. http://inzeko.ktu.lt/index.php/EE/article/
R. Van Solingen, E. Berghout, The Goal Question Metric: A Practical Guide for Quality Improvement of Software Development (McGraw Hill, Chicago, 1999) M.K. Verma, Importance of Leadership In Total Quality Management (Mizoram University, 2014).
http://www.reseachgate.ney/publication/295531927
Chapter 6
Software Product Line (SPL)
Abstract To be competitive, most product engineering organizations must deliver product lines; it becomes an important and widely used approach for the efficient life cycle of the organization’s software product.
Software product line can be defined as a set of software intensive systems that share common features to satisfy the specific needs of a particular market. The quality attribute associated with this type of systems is variability which is a kind of modifiability qualities. Variability is the ability of a system to support the production of a set of artifacts that vary from each other in a preplanned way; its goal is to satisfy the variations and commonalities that are identified by the scope of the product line. Developers have to decide what type of variation mechanism is needed to encapsulate the variable parts, and this mechanism must be appropriate with the product strategy.
The SAAM method that is used to evaluate such type of products is described.
The evaluation of SPL will focus on the variation points to make sure they are suitable and allow products to be built quickly and to avoid unacceptable runtime performance cost.
At the end of this chapter, you will learn:
• The definition of SPL and its framework
• The definition of variability and its goal
• The method that is used to evaluate SPL system
6.1 SPL Definition
Previous chapters described the architecture and its relation to produce high qualities; the following chapters will show how this will happen in the practice, starting with software product line (SPL). SPL is another way of reusing the architecture across a family of related systems, and from the architecture’s point of view, SPL
reuses architectural assets. This has many benefits including reducing the cost of construction, reducing time to market, and increasing the quality of building. All these benefits will be the core of the SPL approach to system building.
© Springer Nature Switzerland AG 2020
95
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_6
6 Software Product Line (SPL)
Products
are built
share
are related
from
to
Core Asset
Architecture
Market Strategy
Fig. 6.1 Software product line
The Software Engineering Institute defines software product line as “a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.”
Figure 6.1 shows that the products relevant to a specific application domain share common architecture and are built from the same core assets (but there are other core assets as well).
Assets are engineered in a way to be shared across a product line that is used in any product; it works with a variation point (more details later in this chapter).
Any organization that develops software creates multiple software applications that have commonalities. Software product line was designed to manage these software products, and their commonalities are used to increase the benefits of the organization.
Core assets are defined as those reusable artifacts and resources that form the center for the software product line. Core assets often include, but are not limited to, requirement statements, the architecture, reusable software components, domain models, documentation, specifications, schedules, budgets, test plans, test cases, work plans, and process descriptions. The architecture is the key among the core assets.
The commonalties between applications are embodied in the core assets which are the reusable parts of the products. Core assets can be components, tools, framework, etc. Each core asset shares an architecture that all products in the product line will have in common. In addition, a process is attached to each core asset and recommends the optimal method of using the asset to build a product in the product line architecture. Although it is possible to create core assets without any adaptations, in many cases, we need to make some adaptations to these assets in order to use them in the broader context of the product line.
Software product line approaches increase benefits at the organizational level, for example:
6.2 A Framework for Software Product Line Engineering 97
• Productivity gains
• Decreased time to market
• Increased product quality
• Decreased product risk
• Increased market agility
• Increased customer satisfaction
These benefits give the organizations a competitive gain, and any organization that launches a product line should have specific and solid business goals that it plans to achieve through product line practice. Moreover, the benefits given above should support carefully with the achievement of these goals, because a software product line requires a start-up investment as well as ongoing costs to maintain the core assets.
6.2 A Framework for Software Product Line Engineering
A framework for software product line is a document that helps the software community in the aims of the software product line. The essential activities of SPL play an important role in the framework before going through developing a product line to achieve the product line development goals.
The essential activities of SPL are:
• Core assets development
• Product development
• Management at organizational and technical levels
In their essence, product lines engage core asset development and product development using the core assets, both under the guidance of technical and organizational management. Core asset development and product development from the core assets can occur in either order: new products are built from core assets, or core assets are extracted from existing products.
Core Asset Development
Core asset development is the creation and maintenance of the artifacts in the product line. These core assets are used to create systems that are equal to the quality standards of the product line. The goal of this activity is to create a capability within the organization to produce a specific type of application and thus will give the similar architecture. The outputs of this activity will then be input to the production development activity. One of the most important outputs is the core assets’ base which includes all the core assets that are the basis for the production of products in the product line. These core assets mostly include an architecture that the products in the product line will share, as well as software components that are developed for reuse across the product line. Requirement specifications and domain models are core assets, as is the statement of the product line’s scope. Web services and commercial off-the-shelf (COTS) software, if adopted, also form a core asset.
6 Software Product Line (SPL)
Core asset development
sector
Core assets and associated
process
Results in
Fig. 6.2 Core asset development sector
Product Development
Sector
on
Results
Depends
in
New set of assets if
needed
Products
Feedback on any
Core assets and associated
problems
process
Fig. 6.3 Product development sector
Management artifacts such as schedules, budgets, and plans also constitute core assets. Also, any infrastructure of production such as specific languages, tools, are considered core assets. Each core asset has an associated process that specifies how it will be used in the development of actual products (Fig.6.2).
Product Development
The product development activity depends on the output of the core asset activity. It involves the creation of products or systems from the core assets of the product line.
The core assets must be created if the system requires an asset that is not included in the core assets. If the existing core asset does not match the quality requirements of the product under development, the core asset must then be modified. Product builders have a responsibility to give feedback on any problems encountered with the core assets, so the core asset base remains working (Fig. 6.3).
6.3 Architecture and Software Product Line
99
Organizational
Software
area
Technical area
engineering
area
orchstrate
Fig. 6.4 Categories of practice areas
Management
Management (both at the organizational level and the technical level) plays an important role in the success of a product line. Organizational management must create an organizational structure that makes sense for the enterprise and makes sure that the organization receives the right resources. Organizational management also arranges the technical activities and iterations between the essential activities of core asset development and product development. On the other hand, technical management manages the core asset development and product development activities by ensuring that those who build core assets and products are connected in the required activities, follow the processes defined for the product line, and collect data sufficient to follow the progress. Management includes managing specific projects within the product line as well as all product line managers.
To build a software product line, you must carry out the three essential activities described previously, and you also need to know the type of work the organization does in order to successfully carry out the essential work of a product line; this is called a practice area. A practice area is a collection of activities that makes the essential activities more achievable.
The practice area provides starting points from which organizations can make (and measure) progress in adopting a product line approach for software. There are three categories of practice areas (Fig. 6.4): 1. Software engineering practice areas are those necessary for applying the suitable technology to create and evolve both core assets and products.
2. Technical management practice areas are those necessary for managing the creation and evolution of the core assets and the products.
3. Organizational management practice areas are those necessary for managing the complete software product line effort.
Each of these categories requires a different skill set for the people who must carry them out. The categories represent disciplines of the work.
6.3 Architecture and Software Product Line
Every time you make a change to a system, you are reusing its architecture, and you will see that clearly through sets of reusable assets (core assets, defined previously) in the SPL architecture. These sets can be used across many multiple systems. What
6 Software Product Line (SPL)
make core assets work quickly are the built-in variation points (will be explained later in this chapter) or places where they can be quickly tailored in preplanned ways. Once the core assets are in place, building the system becomes a matter of accessing the appropriate assets in the core asset base, exercising the variation points to configure them as required for the system being built, and then assembling that system.
6.3.1 What Makes a Software Product Line Succeed?
A product line succeeds because the commonalities shared by the software products can be exploited through reuse to achieve economies of production. The products are built from common assets in a predetermined way. Reusing of these commonalities includes:
• Requirements: most of the requirements are common early in the life cycle of the system.
• Architectural design: the quality goals of the system such as reliability and performance are inhibited once the architecture is created. That is why an architecture represents a large investment of time from the organization’s most talented engineers.
• Software elements: software elements are applicable and reusable across individual products. It includes initial design work such as designing the element’s interface, its documentation, etc. The successful design is captured, and unsuccessful designs are avoided.
• Modeling and analysis: performance models, schedule analysis, distributed system analysis, network load, and so forth can be reused across products in the product line.
• Testing: test plans, test processes, test cases, test data, and so forth can be established once for the product line.
• Project planning: budgeting and scheduling are more predictable because experience is the best sign of future performance. Planning the team’s size and composition is easily done from past experience.
Artifact reuse enables reuse of:
• Processes, methods, and tools: configuration control, facilities, documentation plans, tools, system generation, deployment processes, and coding standards are all established once for the whole product line.
• People: the people’s experience is applicable across the entire product line.
• Exemplar systems: deployed products serve as demonstration prototypes of the system.
• Defect elimination: product lines enhance quality because each new system takes advantage of the defect elimination for the entire family.
All of the above reuse helps products begin more quickly with high quality and more expected budget and schedule.
6.4 The Quality Attribute of SPL (Variability Quality) 101
The software architecture plays the important role in the set of core assets. Product line architecture must apply to all members of the product line—even if their functions and quality attributes are different. Also, the architecture of the product must define the commonalities and hold the variations between the products in the product line.
The architects of the software product line need to think about the following things:
• Identifying variation points in the products
• Supporting variation points by introducing the variation mechanism
• Evaluating the architecture for product line suitability
These roles will be explained later in this chapter.
6.4 The Quality Attribute of SPL (Variability Quality)
Every system has its own qualities. Variability is the most obvious quality associated with SPL (in spite of other existing qualities such as performance and security).
Variability is a special form of modifiability; it is the ability of a system to support the production of a set of artifacts that vary from each other in a preplanned way.
Sometimes, it can be defined as the ability of core assets to adapt usages in the different contexts that are within the scope of the product line; its goal is to satisfy the variations and commonalities that are identified by the scope of the product line.
Product line scope can be defined as a statement about what systems an organization is ready to build as part of its line and what systems it is not ready to build. The scope is driven by strategic planners, domain analysts, marketing, and the need to build multiple products that are similar. It is very important to the architect because it defines what is common across all members of the product line and what is different.
Table 6.1 shows the general scenario for variability quality. This is a general table; it can be used as a starting point for any future work.
SPL is described by the following representations:
Variability point
the specific points where the variability takes place. It is the difference between two or more products. Differences can involve:
• Functions
• Quality attributes
• Platforms
• Interfaces
6 Software Product Line (SPL)
Table 6.1 General scenario for variability
Portion of
scenario
Possible values
Source
Requests variability
Stimulus
Requests to support variations in hardware, technologies, feature sets, quality attributes, etc.
Artifacts
Affected assets, such as requirements, architecture, component x, etc.
Environment
Variants are to be created at runtime, build time, and development time Response
The requested variants can be created
Response
A specified cost and/or time to create the core assets and to create the measure
variants using these core assets
Ideally, variation points are identified during requirements, elicitation, and analysis. In reality, identifying variation points must be a continuing activity.
Variants
a set of alternative variability; all variability scenarios specify variations that have to be included in a range of product. For example, the customers of a home automation system can decide on the language of the user interface before the system is installed.
Variability point:;
language
Variants:
Variant :
Variant:
English
spanish
french
The relation between variability point and variants
6.4.1 The Goal of Variability
The goal of variability in SPL is to increase return on investment (ROI) for building and maintaining products over a specified period of time. The cost of producing products includes the cost of building the core assets on which they are based on and that is why the variation mechanism (described later) will affect both the cost of building the core assets and the cost of building products from core assets.
ROI can also be used in producing the higher quality. Higher quality needs more cost to be built, but this will satisfy the customer’s requirements, enhance reputation for quality, and cause fewer defects to fix and other goals that increase the ROI.
6.4 The Quality Attribute of SPL (Variability Quality) 103
6.4.2 Variation Mechanism
As a part of the core asset design, the developer has to choose a variation mechanism to encapsulate the variable parts; this mechanism must be appropriate with the product strategy. For example, if implementing a mechanism needs 2 months but the product must be delivered in 1, then choosing that mechanism is not suitable. To help the decision process, a variation mechanism has a set of properties, some of which are:
• The cost to implement the mechanism
• The cost and time to exercise the mechanism
• The group of users that use the mechanism
• The effect of the mechanism on quality
and so on.
The important thing is the information required to make the decision on using the variation mechanism. Organizations that use product line should have a catalogue of variation mechanisms that includes rating and stakeholders related to that organization. Table 6.2 shows some variation mechanisms.
The cost values are relatively value, for example, the cost to exercise parameter values (low) is less expensive than using a new class using inheritance (high).
The architect of a product line should document these mechanisms; it will be under the section of variability guide in the documentation. The variability guide should describe each variation mechanism, how and when to exercise it, and what variations it supports. The documentation also has to explain valid and invalid variation choices if certain combinations of variation are disallowed.
Variability guide is a section in the documentation; it shows how to exercise any variation points that are part of the architecture shown in the view.
Table 6.2 Variation mechanism examples
Variation
Properties to be built into
Properties to be exercised when building
mechanism
core asset
products
Inheritance
Cost: medium
Cost: medium
Skills: object oriented
Tools: compiler
languages
Stakeholder: product developers
Templates
Cost: medium
Cost: medium
Skills: abstractions
Tools: none
Stakeholder: the administrator of the
system, developers
Aspects
Cost: medium
Cost: medium
Skills: aspect oriented
Tools: aspect oriented language compiler
programming
Stakeholder: product developers
6 Software Product Line (SPL)
The documentation for product line architectures will also include:
• Documentation for all core assets (requirements, design, and so forth)
• Variation points: Where variation occurs in the products and how it is accommodated
• Production plan: Describes how products will be built or instantiated 6.5 Evaluating a Product Line Architecture
One of the most important things in software system development today is the quality of that system. The purpose of evaluation is to analyze the software architecture to identify the possible risks and verify that the quality requirements have addressed the design of the system.
The architecture of a software product line is one of its most important artifacts; it represents an abstraction of the products that can be generated. It is important to evaluate the quality attributes of product line architecture for the following reasons:
• Increasing the productivity of the product line process and the quality of their products.
• Decreasing their time to market.
• Improving the handling of the product line variability.
• Evaluating product line architecture can serve as a basis to analyze the manage-rial and economical values of a product line for software managers and architects.
The evaluation of SPL will focus on the variation points to make sure they are suitable and allow products to be built quickly and that they avoid unacceptable runtime performance cost. If the evaluation depends on a scenario, then it will be expected to gather scenarios that involve instantiating the architecture to support different projects in the product line.
Software product line has different quality attribute requirements; evaluating the architecture must have the ability to satisfy all the combination of these qualities.
SEI developed the following scenario-based methods and for different types of qualities:
• SAAM: Software Architecture Analysis Method
• ATAM: Architecture Trade-off Analysis Method
• ARID: Architecture Reviews for Intermediate Design
The three methods have been applied for years on lot of projects of all sizes in different types of domains, so you can use these methods in SPL architecture. When evaluating the architecture of product line (the core assets specifically), you need to be able to know whether it is appropriate not only for that particular product but for
105
the continuation of the products to come. SAAM method concentrates on modifiability in its various types (portability, subsetability, and variability) and functionality.
It may be worthwhile to evaluate product line architecture:
• Immediately after the architecture for the entire product family has been created
• When creating the first product “instance” using the architecture
• After major revisions to the architecture
• When market demand or stakeholders change significantly
When a new product that lies outside of the product family is being proposed, the product line architecture should be evaluated to see if it will suffice for the new product.
At last, you must know that two groups of people are involved in architecture evaluation:
The first is the evaluation team: those are the people who will analyze and evaluate the system.
The secon d group is the stakeholders: these are the people interested in the architecture of system.
6.6 Summary
The Software Engineering Institute defines software product line as “a set of software- intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.”
A framework for software product line is a document that helps the software community in the aims of software product line. The essential activities of SPL play an important role in the framework before developing a product line to achieve the product line development goals.
The essential activities of SPL are:
• Core assets development
• Product development
• Management organizational and technical levels
A product line succeeds because the commonalities shared by the software products can be exploited through reuse to achieve economies of production. The products are built from common assets.
The evaluation of SPL will focus on the variation points to make sure they are suitable and allow products to be built quickly and to avoid unacceptable runtime performance cost. If the evaluation depends on scenario, then it will be expected to gather scenarios that involve instantiating the architecture to support different
6 Software Product Line (SPL)
projects in the product line. SEI developed the following methods for scenario-based methods and different types of qualities:
• SAAM: Software Architecture Analysis Method
• ATAM: Architecture Trade-off Analysis Method
• ARID: Architecture Reviews for Intermediate Design
SAAM concentrates on modifiability in its various types (portability, subsetability, and variability) and functionality.
References
P. Clements, R. Kazman, M. Klein, Evaluating Software Architectures: Methods and Case Studies (Addison Wesley, 2002)
J. Frank et al., Software Product Line Engineering: Foundations, Principles and Techniques (Springer Science & Business Media, 2005)
L. Northrop et al. “A framework for software product line practice”, version 5.0 (2012)
Further Reading
Sh. Cohen, P. Krut, Managing variation in services in a software product line context. Technical
notes, CMU/SEI (2010). http://www.sei.cmu.edu/
D. Reis, P. Valle, Variability and Software Product Line Architecture (University of São Paulo,
Institute of Mathematics and Computer Science, 2016). https://edisciplinas.usp.br/pluginfile.
php/977101/course/section/268869/Seminar5_SPL_SPLA.pdf
L. Sion, G. Jong, Systematic Quality Trade-off Support in the Software Product-Line Configuration Process (ACM, 2016). https://doi.org/10.1145/2934466.2934481. ISBN
978-1-4503-4050-2/16/09
Chapter 7
Internet of Things (IoT)
Abstract The origin of the Internet of Things dates back to Kevin Ashton in 1999.
Ashton is an innovator and consumer sensor expert who describes the IoT as a network that connects objects in the physical world to the Internet; but this definition is still seen as odd. In the twenty-first century, computers can sense things for themselves, for example, GPS-based location sensing. This chapter describes the architecture of IoT with its basic characteristics. Two qualities of IoT with their QAS’s will be defined: interoperability and modifiability.
DYAMAND, a case study for IoT, will be explained in detail to solve the interoperability problem. Its requirements and architecture will be described in detail.
What makes the content of this chapter different from other IoT books is that it takes the software architecture’s point of view, and that is the main core for this book.
7.1 IoT Definition
Internet of Things is a new revolution of the Internet. It can be defined as a type of network that connects anything with the Internet, and this will be based on protocols through sensing equipments in order to exchange information and communication to achieve smart recognition. The goal of IoT is to connect things anytime, anyplace with anything using any path or network and any service. The important thing to take into account is that IoT is not a single technology; it is a combination between hardware and software technologies; without these technologies IoT would not be possible.
IoT provides solutions depending on the integration of information technology (that refers to hardware, software that is used to store, retrieve, and process data) and communication technology (which includes electronic systems that are used to communicate between individuals and groups).
© Springer Nature Switzerland AG 2020
107
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_7
7 Internet of Things (IoT)
How does Kevin Ashton1 define IoT?
“Internet of Things means sensors connected to the Internet and behaving in an Internet-like way by making open, ad hoc connections, sharing data freely and allowing unexpected applications, so computers can understand the world around them and become humanity’s nervous system.”
The main vision of IoT is that things are able to talk and their data can be processed to perform the specific tasks.
Finally, some sources mention which technologies and protocols can be used for the IoT, such as the Internet, cloud computing, RFID, IPv6, and much more, but these will be excluded since they are out of the scope for this book.
Cloud computing: Cloud computing is a type of computing that relies on shared computing resources rather than having local servers or personal devices to handle applications.
RFID: Radio frequency identification devices are wireless microchips used for tagging objects for automated identification.
IPv6: Internet Protocol version 6 is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet.
The fundamental characteristics of the IoT are:
• Things-related services: The IoT is capable of providing things-related services within the constraints of things, such as privacy protection between physical things and their associated virtual things. To provide this fundamental within the constraints of things, both the technologies in the physical world and the information world will change.
• Interconnectivity: In IoT, anything can be interconnected with the global information and communication infrastructure.
• Heterogeneity: The devices in the IoT are heterogeneous. They can interact with other devices or service platforms through different networks.
• Dynamic changes: The state of devices change dynamically, for example, connected and/or disconnected. The number of devices can also change dynamically.
1 Kevin Ashton is an innovator and consumer sensor expert who coined the phrase the Internet of Things to describe the network connecting objects in the physical world to the Internet.
7.1 IoT Definition
109
• Scale: The number of devices that need to be managed and that communicate with each other will be larger than the devices connected to the current Internet.
• Safety: This includes safety of personal data and safety of physical well-being.
Security of endpoints, networks, and data movement.
• Connectivity: Connectivity enables network accessibility and compatibility.
Accessibility is getting on a network, while compatibility provides the common ability to produce and consume data.
Despite the fact that the architecture layers of IoT are not in the scope of this book, it will be described briefly in order to know how scalability and other qualities can perform through IoT. Some references describe three layers, others describe six, but in general IoT must have layers to obtain information from the physical world layer for transferring data and must also have a layer for using this data. This book divides the architecture of IoT into four layers (Fig. 7.1): Smart Device/Sensor Layer
This is the lowest layer. It is made up of smart objects that are integrated with sensors. Sensors are grouped according to their purposes, for example, environmental sensors, home appliance sensors, etc. Those sensors have the ability to measure the physical property and then convert it to signals that can be understood by instru-ments. Most sensors need connectivity to the sensor gateway which can be in the form of LAN (Local Area Network) such as Wi-Fi or PAN (Personal Area Network) such as ZigBee. Some sensors do not require a connection to the aggregators; their connectivity to backend servers/applications can be provided using wide area network (WAN) such as GSM (Global System for Mobile communication). Sensors that use low power and low data rate connectivity typically form networks commonly known as wireless sensor networks (WSNs).
7 Internet of Things (IoT)
Application layer
IoT applications
Management service layer
Business and process rule engine ,analytic tool, data management, data mining…….
Communication layer
Network and transport capabilities
Sensor layer
Contains amart objects integrates with sensors and devices
Fig. 7.1 Architecture layers of IoT
Gateways and Networks
Large numbers of data produced by small sensors will require high performance and robust wired or wireless network infrastructure as a transport medium. Multiple networks with different technologies and access protocols are needed to work with each other in a heterogeneous configuration. These networks can be in the type of a private, public, or hybrid models and are built to support the communication requirements for latency, bandwidth, or security.
Management Service Layer
This layer enables the processing of information possible through controlling the security, analytic, process modeling, and management devices. The most important feature of this layer is the business and the process rule engines. IoT brings connection and interconnection of objects and the system together presenting the information in the form of data, events, current location, and traffic data. Some events need filtering, while others need response to the immediate situations. Rule engines support the formulation of decision logics.
Application Layer
This layer covers the smart environmental spaces such as transportation city, factory, and emergency health care.
The thing you must know that the security features must include for all four layers beginning from sensor layer ending with the application layer, this feature prevents systems from hacking by unauthorized persons, and of course this will reduce the possibility of risk.
111
Three Cs impact of IoT to the business and society:
Communication: IoT communicates information to people and systems and data from sensors that can monitor a person’s signs; location is very important for items that move.
Control and Automation: in many cases, a consumer or business is able to control a device remotely, for example, controlling the temperature of the environment by a consumer.
Cost Saving: with new sensor information, IoT can save money by minimizing the failure of equipments and permitting the business to perform planned maintenance. Many other ways can be used by IoT to save money.
7.2 Architecture and IoT
The goal of software architecture is to design a system that meets the quality attributes. Choosing one style for software architecture will show different levels of quality attributes for the same system. This is very important for IoT systems because it can include different kinds of categories, for example:
• Wireless sensor/actuator networks; sensors provide data either to users or actuators. Actuators receive data either from sensors or from users.
• RFID enable tracking.
• Smart homes.
• Connected cars.
• Devices that connect via Bluetooth-enabled mobile phone to the Internet.
The result from that is that there is no single architecture that suits all these areas and the requirements of each area. It always depends on the goal of quality requirements. Also, it is hard to provide reference architecture for the entire IoT system.
The terms reference model and reference architecture will be described in
A reference model is a division of functionality into elements and the data flow between them; it is the domain analysis.
Reference architecture is a reference model that is mapped onto the software elements that implement the functionality defined in the model. It is a mirror to the software architecture.
7.3 Basic Qualities of IoT
Previously, I talked about quality attributes in details. In order to build systems that support the required qualities, you need a way to express the quality attributes and understand how these qualities can be achieved. In this section, two important
7 Internet of Things (IoT)
Fig. 7.2 Reference
architecture
Reference Model
Architectural Pattern
Reference Architecture
Software Architecture
qualities related to IoT will be discussed: interoperability and modifiability. Also, security is an important quality to IoT; description of general and concrete scenarios for security will be in Appendix A.
7.3.1 Interoperability Quality
Interoperability is the ability of more than two systems or components to exchange meaningful information through interfaces in a specific context. In this definition, there is no limit on exchanging data (syntactic interoperability) but having the capability to interpret data being exchanged (semantic interoperability). Any discussion regarding interoperability needs to identify with whom, with what, and under what circumstances; that is why the context has to be included throughout exchanging.
Interoperability is a runtime quality attribute, the architect always needs to design the system to be interoperable with other systems, and that is done through bound-ing the system that is built with another system later in the life cycle. However, sometimes systems will connect early with the architect’s system. In that case, quality will be produced at the design time.
Regarding interoperability in IoT, Internet of Things provides connectivity between people, processes, and things, but we are far away from speaking the same language. Existing solutions cannot easily talk to each other. Probably, the greatest
7.3 Basic Qualities of IoT
113
difficulty for large-scale adoption of IoT is the lack of interoperability. It prevents companies from delivering services that enable full connection to the digital world.
Interoperability can be on different levels. Systems can simply exchange data and call each other’s functions. They can also work together as a single business application with integrated communication channels, state synchronization, and a common interpretation of the data. For example, in the banking sector, the success of electronic and mobile payment systems largely depends on the interoperability with the back office systems and the secure handling of the communication between them.
Some important reasons why the system has to be interoperable are:
• Increasing level of reusability because interoperability enables using component-based software engineering.
• Sometimes systems need to interoperate with the created system even when the architect does not know anything about those systems, for example, Google Map application.
• In IOT, the architect often builds integrated systems where applications use capabilities from existing systems. For example, connecting medical sensors with systems that process the data and secure event servers that send out alerts.
General quality attribute scenario for interoperability is described in Fig. 7.3.
Now let us apply this quality on a smart medicine cabinet: A medicine cabinet is able to send an alert to a doctor when an at-home patient’s supply of drugs runs low. The new instruction is verified by that doctor and forwarded to the pharmacist who sends a new supply of drugs with a courier.
This needs a huge number of interoperability requirements:
• The drug recipient talks to the cabinet of the system.
• The medicine cabinet interacts with the doctor’s patient system.
• The pharmacist communicates with the dispatching service of the messenger company.
To make it even more complex, there are many different ways to notice the supply level of drugs, and there are many existing patient systems used by doctors.
Let’s focus on the interoperability scenario between a drug distributor device and the smart medicine cabinet. Pharmaceutical companies have different types of smart Artifact
A system that wish to interoperate
Stimulus
Response
Source
A request to
Environment
Response
System that
exchange
It can either
measure
initiates a
information
It can be at run time
accepted
Either accepted
request
among
or from the beginning
Rejected or
%
systems
logged
Rejected%
Fig. 7.3 QAS for interoperability
7 Internet of Things (IoT)
medicine bottles or tablet strips. This is also an area of innovation with new sensors and protocols appearing on the market regularly. Table 7.1 shows the concrete interoperability QAS
There are two categories of interoperability tactics: locate and manage interfaces
Table 7.1 Concrete scenario for interoperability quality
Source
The drug point to a device, for example, a smart medicine bottle
Stimulus
Sends a message that includes an identification to the drug and the remaining supply level
Artifact
Smart medicine cabinet local control system
Environment The drug distributor unit discovered at runtime
Response
The smart medicine cabinet if the received data is complete and matches the data in the database
Measure
For the new drug that is discovered before:
95% of the notifications has to be correct and complete
A maximum 5% can be rejected with a notification to the smart cabinet support center
orchestrate
……...
Interface mangment
interoperabilty tactics
locate
Discover
service
Fig. 7.4 Tactics for interoperability
115
Note The basic goal of these tactics is that after requesting to exchange information, the request must be handled correctly.
Figure 7.4 shows that there is only one tactic for locate and discover service. It is used when systems that interoperate must be discovered at runtime. On the other hand, managing interfaces has two tactics: orchestrate which is used as a control mechanism to invocate specific service and tailor interface which adds or removes capability to an interface.
7.3.2 Modifiability Quality
Modifiability is a design quality attribute that can be supported by mechanisms in all phases of the system life cycle. The goal of modifiability is to make flexible systems that can hold change at a minimum cost.
Modifiability has great effects on business competitiveness. A modifiable architecture also creates opportunities for reusable components and can simplify maintenance because the small components are less complex and, if well designed, have fewer dependencies on other components. To plan for modifiability, the software architect asks four main questions:
Who Makes the Change?
Different stakeholders can implement changes to a system: software engineers, system administrators, field engineers, and users.
What Is the Probability of the Changes?
A system cannot plan for all potential changes; that is too expensive, and it may suffer from quality attributes problems. The architect has to make the tough decisions about which changes are probable and which changes are to be supported.
What Can Change?
A change can occur at any aspect of the system.
How Is the Cost of Change Measured?
Two types of costs must be taken into consideration through dealing with modifiability: the first is the cost of introducing the mechanism(s) to make the system more modifiable and the second is the cost of making the modifications using the mechanism(s). The dynamic environment of IOT systems will lead to adaptive architectures that need to support modifiability. This will be the subject of the DYAMAND case study, which you will discover in the next section. Concrete modifiability scenario will show in Fig. 7.5.
The impact that appears in the response measure will show that modifiability has a big impact on business competitiveness. It determines the effort to produce the next release, and it will shorten the time to market for releasing new features with less cost. Table 7.2 represents the general scenario for modifiability.
7 Internet of Things (IoT)
Artifact
code
Source
Stimulus
Environment
Response
Response
Developer
Needs to
measure
change UI
At a design time
Change made
In 2 hours
Fig. 7.5 Concrete scenario for modifiability
Table 7.2 General scenario for modifiability
Source
End user, developer, system administrator
Stimulus
An order to add/delete/modify functionality or change a quality attribute, capacity, or technology
Artifacts
Code, data, interfaces, components, resources, etc.
Environment
It can be at any time in the life cycle, it may be at runtime, compile time, build time, etc.
Response
One or more of the following:
Make a modification
Test a modification
Deploy a modification
Response
Cost in terms of size, complexity of affected artifacts, effort, calendar time measure
Money, etc.
There are many tactics to control modifiability; their goal is to control the complexity of change (Fig. 7.6):
• Size of the module – splitting the module will reduce the cost of making a modification to the module that is being split. The split is also chosen to reflect the type of change that has to be made.
• Increasing cohesion – increasing semantic coherence; if the responsibilities A and B in a module do not provide the same purpose, one of them should be put in a different module.
• Reducing coupling – the main tactics for reducing the coupling are: 1. Encapsulation: it introduces an explicit interface to a module. The interface designed to increase modifiability should be abstract with respect to the details of the module.
2. Using an intermediary: breaks a dependency, the type of intermediary depends on the type of dependency, for example, in publish-subscribe, data repository is used to separate readers of data from writers of that data.
3. Reactor: is a tactic undertaken where two modules are affected by the same change because they are duplicates of each other.
4. Restrict dependencies: restricts the modules which a given module interacts with or depends on.
117
Defer Binding
Increase cohesion
modifiability tactics
Reduce coupling
Reduce size of module
Fig. 7.6 Tactics for modifiability
5. Abstract common services: where two modules provide similar (but not quite the same) services, any modification to such services will be in one place, and this may be cost-effective.
6. Defer binding: in general, an architecture that equips modification late in the life cycle will cost less than doing this earlier in the life cycle.
Note The main goal of this tactic is that when change is requested, the change must be made and deployed.
7.4 DYAMAND: Case Study
In the real world, a wide range of technologies that want to state IoT rise, but, as said before, all of these technologies have a basic problem which is lack of interoperability with each other, and this causes problems. DYAMAND (Dynamic Adaptive Management of Network and Devices) solves this problem by combining these technologies in order to be used by application.
DYAMAND is a software platform that enables application developers to be more easily connected in order to develop the application without any efforts.
Before going through details, the brief definition of the framework of DYAMAND
needs to be explained in order to show how it works. SDPs (Service Discovery Protocols) are a part of this framework; the framework acts as a middleware layer UPnP (Universal Plug and Play) describes the devices that work with a computer system as soon as they are connected. It uses network protocols to allow a wide range of devices to interconnect with each other.
7 Internet of Things (IoT)
between the application developer and the controllable devices and permits to translate devices/services as declared by one SDP instance to another, while abstracting the SDP toward the application developer.
SDPs are a protocol that enables dynamic discovery of services in a network; DNS-SD (domain name system service discovery) is an example of this protocol.
SDPs are composed of three basic functions:
1. Discovery: the protocol must offer the discovery of devices and/or services.
2. Control: SDP allows controlling the services it discovers (after supposing that the interoperability issues of different discovery/service models and different service type representations were solved and services could be discovered uniformly). If SDP does not provide control, an external control protocol must be used.
3. Eventing: SDP embeds events in it; for example, the General Event Notification Architecture (GENA) that is embedded in UPnP supports the application to receive events without knowing about the service.
Going back to the DYAMAND, runtime modifiability is the most important quality attribute the framework needs to take into consideration. This is why plug-in The term “POJO” initially denoted a Java object which does not follow any of the major Java object models, conventions, or frameworks. Nowadays “POJO”
may be used as an acronym for “Plain Old JavaScript Object,” in which case the term denotes a JavaScript object of similar pedigree.
architecture was developed, to take into consideration the possible differences between SDPs, devices, and services. Also the framework should deliver API that will be simple to use and easy to understand. Plug-in can be in three types:
• SDP plug-in which is responsible to implement (parts of) SDP
• Translation plug-ins which are responsible for translating SDP-specific objects into generic ones and vice versa
• Application plug-in which is responsible for implementing a specific use case All three types of plug-in will go through device/state change translation cycle.
After this cycle, the framework will notify the application plug-in of translated services or state changes.
Sometimes command translation is used in the framework. Here, the operation will go in the opposite direction which means that the application plug-in needs to interact with a service; it retrieves the POJO associated with the service (just acts with java interface). Using POJO improves the usability of the framework.
As a student, all you need to know is a simple background on how the framework of DYAMAND works from the point of view of application developers; even developers do not need to understand how SDP works to develop the application.
119
7.4.1 DYAMAND Requirement
Software requirement from the DYAMAND point of view starting with the use cases of DYAMAND. From the perspective of DYAMAND, a limited set of use cases exist.
You can conclude from Table 7.3 that the basic actors of DYAMAND are two: devices and applications. Three groups appear in the table. The first group of use cases is to discover the devices; an application must be able to discover the availability of devices to be able to control them ( use cases 1–3). After that, an application has to be able to execute that device effectively ( use cases 4–6). Adding, removing, and updating new technologies and functions that relate to the modifiability of the system of software will be in use cases 7–9.
Now going through the quality attribute, you see the performance quality of DYAMAND as in Fig. 7.7
Performance requirement is an essential quality for the application using this framework. Figure 7.7 shows that whenever a device notifies its availability, the system translates the device to its generic representation and notifies the interested application within 200 ms.
Apart from performance requirements, modifiability (that is tightly coupled with interoperability) is essential for the system. Whenever support for a new technology gets added at runtime, additional devices must be supported without any change to the application. For example, if there is an application that uses motion sensors, adding a new technology that supports motion sensors just means the application will be notified of new devices being available. Adding support needs to be done within 500 ms. This framework has no use without solving the interoperability problem, and modifiability would be the unique selling proposition of the framework (Fig. 7.8).
Table 7.3 Basic actors and
Use cases
Actors
their use cases
1. Get list of devices
Application
2. Notify availability
Device
3. Notification of new device
Application
4. Execute command on device
Application
5. Send status update
Device
6. Receive status update of device Application
7. Add support of new technology Admin application
8. Remove support of technology
Admin application
9. Update support of technology
Admin application
120
7 Internet of Things (IoT)
Artifact
system
Response
Stimulus
Environment
Response
Source
Notify
Translate and
measure
Device
availability
Normal mode
notify
Within in 200
application
ms
Fig. 7.7 The concrete scenario for performance quality
Artifact
Device subsytem
Stimulus
Response
Response
Source
Adds
Environment
measure
Admin
Support for
Support for
New support
application
new
Run time
additional
available
technology
devices
Within in 500
ms
Fig. 7.8 Modifiability/interoperability qualities for DYAMAND
7.4.2 DYAMAND Architecture
Architectural pattern is a basis of the complete architecture. Sometimes combining more than pattern features can help build the architecture. According to the important qualities that associate the DYAMAND (modifiability and interoperability), building the architecture tactics that are associated with each quality will be needed.
Candidate tactics for each quality will be as in the following:
The candidate tactics for modifiability are:
• Increase semantic coherence
• Use an intermediary
• Restrict dependencies
• Anticipate expected changes
• Abstract common services
• Restrict communication paths
• Defer binding
The candidate tactics for interoperability are:
• Discover services
• Orchestrate
Relevant tactics are selected to be used for selected patterns, for example, in Table 7.4.
7.4 DYAMAND: Case Study
121
Table 7.4 Some tactics for modifiability and interoperability with candidate patterns Tactics
Microkernel
Component configuration
Layers
Abstract common service
Yes
Yes
Yes
Runtime registration
No
Yes
No
Anticipate expected changes
Yes
Yes
No
Discover services
Yes
No
No
Orchestrate
Yes
Yes
No
Based on Table 7.4, “anticipate expected changes” is better in both microkernel and component configurator than in the layers pattern. Layers explicitly defines the services needed in each layer, while microkernel abstracts common services and enables easy addition through the use of internal and external servers. “Discover services” is inherent when using the microkernel pattern. “Runtime registration” is only available in the component configurator pattern. According to features of Table 7.4, combination between microkernel and component configurator patterns seems to be the best fit for the requirements of this system and that will be shown in
Fig. 7.9: a static view of the architecture also the plug in context is shown in Fig. 7.10.
Quick Note
Microkernel pattern (plug-in architecture pattern) is a natural pattern for implementing product-based applications. The microkernel architecture pattern consists of two types of architecture components: a core system and plug-in.
Plug-in
Plug-in
Component
Component
Plug-in
Core
Plug-in
Component
System
Component
Plug-in
Plug-in
Component
Component
Component configurator pattern consists of:
Component: a uniform interface that can be used to configure and control the type of application service or functionality provided by component implementation (initializing, suspending, resuming, and terminating)
Concrete components: implement component control interface to provide a specific type of component
Component repository: manages all concrete components that are configured currently into an application
7 Internet of Things (IoT)
Fig. 7.9 A view of the
combination patterns
Plug IN
Kernel
Plug In MANGER
Repository for
plug IN
Plug In context
C1:PlugIn context
Kernal
C2:PlugIn Context
Fig. 7.10 Plug-in context
Figure 7.9 shows that the plug-in manager takes the responsibility of the component configurator component in the component configurator pattern, which is to hold the life cycle of the concrete implementations of plug-in. On the other hand, plug-in repository is the component repository in the component configurator pattern.
Plug-ins should use the available communication mechanisms provided by the kernel in order to communicate with each other. This highly strengthens the modifiability of the system.
Plug-ins that provide generic interfaces (e.g., motion sensors) implement the adapters in the microkernel component. Different than in the microkernel pattern,
7.5 Evaluating IoT Architecture
123
adapters will not communicate with external servers, only with the kernel component itself.
Plug-ins that translate from protocol-specific devices to generic ones implement the external server functionality in the microkernel pattern in that it implements policies on how to interpret protocol-specific parameters and translate them to generic parameters.
Application plug-in uses the generic adapters of devices to implement a generic application; these are the client components in the microkernel pattern.
In addition to the modifiability, many other qualities can be satisfied through this view; for example, security can be provided by assigning a plug-in context object to a concrete plug-in while starting. This is the “single point of entry” that acts as a gatekeeper to the kernel (Fig. 7.10).
Plug-in context is a single point entry that acts as a gatekeeper toward kernel services.
7.5 Evaluating IoT Architecture
IoT application integrates multiple software elements that are distributed across several nodes and communicate with each other, through using Internet protocols and standards. IoT is composed of:
• A sensing device, i.e., a node with computing and communication capabilities
• A gateway device responsible for enabling the connectivity between the short-range network of sensing devices, on one side, and the wide area network, on the other
• A user interface (UI) device that complements the sensors and actuators with limited UI capabilities and allows the users to interact with the IoT application and that will usually be through a dedicated app or through a web interface
• A web component responsible for executing the application logic of the application or service on cloud infrastructure and mediating the communication with other sensing and actuating devices
Evaluating terms that are related to IoT can take many forms from different types of view; for example, if you search on the application provider’s viewpoint, you go through the framework of the IoT which depends mainly on the framework of BPF
(Business Process Framework) by TM (Telecom Operation Map) forum. In this framework the difference is made between the processes dealing with the design and development of the service and the configure operations process, such type of framework will be the basis for evaluation the framework of IoT.
Figure 7.11 represents the IoT evaluation framework that provides to support for: 1. Design and implementation: the design and implementation of application elements to be deployed at the device, gateway, UI device, and web component
7 Internet of Things (IoT)
Support for design and
Device
Gateway
UI
web
implementation
process
Support for operations
Fulfillment
Assurance
Billing
process
Fig. 7.11 Evaluation framework for IoT application
2. Operations including:
• Fulfillment: the discovery and purchasing of applications, as well as the delivery, configuration, and activation of application software
• Assurance: proactive and reactive assurance through monitoring of relevant performance characteristics
• Billing: the accounting and billing of applications and services You can find some of the analysis of IoT framework in the (A Framework for Evaluating Internet of Things Platforms: Application Provider Viewpoint reference).
Quality model of IoT Applications, which will be another suggestion to the evaluation, commonly uses the characteristics defined in the quality model of IOT applications. The effectiveness of the quality model for evaluating IOT application through scenario-based is validated.
A quality model for software applications acts as a framework for the evaluation of attributes of the applications that supply the quality model. It is important that every relevant quality characteristic of software applications must be specified and evaluated, whenever possible, using validated metrics. It is necessity to customize a quality model to identify the acceptance criteria and evaluate a particular application domain, IoT applications.
A natural consequence of the trends would be to manage the quality of IoT applications. However, measuring the quality of IoT applications is considerably different from measuring the quality of conventional software systems. This is because the characteristics of IoT devices and their applications are not presented in conventional software systems.
The main characteristics of IoT are:
• Participation of hardware device: IoT application consists of two types of elements; software components and hardware devices/components. In the design
7.5 Evaluating IoT Architecture
125
and implementation of IoT applications, the presence of hardware devices should be considered.
• Collaboration model with IoT devices: The collaborations of IoT application should consider the hardware functionality as well as conventional software collaboration.
• Mobility and connectivity: It refers to the capability for device mobility to correct the information processing in different stages of a process.
• Connectivity characteristics refer to the user’s quick and efficient connection to information of IoT applications. This characteristic is only used in web applications and mainly in IoT applications.
• Monitoring for IoT devices: Remote monitoring for smart devices attached to networks can support multiple functions. Through smart devices, delivered services can provide more real time and precise.
• Limited resources: The resource types of IoT devices can be battery, network communication facility, memory, and computation power. IoT devices suffer from some limited resources such as battery lifetime and dominate energy consumption. Energy efficiency can be increased by wisely adjusting transmission power.
Participation of
hardware device
Collaboration Model
with IoT Devices
Mobility and
Characteristics of
Connectivity
IOT
Monitoring for IoT
Devices
Limited Resources
These characteristics become the basis for deriving the quality model of IoT
applications, that is, defining quality attributes for evaluating IoT applications by considering the impacts of the identified characteristics on the quality of IoT
applications, as shown in Fig. 7.12.
7 Internet of Things (IoT)
Participation of IoT
Mobility and
Limited Resources
Devices
Connectivity
Reliability
Portability
Efficiency Quality
Fig. 7.12 Some IoT characteristics and their relation to quality attribute Figure 7.12 shows that each characteristic of IoT has a set of associate quality factors, and you must know that each factor has its subfactors, all of that will be measured and the results will be between 0 and 1. Any number near 1 approximately reaches very high quality.
Portability as an example has four main subfactors:
Install ability is the effort for installing the software, conformance means the conformance of applications to the standards, replace ability is the opportunity to use an application as a replacement for another IoT application, and sustainability is the resource types of IoT. In order to calculate metric for conformance, as an example, you have to measure the degree of change to related environments.
X = A/ B, where A is the number of system response requests which can be customized and B is the supposed user response. The range of X is 0–1, and the value 1 is the best which is the response request number for a heterogeneous system; for example, a sensory data through IoT applications is higher for system utilization.
Another example is metric for efficiency, which will measure the appropriate time and resource. Again X = A/ B where A is the time of utilization of limited battery and B is the user requirement time and resources. The range will be from 0 to 1, 1 being the best. Using the proposed set of factors and subfactors, the next step is computing the overall quality of IoT application.
In order to apply the quality model (QM) for IoT, all qualities should be computed in this model, and then the summation of all quality factors multiplied by a given weight (where the given weight for the quality attributes is proposed as high for (0.3), medium for (0.2), and low for (0.1) would be represented) will represent the total factor, and of course a value near 1 will be the perfect (high quality).
127
7.6 Summary
IoT can be defined as a type of network that connects anything with the Internet, and this will be based on protocols through sensing equipments in order to exchange information and communication to achieve smart recognition. The goal of IoT is to connect things anytime, at any place with anything using any path or network and any service.
The fundamental characteristics of the IoT are:
• Things-related services
• Interconnectivity
• Heterogeneity
• Dynamic changes
• Scale
• Safety
• Connectivity
What makes this chapter different from other books on IoT is that it deals with the qualities of IoT: interoperability and modifiability. Security is also an important quality to IoT.
Quality model is the effective way for evaluating IoT application. That will be through characteristics of qualities and subfactors for IoT application for each quality, summing up all the qualities and then giving the total results.
References
K. Patel, S. Patel, Internet of Things-IOT: definition, characteristics, architecture, enabling technologies, and application & future challenges. IJESC (2016). https://doi.org/10.4010/2016.1482
An introduction to the internet of things by Lopez, 2013. http://www.lopezresearch.com/
On line training from SEI
On line training from course area
M. Kim, A quality model for evaluating IoT applications, Department of Computer Science, Soongsil University, Seoul, Korea. IJECE (2016). https://doi.org/10.17706/ijcee.2016.8.1.66-76
Further Reading
Ashton K (2017), ‘Making Sense of IoT”
A. Bassi et al., Evaluating Things to Talk Designing IoT Solutions with IoT Architectural Reference Model (eBook Springer, Heidelberg New York Dordrecht London, 2013). https://
doi.org/10.1007/978-3-642-40403-0. ISBN 978-3-642-40402-3 ISBN 978-3-642-40403-0
J. Tan, S. Koo, Survey of technologies in internet of things, in IEEE International Conference on Distributed Computing in Sensor Systems, (2014). https://doi.org/10.1109/DCOSS.2014.45
Chapter 8
Service-Oriented Business Architecture
(SOBA)
Abstract Service-oriented architecture (SOA) can be best defined as “services”
that provide a platform for different systems to communicate with each other. This chapter explains how SOA can be the basis in the world of business to bring benefits to the organizations that deploy it. The services I talk about are essentially groups of software components that help a company seamlessly carry out important business processes. SOA implementation makes interoperability between heterogeneous applications and technologies possible.
SOA implementation carries several benefits to the organizations:
• Shortened deployment time
• Reduced operating costs
• Reduced risk of failure
All the above (and more) are the reasons for emergence of the concept of Service-Oriented Business Architecture (SOBA). SOBA can be defined as set of steps executed within business processes in the organization, and this will be as services delivered to these processes. These services can then be matched with IT services or others that deliver the necessary functions. The foundation of this concept has been pioneered by IBM to move the position of SOA from IT to the business domain.
SOA, as a style of business architecture, adds value to the business architecture by enabling modularity at the business service level, and this will improve manage-ability. Relation of SOA and quality will be discussed in this chapter.
At the end of this chapter, you will learn:
• What the Service-Oriented Business Architecture means
• The impact of service-oriented architecture on quality attribute and business goals
• The method that is used to evaluate SOBA
© Springer Nature Switzerland AG 2020
129
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1_8
8 Service-Oriented Business Architecture (SOBA)
8.1 Definition of Service-Oriented Business Architecture
(SOBA)
In Chaps. 1 and 2, enterprise and business architecture are defined; you can go through these chapters to review these two terms. EA refers to the connection of design infrastructure with both business organization and the information technology (IT). Organizations’ IT infrastructures are becoming increasingly service-oriented.
Before discussing SOBA, an overview definition of SOA is needed. SOA is defined in many different points of view, including:
• “A Service-Oriented Architecture (SOA) is an application framework that takes everyday business applications and breaks them down into individual business functions and processes, called services. An SOA lets you build, deploy and integrate these services independent of applications and the computing platforms on which they run.”— IBM Corporation point of view
• “Service-Oriented Architecture is an approach to organizing information technology in which data, logic, and infrastructure resources are accessed by routing messages between network interfaces.”— Microsoft view
• An SOA is “a set of components which can be invoked, and whose interface descriptions can be published and discovered.”— Worldwide Web Consortium
[W3C 04] point of view
From the IT viewpoint, SOA is a component providing technology services which represent an interface that hides the internal implementation technology; but SOA is more than that. If you consider the business point of view, you can see that SOA is a style of designing the business architecture. SOA aims to encapsulate the complexity in business services. The benefits of SOA for business are to provide good business governance with clear accountabilities for business service delivery.
Business governance is a process, organizational function, set of techniques, and systematic approach for creating and deploying business policies and business rules into day-to-day business activity. (BPM glossary)
SOA solutions have been created to satisfy business goals that include flexible integration with legacy systems, making more effective business processes, reducing costs, and creating values for service for which customers will pay.
Architects of SOA are often in a conflict. On one part, there is business/mission goals and quality attribute requirements that drive the architecture of the system, and on the other part, there is the set of service-oriented principles that influence the architecture and affect its quality attributes. From the intersection of these qualities, the architect needs to make the decisions that are responsible to make a trade-off and achieve the business goals of the system.
8.1 Definition of Service-Oriented Business Architecture (SOBA) 131
Nowadays, information management research is studying how service- orientation can be applied to the business infrastructure of an organization, and that leads to the rise of the concept of Service-Oriented Business Architecture (SOBA). Foundational concepts underlying the idea of Service-Oriented Business Architecture (SOBA) have been founded by IBM’s Research Division, moving the service from the IT to the business domain. SOBA explains the individual steps to be executed within the organization’s business processes as services delivered to these processes. These business services can then be matched with IT services or others that deliver the necessary functions, and business processes can be reconfigured by changing their mapping onto business services. For many businesses, processes are everything.
Processes drive the action of business units and define the parameters of the success of that action. Processes can also help define goals and the steps that a business needs to take toward those goals to reach success. Service-oriented architecture has become a trending topic in the business process management world.
Business architecture focuses on the work of the organization and how the organization does that work. In order to do that and apply SOA, business and business services need to be aligned.
Business services are operational entities which may have a technical appearance
Three main pillars are needed to align SOA with business technology (Fig. 8.1):
• Strategic pillar: this is about the strategy of the organization, orienting the organization around vision, missions, and goals.
• Operational pillar: this is about the execution of the organization.
• Operational model: this is about focusing on both running and growing the business. The operating model alignment deals with questions such as “How does the organization structure itself?”, “How does that structure support sharing?”, and
“How are business executives, and in effect organizational units, measured for success?” The last question depends on the culture of the organization.
strategic
operational
Operational model
Based on:
vision, mission, goals
strategic models to align
Based on:
Based on:
vision, mission and goals
Organizational structure
Organizational
governance (which
Organizational function that
structure
translate goals to
execute the operation of
Organizational culture
principles and policies.
the organization
Fig 8.1 Main Pillars of Alignment of Business and SOA
8 Service-Oriented Business Architecture (SOBA)
8.2 Basic Qualities in SOBA
Quality attribute requirements drive the software architecture design of the business.
That is why designing architecture for such systems has to satisfy both functional and nonfunctional requirements, and this will be the essential part to the success of business. Recently, the use of a SOA as the underlying business architecture has been gaining popularity and well-known use as the architectural approach for various types of business. Services in SOA are the implementation part of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.
Choosing SOA to be an approach for building business architecture depends on several factors; these factors include the architecture’s ability to meet functional and quality attribute requirements. Usually, architecture needs to satisfy many quality attribute requirements in order to achieve the business goals of the organization. In almost all cases, trade-offs appear between these requirements. In some cases, satisfying these requirements may be easier using an SOA; in others, it may be more difficult.
In all cases several questions need to be asked if SOA is being considered, for example:
• What is the effect of SOA on the business goal?
• Which quality attribute requirements will impact positively, and which will impact negatively by the use of the SOA?
• What trade-offs need to be made among the quality attributes?
As said previously, quality attribute requirements drive the design of architecture. Usually, interoperability and modifiability qualities are the core of SOA systems, but these qualities are explained in the IoT chapter. Here, two other qualities are taken into consideration through designing business which has SOA in its structure: availability and scalability. Business quality can be defined as a non-software system quality that influences other types of qualities. Business qualities are important qualities because it is taken from the market’s point of view. This means that we need to reach some goals like cost and time to market from market’s point of view, but that will be affected from the software quality that can be reached by our stakeholders. To conclude, business systems built from software and the quality of this software will affect the goal of the business. This is why you see the same qualities in other software architecture books and why you see variability in SPL systems (you can add other qualities you need in your system according to the type of business you build).
8.2 Basic Qualities in SOBA
133
8.2.1 Availability
Availability is the degree to which a system or component is operational and accessi-ble when required for use. In fact, availability is built on reliability by adding the notion of repair.
Availability is closely related to many other qualities. It is related to security; denial of service attack is basically designed to make the system unavailable.
Availability is also closely related to performance; it is difficult to know when a system will fail or simply slow to respond. Again availability is related to safety when keeping the system from hazards and recovering the damage when it occurs.
Going back to the availability of services, both from the user’s and provider’s points of view, you see that this quality is a concern for the success of an SOA. From the service user’s perspective, if the system relies on a set of services being available in order to meet its functional requirements and one of those services becomes unavailable, it could influence the system’s success. From the service provider’s perspective, in order for the services to be used, they must be available when needed.
Otherwise, the provider’s finances could be impacted. Figure 8.2 represents quality attribute scenario for availability.
Service providers usually agree to provide the service users a set of services and to include each service in a SLA (service-level agreement) . The SLA defines the contract of the terms of the service with details such as who provides the service, the guaranteed availability of the service, the rapid increase process (which is followed if the service is not handled to the service user’s satisfaction), and the penalties to the provider if the service level is not met.
When the system no longer delivers a service that is consistent with its specification, it will fail, and this will be observed by the system’s actors. A fault has the potential to cause a failure. Recovery or repair is an important aspect of availability.
Availability tactics are designed to tolerate the system’s fault so that the system still delivers services consistent with its specification.
Artifact
Processors, communication channel,….
Response
Source
Stimulus
Environment
Response
measure
Prevent fault
Interval time or
It can be internal or
Fault: incorrect
Normal operation,
from becoming
time must be
external :example
timing,
shutdown ,overloaded
failure, Detect
available. time
people ,hardware,
incorrect
operation….
Fault, recover
to detect fault,
software...
response...
fault
repair time….
Fig. 8.2 The quality attribute scenario of availability
8 Service-Oriented Business Architecture (SOBA)
Shadow
Voting
Re introduction
Preparation and Repair
Fault Recovery
Fault Prevention
Transactions
Availability tactics
…….
Fault detection
Heart beat
Exception
…….
Fig. 8.3 Availability tactics (the square of means that there are other examples on this tactic) Availability tactics may be categorized as:
• Fault detection
• Fault recovery
• Fault prevention
So your basic job as an architect is to choose and assess the right availability
Note The main goal of availability tactic is that when the fault appears, it must be repaired or masked.
In conclusion, the impact of SOA on availability is that it is up to the service users to negotiate the SLA that can be used to set an agreed-upon level of availability and include penalties for nonconformity with the agreement. Also, when invok-ing a service that is not available, here availability could actually be improved as compared with other architectural approaches.
135
8.2.2 Scalability
Scalability is the ability of SOA to do its purpose when the system is changed in size or in volume in order to meet the users’ needs. One of the major issues in scalability is the capacity of the site where the services are located to accommodate an increasing number of service users without affecting the services’ performance.
One of the most important aspects of SOA in relation to scalability is the ability for developers to distribute and deploy applications to multiple locations. These locations may be separated physically or logically, or they may be distributed across a platform such as the web. It may also be between different departments in an organization regardless of where or how they are deployed; the concept of SOA allows for flexibility in the design and development of these applications. Services can be used by anyone in any location for whatever needs they may have. This will increase flexibility and the ability to integrate existing scalable services into an application built for heavy loads.
There are two basic kinds of scalability:
• Horizontal scalability: distributing the workload across more computers, for example, adding tier or more service sites. It does not require more expensive hardware, but does require architectural and design decisions to ensure that the application can run perfectly across multiple machines.
• Vertical scalability: upgrading to more powerful hardware for the service site. In the short term, vertical scaling is easier—upgrading machines to handle more is quite easy and allows the developer to expand without reengineering the application. However, this type of scaling does not work in the long term.
Another type of scalability known as scaling by depth describes the ability to add or remove services on the fly. This would allow an application to be constructed dynamically and be customized for individual use cases. Another type of scalability is time scaling utilizing SOA, and just-in-time resource allocation in the cloud allows for runtime creation of applications that only use resources where needed.
This on-demand scaling saves costs in many areas.
The performance of the system must be studied, and performance models must capture the degree of the scalability and load tests required. These performance models will need to make some changes based on solution option or a combination of options that is chosen to make sure that the new deployment configuration will meet the intended scalability requirements without affecting the system’s performance.
Using service-oriented architecture does not automatically guarantee scalability.
Many problems exist between such architecture and a truly scalable application, ranging from simple bottlenecks to bad design decisions, for example, all layers must scale or there is a physical limitation.
In conclusion, the impact of SOA on scalability is that there are ways to deal with increasing the number of service users, and this will need to support more requests for services. However, these solutions need detailed analysis by the service providers to make sure that other quality attributes are not affected negatively.
8 Service-Oriented Business Architecture (SOBA)
These two qualities and other sets of qualities are required to build SOBA, tradeoff is made between the qualities (and other qualities) through building the business, and all of that will be advantageous to the business. Some other advantages for SOBA are:
• Services (sometimes called functions) will be reusable. Since each part of the business will be coded independently, these pieces will be reused in different parts of the business. One of the good examples is a USB cord; it can be used to charge and power many devices.
• Better productivity is another advantage for SOBA; reusing the services enhances the efficiency and the productivity of the business.
• Easy consulting. You can easily find partners who use SOA who you can consult to find the solution for the business.
8.3 The Impact of Service-Oriented Architecture on Quality
Attribute and Business Goals
The important part for the success of any organization is building systems that satisfy its business goals. Software architecture is the bridge between business goals and the final results of the system.
Specific business goals require specific types of quality attributes. For example, the business goals of agility and being first to market require adaptability, interoperability, scalability, and extensibility, and these will be the major drivers for the architecture of that application and development of the services. Agility will require that services can be adapted and reused in new applications, combined in new ways, and scaled to meet the increasing demands for the functionality within the application.
Typical business goals are:
• Agility
• Being first to market with innovative services for its customers
• Streamlining business processes to reduce operating costs
• Enabling easy and flexible integration with legacy systems
Because architects try to satisfy the system’s requirements (both functional and nonfunctional) and meet the organization’s business goals, they may choose to use an SOA approach in architecting and designing the system.
There are sets of principles for architecting and designing an SOA that impacts agility. These principles include loose coupling and precise specification of services and more such as standardized services, standards compliance, and defining services as coarse-grained.
Reducing the time required to be in the market is done by reusing both internal and external services within the SOA approach, combining services in new and different ways, and adding additional services where needed.
8.4 Service-Oriented Business Architecture and the Evaluation Method 137
Table 8.1 The impact of SOA approach on some of quality attributes Quality
attribute
Conclusion effect
Grade
Security
The need for authentication, trust, and encryption within an SOA
Zero
approach needs specified attention within the architecture. Standards to support security are still not finished, and this will impact negatively on security
Interoperability SOA provides good interoperability quality, and that will allow 2
services and applications to be built in different languages and to interact through different platforms
Performance
In general, SOA has a negative impact on this quality through the delay Zero in network or through requiring a call to a directory of services to locate the desired services. Designing and evaluating the architecture carefully by the user of the service is important to make sure the requirements of the performance are met
Usability
It is up to service users and providers to build this quality in their 1
system. It may decrease if the service within the application supports human interaction within the system and has some problematic issues in the performance of that service
Extensibility
Extending SOA by adding new services or incorporating additional
2
capabilities into existing services is supported in SOA, but you must make sure that the interface is carefully designed to help this quality without any effect on service users
Using a service-oriented approach allows organizations to combine existing and newly developed processes, and this combination will meet the new process’s needs.
The SOA approach’s impact on the quality attributes is shown in Table 8.1. The
“grade” column refers to the state level of SOA in each area. Number 2 indicates that there are known solutions for the SOA based on relatively mature standards and technology. Number 1 indicates that some solutions exist but need further research to prove their usefulness in handling the requirements for the quality attribute. Zero indicates that the standards and technology are immature and further significant effort is required to fully support the quality attribute within an SOA.
8.4 Service-Oriented Business Architecture
and the Evaluation Method
The first question that arises in mind is: what does it mean that particular software architecture is suitable for its proposed purpose? The answer that comes from SEI is: it is the one that is built based on what is determined by quality attribute requirements. These requirements are important to the stakeholders of the system, and that is the reason the attribute requirements rely on the ATAM method; it depends mainly on eliciting QAS from different groups of system stakeholders.
If software architecture is a key business benefit for an organization, then a key practice for that organization must be architectural analysis. The reason is that such
8 Service-Oriented Business Architecture (SOBA)
type of architectures are complex and they hold many design trade-offs, and with a formal analysis process, the organization can make sure that the architectural decisions are made. You must also know that if the architectural design decisions form a system’s quality attributes, then it is possible to evaluate these decisions according to their effect on those attributes.
QAS gives exact statements of the usage of the requirements, failure, threats, modification, as well as performance. Once the important quality attributes are identified, the decisions that related to each high priority scenarios are analyzed, and this will be in the form of the following:
• Risks: architectural decisions that might create problems in the future for some quality attribute
• Non-risks: architectural decisions that are suitable in the context of the quality attribute that they affect
• Trade-offs: architectural decisions that have an effect on more than one quality attribute
• Sensitivity points: a property of one or more components and/or component relationships, critical for achieving a particular quality attribute requirement ATAM (developed by the Carnegie Mellon Software Engineering Institute (SEI)) is the foundation for defining the activities and information that are important for the evaluation of a system that uses an SOA approach. ATAM method consists of the following steps:
1. Present the ATAM: The evaluation team presents a quick overview of the ATAM
steps, the used techniques, and the outputs from the process.
2. Present the business drivers: The system manager presents the business drivers in a brief way and context for the architecture.
3. Present the architecture: The architect presents an overview of the architecture.
4. Identify architectural approaches: The evaluation team and the architect document the architectural approaches discovered in the previous step.
5. Generate the quality attribute utility tree: A small group of technically oriented stakeholders identifies, prioritizes, and refines the most important quality attribute goals in a utility tree format.
6. Analyze the architectural approaches: The evaluation team look into the architectural approaches in light of the quality attributes to identify risks, non-risks, and trade-offs.
7. Brainstorm and prioritize scenarios: Diverse group of stakeholders creates scenarios that represent their various interests. Then the group votes to prioritize the scenarios based on their relative importance.
8. Analyze architectural approaches: The evaluation team continues to identify risks, non-risks, and trade-offs while noting the impact of each scenario on the architectural approaches.
9. Present results: The evaluation team reviews the ATAM steps, outputs, and recommendations.
8.4 Service-Oriented Business Architecture and the Evaluation Method 139
These steps are usually carried out in two phases:
Phase 1 is architect-centric and concentrates on eliciting and analyzing architectural information. This phase will be from steps 1 to 6.
Phase 2 is stakeholder-centric, elicits points of view from a more diverse group of stakeholders, and verifies the results of the first phase. This phase will be from steps 7 to 9.
There is also a phase 0 which consists of planning and preparation. In this phase the evaluation team looks at the existing architecture documentation to identify questions or areas of incompleteness. If the documentation is considered insufficient to express the multiple structures of the architecture, the evaluation does not proceed to phase 1.
Adventure Builder is a simple and brief example on evaluation a system. Basic functionalities of this application are shown in Fig. 8.4.
Table 8.2 shows some quality attribute requirements by using quality attribute scenarios for the Adventure Builder system. It shows sample scenarios that may be related to an SOA-based architecture.
Note OPC (order processing center) acts as a service user when it interacts with airline provider, lodging provider, and activity provider (external services in
Fig. 8.5). These interactions are asynchronous, because processing the requests can take a long time and the OPC application should not be blocked waiting for the Adventure System
*Bank
Browse catalog
*
*
Order Travel Package
*
*
*
*
*
**
* Airline
*
Vacationer
Track the Order
*
**
Lodging Provider
*
*
Revise the Cataloge
*
*
* Activity Provider
Fig. 8.4 Use case diagram for the Adventure Builder
8 Service-Oriented Business Architecture (SOBA)
Table 8.2 Quality attribute scenario for performance and availability quality for the adventure system
Performance (Source): User
(Stimulus): User submits an order for a package to the consumer web site.
(Artifact): Adventure Builder system and the bank
(Environment): Under normal operation
(Response): The consumer web site informs the user that the order has been successfully submitted and is being processed by the OPC
(Response measure): The system reacts to the user in less than 5 seconds Availability (Source): Internal to the system
(Stimulus): Fault occurs in the OPC
(Artifact): OPC
(Environment): Under normal operation
(Response): The system administrator is informed of the fault; the system continues taking order requests; another OPC instance is created; and data remains in consistent state
(Response measure): The fault is detected, and fail over action is taken within 30 seconds
Website for consumer
Related
Database
Web browser
Order Processing Center
Related
Database
BROKER
bank
External service3
External service1
External service2
Fig. 8.5 The architecture view of adventure application
results, and that is why broker is needed. Fig. 8.5 shows the role of OPC on the architecture’s view of adventure
As defined in previous sections, a service is a distributed component which its details of implementation will be hidden. The distributed nature of a service and the
8.4 Service-Oriented Business Architecture and the Evaluation Method 141
interaction between a service user and a service provider are noticeable at runtime.
Thus, the runtime view best captures a service-oriented design that leads to say an SOA is a style of the component-and-connector view type.
In an ATAM evaluation, the architectural approaches are identified during steps 3 (Present architecture) and 4 (Identify architectural approaches). Hub-and-spoke is the architectural approach of the Adventure Builder application. The use of the
“hub” as an active mediator reduces the dependencies between the “spokes” to promote modifiability. Most changes to any single “spoke” should be localized and should only require changes to the “hub,” but when you deal with service integration, the evaluation does not cover every important architectural decision. For example, the architectural pattern used in the consumer web site is the Model-View-Controller (MVC) pattern to promote modifiability.
Hub-and-spoke: it is one of traditional architectures. In this type of architecture, there is a single integration server named hub that holds information to be exchanged between many applications or data stores named spokes.
Going through architectural analysis in the ATAM does not mean that it will be accurate and detailed; there is also no numerical value for different qualities. The key is to elicit enough architectural information to identify risks, which results from the correlation between the architectural decisions and their effect on quality attributes. The evaluation is done to capture the architectural approaches and identify their risks, non-risks, sensitivities, and trade-offs. For example, the architectural analysis of performance quality is as shown:
Scenario
User submits an order for a package to the consumer web site. The system abstract
responds to the user in a specific time
Business goals Provides satisfactory user skills
The quality
Performance
attribute
Architectural
The web services were designed around the documents handled, such as approaches
purchase orders and invoices. The OPC purchase order service interface improves the performance. This interface reduces the overhead of calling a fine-grained service for each step of a business process
The OPC interacts with the bank in a synchronous way. After authorizing the charge quickly, the OPC sends requests to transportation, lodging, and activity providers, which will later respond through the web service broker callback endpoint. These requests are sent asynchronously to improve scalability and throughput and also because of the nature of the legacy systems supporting this interface
Risk
The design does not meet the requirement in this scenario, for the reason that it assumes that all external transportation providers implement the same web service interface
8 Service-Oriented Business Architecture (SOBA)
Trade-off
The homogenous action of all transportation providers in OPC increases modifiability. On the other hand, intermediaries are needed to cooperate with external providers that offer heterogeneous service interfaces, as in this scenario
These intermediaries represent a performance overhead, because they may require wide processing of overhead and routing messages
8.5 Summary
Service-oriented architecture is defined from different points of view. The IT point of view of SOA is a component providing technology services which represents an interface that hides the internal implementation technology. If you take the business point of view, you can see that SOA is a style of designing the business architecture.
SOA aims to encapsulate the complexity in business services. SOA benefits for business are providing good business governance with clear accountabilities for business service delivery. Nowadays, information management research is studying how service-orientation can be applied to the business infrastructure of an organization, and that leads to the rise of the concept of Service-Oriented Business Architecture (SOBA). Foundational concepts underlying the idea of Service-Oriented Business Architecture (SOBA) have been founded by IBM’s Research Division move service from the IT thinking to the business domain. SOBA explains the individual steps to be executed within the organization’s business processes as services delivered to these processes. These business services can then be matched with IT services or others that deliver the necessary functions, and business processes can be reconfigured by changing their mapping onto business services.
Choosing SOA as an approach in the development of architecture depends on several factors including the architecture’s ability to meet functional and quality attribute requirements. Usually, the architecture needs to satisfy many quality attribute requirements in order to achieve the business goals of the organization. In almost all cases, trade-offs have to be made between these requirements. Usually, interoperability and modifiability are the cores of SOA systems.
If software architecture is a key business benefit for an organization, then a key practice for that organization must be architectural analysis. This is because these architectures are complex and hold many design trade-offs. And with a formal analysis process, the organization can make sure that the architectural decisions are made. That is why ATAM is the appropriate method to SOBA.
References
L. Bass, Software architecture in practice (Addision Wisely, 2013) P. Bianco, R. Kotermanski, P. Merson, Evaluating a Service-Oriented Architecture (2007).
Technical Report. CMU/SEI-
Capagmenin Consulting Technology and Outsourcing, Service-oriented enterprise: how to make your business fast, flexible and responsive. http://www.cio.co.uk
143
E. Lemey Supervised by: Geert Poels, Investigating service-oriented business architecture, 7221
(Springer-Verlag, Berlin, Heidelberg, 2012), pp. 220–225
L. O’Brien, L. Bass, P. Merson, Quality attributes and service-oriented architectures, 2005, Technical note from CMU- SEI
The Open Group. SOA for Business Technology – SOA and Business Architecture
Further Reading
A. Grigoriu, SOA, BPM, EA, and service oriented enterprise architecture, BPTrends 2007
I.
Sommerville, Software engineering, 9th edn (Addison Wesley, 2010) ISBN:01370351529780137035151
Now at last I want to conclude the main thoughts that I want you to know through beginning your future in software architecture especially if you are just beginning your study in this field or just beginning your first day in your job as an architect:
• First: qualities are the basic part for any individual, company, and organization that need to start building their products, because this will make the competition between products or even between the people whose responsibility is building the products in the market. It is the main target to building any system.
• Second: knowing the patterns and tactics. As beginning with the first thought, the quality is the basic thing that all must focus on, and the second thought that you must know is that gaining the quality can be done through other stages in the life cycle. Here the focus is on software architecture stage because the title of this book is going around this stage. And because I talked especially on software architecture and its relation to building high-quality products, then you need to know the architectural patterns and their tactics to use the most appropriate of them to have the high-quality products and also make a trade-off between qualities in the same product.
• Third: stakeholders. Through years ago I read many books and article papers and attend conferences on software architecture; through that I saw the important advice from professionals; and this advice says: know your stakeholders.
Knowing the stakeholder is a very important part to any architect because you as an architect can extract the goals that they want from the product that you can go through this road to reach the quality.
• Fourth: evaluation. It is very important to any architecture because it avoid architectures from disaster. To put it in a different way, if you were building a house, you wouldn’t proceed without carefully looking at the blueprints before building began. It is also the right thing to know the appropriate method according to the quality of the product as what said through this book but in general ATAM
method is used as an evaluation method. Also you must know that the evaluation will tell you that the architecture is suitable according with one goal (or set of
© Springer Nature Switzerland AG 2020
145
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1
Conclusion Thoughts
goals) and according to other qualities there is a problem, sometimes one goal is important than another sometimes a conflict occurs between qualities, the manager of the project will have the decision to make if the architecture evaluates good in some areas and not evaluated very well in other area.
• Also you showed that SAAM method focuses on modifiability quality in its different forms (such as portability, subsetability, and variability) and functionality, while ARID method provides a deep understanding about the suitability of part of the architecture to be used by developer to complete their responsibilities.
That is why architecture evaluation methods can be choosing according to the qualities that are related to that architecture.
• In short, architecture evaluation produces better architectures.
Finally I hope you have the basic stone to start your journey in software architecture and its relation to building high-quality products.
Appendix A
General Scenario for Modifiability
Artifact
What to be changed: code, interfaces,
data...
Stimulus
The change to
Environment
Response
Response
Source
be made:Add/
measure
End user
Delete/Modify
When the change can
Make ,test and
Time and
System Administrator
functions.
be made: in all stages
deploy
money is the
developer
A change can
of life cycle
modification
most measure
be made to
quality also
Concrete Scenario for Modifiability
Artifact
code
Stimulus
Environment
Response
Response
Source
The change to
measure
developer
UI
At a design time
Change made
and test
In three hours
© Springer Nature Switzerland AG 2020
147
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1
148
Appendix A
Role of General Scenario for Performance
Artifact
System, or one or more components in
system
Environment
Response
Response
Source
The system can be in
measure
Internal or
Stimulus
various operational
The system
The time taken to
extenal to the
Arrival events .
mode: as for example
must process
process the arriving
sytem
normal mode,
the arriving
events:latency,jitter
emergency mode
events
….
Concrete Scenario for Performance
Artifact
System
Stimulus
Environment
Response
Response
Source
Initiate
measure
users
event(transaction)
Normal operation
Processed
Latency for two
.
transactions
seconds
General Scenario for Security
Artifact
Service of System, data within system,
data produced or consumed by system
Environment
Source
Stimulus
Response
Response
The source
Attack happen:
The attack come in
measure
either human
example attempt
any mode of system
Process events.
Response of system
or another
to modify ,delete
example normal
Change the level of
example: recovery
system
,display data .
mode, overload mode
service
time
Appendix A
149
Concrete Scenario for Security
Artifact
Data within the ystem
Source
Distinguished
Stimulus
Environment
Response
Response
employee
Attempts to
measure
from remote
modify pay rate .
Normal operation
System maintains
Resore correct data
audit trail
within a day
place
General Scenario for Testability
Artifact
Part of system being tested
Response
measure
Effort to find a
Environment
Stimulus
Response
fault.
Source
Happen at:
Set of tests
effort o achieve
Could be
development time
through
Controlled the
a coverage %,
human or
,compile time,
completion of
system to perform
Probability of
automated
deployment time
coding increment
test and the result
fault being
tester
,run time,
example: service
can be observed
revealed by
design time,
next stage,
integration time
Time to carry
out tests,
Reduction in
risks
Time to prepare
test
environment
Effort to detect
fault
And so on
150
Appendix A
Concrete Scenario for Testability
Artifact
Code part
Response
Stimulus
measure
Source
Environment
Response
completion of
Coverage 90%
Unit tester
Development time
coding unit
Captured results
at 3 hours
General Scenario for Usability
Artifact
System or part of the system that
interacting by user
Response
Stimulus
Response
measure
Try to use the
Environment
Providing the
Source
system
run time or
user’s need of
Task time
End user
efficiently
configration time
features
Number of
Learn using
Or predict the
errors
the system
user's need
Number of
Adapt the
finished
system
tasks
Minimize the
User
effect of
satisfaction
errors
Percentage
Configure
of
system
successful
operation to
the total
amount
And so on
Concrete Scenario for Usability
Artifact
system
Response
measure
Stimulus
Response
Source
Environment
Within two
Download a new
user
run time
minutes
application
Uses applicatin
productivity
experiments
Software
structure
Element types
Relation
Useful for
Module
Decomposition Module
Is a sub module of
Resource allocation and
structure
project structuring and
planning; information
hiding, encapsulation;
configuration control
Uses
Module
Uses
Engineering subsets;
engineering extensions
Layered
Layer
Requires the
Incremental development;
correct presence of; implementing systems on
uses the services
top of “virtual machines”
of; provides
abstraction to
Class
Classes, objects Is an instance of;
In object-oriented design
shares access
systems
methods of
C&C
Service
Service,
Run concurrently
Scheduling analysis,
structure
registry, others
with, etc.
performance analysis
Concurrency
Process, thread
Can run in parallel
Identifying locations
where resource
contention exists, where
threads may fork, join, be
created or be killed
Allocation Deployment
Components,
Allocated to;
Performance, availability,
structure
hardware
migrates to
security analysis
elements
Implementation Modules, file
Stored in
Configuration control,
structure
integration, test activities
Work
Modules,
Assigned to
Project management, best
assignment
organizational
use of expertise,
unit
management of
commonality
Architectural structure for the system
© Springer Nature Switzerland AG 2020
151
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1
ATAM (Architecture Trade-off Analysis Method)
First of all, ATAM gets its name because it reveals on how well an architecture satisfies the quality goals, and the most important thing is how trade-off between qualities has been used for over a decade to evaluate software architectures and draws its technique from three areas:
• The architectural style concepts
• The quality attributes analysis communities
• SAAM method the predecessor method to the ATAM
ATAM steps can be separated into four main groups.
Presentation: exchange the information through the presentation which includes: 1. Present the ATAM: evaluation leader introduce the method to the participate.
2. Present the business driver: the project manager or customer describes the business goals that motivated the development and then what is the main architectural driver (such as time to market).
3. Present the architecture: here, the role of architect is to describe the architecture and focus his attention on how it addresses the business driver.
Investigation and analysis
4. Identify the architectural approaches: the approaches of architecture are identified by architect but not analyzed.
5. Generate the utility tree: the quality attribute of system is elicited and specified down to the level of scenarios, stimulus, and response and prioritized.
6. Analyze the architectural approach: based on the high priority in previous step, the architectural approaches that address the scenario will be analyzed. Here, risk, sensitivity point, and non-risk trade-off will be identified in this step.
© Springer Nature Switzerland AG 2020
153
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1
Appendix C
Testing
7. Brainstorming and prioritize scenario: the set of scenario that elicited earlier will be prioritized through voting process involving all the stakeholders.
8. Analyze the architectural approaches: in this step, reiteration of the activities in step 6 occurs, but high-ranked scenarios from step 7 are used. Those scenarios are supposed to be the test cases to confirm the analysis performed thus far.
Reporting
9. Present the result based on the information collected during the steps, and then the results will be presented to the stakeholders.
These steps can be carried out through the following phases:
Phase
Activity
0
Preparation
1
Evaluation from steps 1 to 6
2
Evaluation from steps 7 to 9
3
Process improvement and delivery
According to quality, ATAM is not oriented to any specific type of quality SAAM (the Software Architecture Analysis Method)
It is a simple method and good place to start if this is the first time you evaluate and architecture, especially if you work on modifiability and functionality The output tangible results from SAAM evaluation are:
• Mapping onto scenarios that represent possible future changes to the system
• Understanding the functionality of the system
SAAM steps are:
1. Develop scenario: these scenarios represent tasks related to different roles of stakeholders; these scenarios are all brainstorming exercise, and also they are collected in two or more elicitations.
2. Describe architecture: describing the architectures should be through notations that will be understand by parties and must specify data components with related connections and system’s computation, and all these will take in the form of natural language or some other formal specification.
3. Classify/prioritize scenarios: in SAAM, scenarios are classified into direct and indirect scenarios. Prioritization is done by choosing the most important scenarios and that is done by stakeholders through voting process.
4. Individually evaluate indirect scenario: chosen scenarios are mapped onto the architectural description. According to direct scenarios, the architect shows how
155
these scenarios are executed by architecture. On the other hand, in indirect scenarios, the architect should describe how the architecture needs to be changed in order to accommodate the scenarios.
5. Assess scenario interaction: interaction scenarios are called to the indirect scenarios that require changes to a single component of architecture. These types of scenarios are important for two reasons: first reason is it depicts allocation of functionality to the product’s design. Second important reason is that it can expose the architecture not documented to the right level of structural decomposition.
6. Create overall evaluation: at the final stage, a weight is assigned to each scenario for the reason of showing the related importance to the success of system. This weight usually attaches to the business goals that support the scenarios.
Notes
• Step 1 and 2 done on interleaved way or on several iterations.
• There are two important concepts in these iterations, and those are direct and indirect scenarios. Scenarios represent tasks relevant to different roles such as developer, maintainer, customer, etc.
Direct scenarios are those scenarios that are specified by the architecture through the execution of the system. Such types of scenarios are increasing the understanding of the architecture to the stakeholders and allow the systematic exploration of their architectural qualities. On the other hand, there is an indirect scenario which defines as that requires a modification to the architecture to be satisfied. It is those scenarios that play as a central role to the measurements of the degree to which an architecture can hold evolutionary changes that are important to the stakeholder.
The indirect scenarios measure the suitability for continuing use throughout the lifetime of the family.
ARID (Active Reviewers for the Intermediate Design)
It is a method that used to evaluate the architecture partially or in the intermediate designs when all the architecture passes through. This method lies at the intersection between ATAM and ADRs (active design reviewers) methods. It consists of nine steps going through two phases.
Phase 1: Rehearsal
In this phase, a meeting between the lead designer and review facilitator to prepare for exercise.
Step 1: identify the reviewers—the reviewers of the ARID are the design’s stakeholders.
Appendix C
Step2: prepare the design briefing—the designers organize a brief explanation of the design. The goal is to present the design in a good so that members can use it in a sufficient way.
Step3: prepare the seed scenarios— here, designer and the review facilitator present a set of seed scenarios; the aim is roughly a dozen scenarios.
Step 4: prepare the materials—this step is the preparation to phase 2 by preparing copies of the presentation, scenarios, and review agenda to the reviewers during phase 2.
Phase 2: Review
Step 5: present ARID— the explanation of the steps of ARID to the participants is done by review facilitator.
Step 6: present the design—the suitability of the design is the goal of this step. The lead designer gives an overview presentation with examples.
Step 7: brainstorm and prioritize scenarios— this session is just for brainstorming and prioritizes scenarios. Voting process is done through process, and the most voted scenarios received are used to test the design for testability.
Step 8: apply the scenarios— when received the most voted scenarios, the facilitator ask reviewers to expertise the code that uses the design services to solve the problem posed in the scenario whenever the group went to the wrong direction they will be stopped to get the group moving again by providing whatever information is supposed it will be necessary.
Step 9: summarize— recounting the list of issues is done by facilitator; ask the participants for their opinions and thank them for their participations.
Note
ARD method relies on actively engaging reviewers by assigning them review tasks that are structured; it is used to evaluate detailed design of coherent units of software for example modules or components.
According to quality, ARID is used for suitability of the design approach.
A
role of
Allocation structure, 52
architect of technical infrastructure, 16
Application layer, 110
business architect, 16
Architectural patterns
business manager, 16
broker pattern, 54, 55
business strategy, 16
client-server, 57, 58
enterprise architect, 16
definition of, 52
productivity and efficiency, 16
elements, 52
solution architect, 16
layered pattern, 53, 54
types, 17
module patterns, 53
and technology
multitier pattern, 60
influence of, 14, 15
MVC pattern, 55, 56
Architecture drivers, 71
pipe-filter, 56, 57
Architecture Influence Cycle (AIC), 15
publish subscriber pattern,
Architecture Reviews for Intermediate Design
61–63, 74
(ARID), 104
SOA, 59, 60
Architecture Trade-off Analysis Method
software architecture structures, 52
(ATAM), 13, 41, 104
types of structures, 52
Attribute-Driven Design (ADD), 11, 16, 70,
Architectural structure, 51, 52, 71, 74
71, 73
Architectural style, 74
Architecturally Significant Requirements
(ASR), 11
B
business goals, 39
Business architecture, 6
interviewing stakeholders, 38
Business governance, 130, 142
requirement documentation, 40
Business managers, 23, 24
system’s requirement, 38
Business pattern, 68–70
utility tree, 40
Business Process Framework (BPF), 123
Architecture
Business quality
definition, 1
basic categories, 92
documentation, 13, 14
benefits, 91
life cycle of, 11, 13
definition, 77, 78
pattern
goals, 78–81
allocation, 18
types of, 91
component and connector, 18
Business software architecture (BSA)
layers, 18
business education, 22
and requirements, 11
business managers, 23, 24
© Springer Nature Switzerland AG 2020
157
L. Khalid, Software Architecture for Business,
https://doi.org/10.1007/978-3-030-13632-1
Index
Business software architecture (BSA) ( cont. )
Global System for Mobile communication
definition, 21
(GSM), 109
measurement, 30
Graphical user interfaces (GUIs), 55
pragmatic architect, 27
requirements, 24, 26
role, business architect, 29
I
role, management, 27, 28
IBM’s Research Division, 131
Integrity, 5
Internet of Things (IoT)
C
application layer, 110
Client-server pattern, 18
cloud computing, 108
Cloud computing, 108
Cs impact, business and society, 111
Commercial off the Shelf (COTS) software,
evaluation, 123, 125, 126
78, 97
fundamental characteristics, 108
Competence center and platform
gateways and networks, 110
pattern, 18
integration of information technology, 107
Component and connector structure, 52
interoperability quality, 112, 113, 115
Containers-as-a-Service (CaaS), 8
IPv6, 108
Cost benefit analysis method (CBA), 23
management service layer, 110
Cyclomatic complexity, 35
modifiability quality, 115, 116
RFID, 108
smart device/sensor layer, 109
D
software architecture, 111
Docker architecture, 9, 10
type of network, 107
Dynamic Adaptive Management of Network
Internet Protocol version 6 (IPv6), 108
and Devices (DYAMAND)
application developers, 117
architecture, 120, 121, 123
L
functions, 118
Local area network (LAN), 109
lack of interoperability, 117
plug-in architecture, 118
software requirement, 119
M
Management service layer, 110
Manufacturing and Service Organizations, 82
E
Marketability, 78
Enterprise architecture, 5, 6
Marketecture, 14, 19
business architecture, 6
Microkernel pattern, 123
characteristics, 6
Microservices, 7
fundamental technology and process
Model-View-Controller (MVC) pattern, 55,
structure, 5
56, 141
modern app architecture, 7, 8
Modularity, 5
organization/collaborative collections, 5
Module structure, 52
role of stakeholder, 7
Multitier pattern, 18, 60
Evaluation, 145, 146
Event Driven Architecture (EDA), 4
N
Networks, 110
F
Non Functional Requirements (NFR)
First come first service (FCFS), 67
Framework, 41
G
O
Gateways, 110
Object Management Group (OMG), 24
General Event Notification Architecture
Operationalizations, 49
(GENA), 118
Order Processing Center (OPC), 139
159
P
scenario prioritization, 47
Pedigree Attribute eLicitation Method
scenario refinement, 47
(PALM), 80
technique of elicitation, 45
Personal area network (PAN), 109
Quality function deployment (QFD), 84
Plan-Do-Study-Act (PDSA), 83
Quality model (QM), 126
Publish subscriber pattern, 61–63, 74
R
Q
Radio Frequency Identification Devices
Qualities, 145
(RFID), 108
Quality attribute
Return on investment (ROI), 23, 36, 102
ADD, 70, 71, 73
benefit of pattern, 69
definition, 34
S
implementation/deployment, 37
Service Discovery Protocols (SDPs), 117
product line scope, 101
Service oriented architecture (SOA) pattern,
software architecture and qualities,
59, 60
37, 38
Service Oriented Business Architecture
software product
(SOBA)
architecture and business, 36, 37
basic qualities
customer satisfaction, 36
availability, 133, 134
cyclomatic complexity, 35
business functionality, 132
definition, 34
requirements, 132
external and internal, 35
scalability, 135
predictability, 36
business technology, 131
reputation, 36
definition, 130
use of systematic software
evaluation method
measurement, 36
Adventure Builder, 139
tactics
architectural analysis, performance
parameters, 66
quality, 141
vs. patterns, 67
ATAM method, 138
quality attributes, 64
hub-and-spoke, 141
queuing model, performance quality,
phases, 139
66, 67
quality attributes, 138
stimulus and response, 64
software architecture, 137
support system initiative, 66
stakeholders, 137
support user initiative, 64
quality attribute and business goals,
usability, 66
136, 137
and trade-offs, 41
quality attributes, 130
variability, 102
Service-Level Agreement (SLA), 133
variants
Service-Oriented Architecture
goal of, 102
(SOA), 130
user interface, 102
Shared-data/repository pattern, 18
variation mechanism, 103
Smart device/sensor layer, 109
variation points, 102
Software architecture
Quality Attribute Scenario (QAS), 39, 42–44
abstraction, 3
Quality attribute workshop (QAW), 11
algorithms and data structures, 2
advantages, 48
definition, 2
architectural plan and presentation, 46
functional and non-functional
business /mission presentation, 46
requirements, 4
identification of architectural
modern, 4
drivers, 46
software system, 2
presentation and introductions, 46
structure, 3
scenario brainstorming, 47
Software Architecture Analysis Method
scenario consolidation, 47
(SAAM), 41, 104
Index
Software product line (SPL)
T
architecture
Tactics, 145
architects, 101
Telecom Operation Map (TM), 123
architectural design, 100
The System Under Consideration (TSUC), 81
artifact reuse, 100, 101
Total quality management (TQM)
modeling and analysis, 100
benefits, 82
project planning, 100
definitions, 82
requirements, 100
Manufacturing and Service Organizations, 82
software elements, 100
principles
testing, 100
continuous improvement, 83
definition, 95, 96
customer-focus, 83
framework
employee empowerment, 84
core assets development, 97, 98
managing supplier quality, 85
essential activities, 97
process management, 85
management, 99
product design, 84
product development activity, 98
use of quality tools, 85
software community, 97
service organizations sector, 82
technical and organizational
management, 97
product line architecture, 104, 105
U
Software Quality for the Product
Unified Modeling Language (UML), 13
(SQP), 34
Universal Plug and Play (UPnP), 117
Specific, measurable, attainable, realistic, and
time (SMART) bound, 78
Stakeholders, 145
V
business goals, 87
Virtual machine monitor (VMM), 9
definition, 86
process and product quality, 88
process improvement, 88
W
process improvement life cycle, 89, 90
Web services, 97
and roles, 87
Wide area network (WAN), 109
System architecture, 5
Wireless sensor networks (WSNs), 109
