Keywords

1 Introduction

A business process architecture (BPA) is a systematic overview of all main processes that manage the business in an organization (Dumas et al., 2013; Ould, 2005). Specifically, it is deployed as an organization high model that reflects the structuring of crucial business processes (BPs) and their connections (Gonzalez-Lopez & Bustos, 2019).

The development of a BPA is applied in different areas than the business of an organization. It is adopted to implement significant disciplines such as change management (Samhan et al., 2018). This could be explained due to the comprehensiveness, simplicity, and usefulness that BPA provides in presenting any business, especially if we are using essential business entities (EBEs) that identify this business. Thus, exploitation of BPA in presenting new technology such as cloud computing (CC) is suggested to reflect these features that BPA achieves in addition to other benefits such as interoperability and integration.

Cloud computing is a freshly established computing sector that has been utilized for information technology activities by a considerable number of enterprises throughout the globe (Jamsa, 2012). Cost savings, increased efficiency, increased agility, increased flexibility and scalability of services, and environmental sustainability are all advantages of moving to cloud computing (Odeh, 2020). Cloud computing grew in popularity as a result of its ability to transform the IT industry’s physiognomies via the usage of virtualization (Odeh, 2019). Meanwhile, several fundamental worries about cloud computing, such as security and privacy breaches, stem from the virtualized environment. Accordingly, the functioning of cloud computing is similar to that of information technology (IT) outsourcing (Joshi & Shah, 2019). However, the complexity of security makes quality control in cloud computing a challenging task (Halpert, 2011).

Cloud computing (CC) can be defined as a model through which users can access a shared combination of configurable software and hardware resources using the internet (Sultan, 2014). These resources are rapidly provided with minimum managerial effort (Siebel, 2019). It can be applications, servers, computer networks, data storage, or any other service. Companies with problems in adopting CC will be at risk due to market competition (Buyya et al., 2008). These problems include factors of high complexity from the review of the previous literature to determine the gap in this study. They include factors of high complexity, low compatibility, and less technological preparedness in cloud computing technology (Lynn et al., 2020).

Nevertheless, CC still requires development and progression in computer systems, software engineering, and performance engineering (Papadopoulos et al., 2019). It is also demanding as a modern technology to address caused-problems disasters in the Middle East and North Africa (MENA) (Al Kurdi, 2021). Cloud computing has emerged as one of the most influential IT paradigms of our time, addressing users’ needs for dynamic, high-capacity computing in a variety of applications like business intelligence and data collected and stored while effectively creating business value for cloud service providers out of (at least initially) surplus computing resources (Hugos & Hulitzky, 2010). Therefore, like with all emergent technologies, the lifespan of the paradigm will be decided by how specific difficulties are addressed.

In this paper, we use Riva method with its elements of units of work (UOWs), 1st and 2nd cut process architecture diagrams to introduce cloud computing business process architecture (CCBPA). A CCBPA is developed to present the CC domain and describe its elements. It is also used to clarify CC capabilities to integrate and support other fields. Evaluation of the CCBPA is accomplished using several criteria which imply perceived ease of use (PEoU) and perceived usefulness (PU). These criteria were argued to predict initial technology adoption (Liu & Prybutok, 2021). They also present cognitive beliefs, in the theory of reasoned action, that affect attitudes, intentions of use, and eventual use of objects such as CC (Karahanna & Straub, 1999).

2 Cloud Computing Definition

However, it seems that there are several definitions of cloud computing (Lehrig et al., 2015). According to Sultan (2014) (a multinational management consulting firm), there are a considerable number of different definitions of cloud computing. In reality, there seems to be no clear definition or standard for cloud computing. Clusters of dispersed computers (often massive data centers and server farms) that deliver on-demand resources and services across networked media are a more widely used definition (usually the internet) (Armbrust et al., 2010). The word “cloud” was most likely inspired by drawings in IT textbooks that represented distant settings (such as the Internet) as cloud pictures to hide the complexity that lay behind them. Understanding the types of services provided by cloud computing, on the other hand, helps to clarify what this new approach is all about (Armbrust et al., 2009).

3 Cloud Computing’s Main Features

Cloud computing is a recent and cutting-edge pattern of Information Technology (IT) service that provides software and hardware services on customer demand across the internet in a customer-operated mode and is unrestricted to device and location. It also has several features that support either integration or flexibility (Liu et al., 2011). Flexibility includes features of scalability, elasticity, pay-per-use, ubiquitous access, and low cost. On the other hand, CC supports the integration of IT resources. Resource pooling, data concentration, and a shared environment are critical features that increase an organization’s ability to integrate its data and multiple applications (Lehrig et al., 2015).

3.1 Scalability

Cloud computing service companies provide solutions that are both elastic and scalable. Despite their similarities in appearance, scalability and elasticity in cloud computing are not identical. Elasticity is the capacity of a system to expand or shrink dynamically in response to varying workload needs, such as an increase in website traffic. A flexible system adapts in real time to match resources as closely as feasible with demand. A company with fluctuating and unplanned requirements may use the public cloud as a flexible option (Jansen & Grance, 2011). As stated before, a system’s scalability relates to its capacity to expand workload while retaining current hardware resources. A scalable solution permits predictable, long-term expansion, while an elastic solution accommodates more urgent, unpredictable fluctuations in demand. In cloud computing, both elasticity and scalability are essential characteristics, but which one takes precedence relies in part on whether the organization’s workloads are highly predictable or very changeable (Lehrig et al., 2015). Due to virtualization, it is now possible to design a scalable cloud infrastructure. In contrast to actual computers, which have relatively fixed resources and performance, virtual machines (VMs) are very flexible and can be scaled with relative ease (Odeh, 2019). As needed, they may be transferred to a new server or hosted simultaneously on many servers, and workloads and applications can be migrated to larger virtual machines. In addition, cloud providers already own the great majority of the infrastructure and software resources required for rapid growth, which a single firm could not pay. Due to virtualization, it is now feasible to develop a scalable cloud infrastructure. Unlike traditional computers, which have set resources and performance, virtual machines (VMs) are very versatile and may be rapidly scaled up or down. They may be relocated to a new server or hosted on many servers simultaneously, and applications and workloads can be migrated to bigger virtual machines as required. In addition, the great bulk of infrastructure and software resources necessary for fast development are already owned by third-party cloud providers, which a single business could not afford. The following are the important cloud scalability aspects that encourage large and small company adoption: With a few mouse clicks, IT managers may build new VMs that are immediately accessible and customized to the business’s requirements. As a result, IT staff will save time (Masdari et al., 2016). Instead of investing hours or days to installing physical equipment, teams may devote their time to more crucial tasks. IT’s agility enables it to respond fast to changing and expanding business requirements, including unanticipated spikes in demand. Even the smallest companies now have access to formerly prohibitively expensive high-powered resources. Companies are no longer constrained by outmoded technology; they can quickly upgrade their systems and expand their power and storage capacity. Due to the scalability of the cloud, organizations may be able to save money by eliminating the upfront expense of acquiring costly, soon obsolete equipment. By using cloud service providers, consumers only pay for the services they use, hence reducing waste. Cloud-based disaster recovery minimizes the need to build and operate alternative data centers, hence decreasing the expenses associated with disaster recovery (Jamsa, 2012).

3.2 Elasticity

The solutions provided by cloud computing service providers are both elastic and scalable. Despite seeming similar, scalability and elasticity in cloud computing are not the same. Elasticity is the ability of a system to dynamically expand or contract in response to fluctuating workload demands, such as an increase in web traffic. A flexible system dynamically changes in real time to match resources with demand as closely as possible. A business with changing and unanticipated demands might use the public cloud as a flexible solution (Jansen & Grance, 2011). As mentioned earlier, a system’s scalability refers to its ability to increase workload while using existing hardware resources. A scalable solution allows for predictable, long-term growth, while an elastic solution handles more urgent, volatile changes in demand. In cloud computing, elasticity and scalability are both crucial qualities, but whether one takes priority over the other depends in part on whether the organization’s workloads are highly predictable or very variable (Lehrig et al., 2015). It is now feasible to construct a scalable cloud architecture due to virtualization. Unlike physical computers, which have relatively fixed resources and performance, virtual machines (VMs) are very flexible and can be scaled up or down with reasonable ease (Odeh, 2019). As required, they may be relocated to a new server or hosted on many servers concurrently, and workloads and applications can be migrated to bigger virtual machines. Additionally, third-party cloud suppliers already own the vast bulk of the infrastructure and software resources necessary for fast development, which a single company could not afford. It is now possible to design a scalable cloud architecture due to virtualization. In contrast to conventional computers, which have fixed resources and performance, virtual machines (VMs) are very adaptable and may be scaled up or down fast. They may be moved to a new server or hosted on many servers concurrently, and programs and workloads can be shifted to larger virtual machines as necessary. In addition, third-party cloud providers already own the vast majority of the infrastructure and software resources required for rapid expansion, which a single organization could not pay. The following are the essential cloud scalability features that stimulate adoption by both big and small businesses: With a few clicks, IT administrators may create new VMs that are instantly available and tailored to the specific needs of a business. IT employees will save time as a consequence (Masdari et al., 2016). Instead of devoting hours or days to assembling physical equipment, teams may focus on more important activities. IT’ s agility allows it to react rapidly to changing and growing corporate needs, including unplanned surges in demand. Even tiny businesses now have access to formerly prohibitively costly high-powered resources. Companies are no longer restricted by obsolete technology; they can easily update their systems and increase their power and storage capacity. Due to the scalability of the cloud, businesses may save money by avoiding the initial costs of purchasing expensive equipment that will quickly become outdated. By using cloud service providers, customers only pay for what they need and reduce waste. Cloud-based disaster recovery reduces the need to construct and run alternative data centers, hence reducing disaster recovery costs (Jamsa, 2012).

3.3 Pay-Per-Use Business Model

The pay-per-use model offers the advantage of not wasting resources since customers only pay for the services they use, as opposed to pre-purchasing a certain quantity of resources that may or may not be used (Odeh & Yousef, 2021). In traditional business architecture, users create data storage to handle the heaviest burden. In contrast, the pay-as-you-go model in the public cloud allows you to pay just for the data you store. Pay-per-use systems, such as Amazon EC2, enable clients to personalize their computing resources and pay only for what they use. The CPU, memory, storage, operating system, security, networking capacity, and access limitations, as well as any additional programs, are selected by the user. As mentioned earlier, cloud computing is a new paradigm for computer service delivery. As with any new service of this magnitude and complexity, there will be questions, ambiguities, and worries over the maturity of the technology. Control, vendor lock, performance, latency, security, privacy, and reliability are among the most urgent issues (Armbrust et al., 2009). However, security is one of the greatest issues for cloud computing, and it is one of the reasons why many firms are hesitant to use cloud solutions. Cloud computing requires a high level of security. Cyber-attackers’ other kinds of black hats try to get access to your network for personal gain, and the annual cost of cyber-attacks is enormous (Al-Ramahi & Odeh, 2020). Firewalls, anti-virus and anti-malware software, physical security measures including guarded data centers, and sophisticated authentication and authorization processes are used to protect our data and networks. Notably, though, the security challenge has a cloud-based solution that is gaining popularity. Security is increasingly provided as a managed service by a third-party provider, which bolsters the relevance of cloud computing (Halpert, 2011).

There are multiple obvious reasons why cloud-based security outsourcing is an excellent solution. As with many other types of cloud-based services, security is a highly specialized field. As a result, having access to the greatest security professionals in the market via a third-party vendor will offer greater protection, more knowledge and experience, and the capacity to move to more modern security systems and equipment than these organizations could deliver on their own. The defining characteristic of a cloud platform is that it enforces an instance of common software components that developers may “bolt on” to their applications rather than having to build them from scratch. This advantage is dangerous in terms of security.

4 Cloud Computing Models

Cloud computing can be classified into two main categories: deployment models and service models (Seethamraju, 2015). The first classification focuses on the managerial approach that the service provider represents. In comparison, the service model focuses on the technical process provided to the customers. In cloud computing, the phrase “services” refers to employing reusable, fine-grained components throughout a vendor’s network. This is often referred to as “as a service.” Characteristics of offerings with as a service as a suffix include the following: low entry hurdles, making them accessible to small enterprises, extensive scalability, and multitenancy, which enables several users to share resources. Device independence allows users to utilize the systems on various devices (Rao et al., 2015).

Cloud computing is not just a futuristic notion with a lot of potential. It has already become a reality, with several commercial applications. Cloud computing seems driven by economics, simplification, and ease in the delivery of computer-related services (Armbrust et al., 2009). Many authors believe that technology offers significant potential for lowering IT costs for businesses and relieving them of the price and trouble of having to install and maintain software locally.

From the technical perspective, cloud computing presents several types of service models: application as a service (AaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) (Jamsa, 2012). Applications are offered as a service across the internet at IaaS. Instead of installing and maintaining software, you just use the internet to access it, eliminating the need for complicated software and device maintenance. This cloud service provides full application capability, ranging from productivity (e.g., office-type) apps to programs like customer relationship management (CRM) or corporate resource management.

PaaS is a platform that gives web application developers access to development tools and hosting alternatives. Cloud computing is a new business model, distinct from those described by authors, who saw service as either a supplement to an existing physical product or a service relying on a provider using skills and knowledge (i.e., competencies) to provide clients with a solution (Tsui et al., 2011).

IaaS provides customers with the processing, storage, networking, and other computer resources they need to execute specific software (operating systems and applications) on their servers. The only disadvantage is that cloud providers are in charge of the infrastructure (Seethamraju, 2015).

Despite the several types of cloud service models, all of such classes are presented based on the same business model, which is pay-per-use. As mentioned before, the service provider will charge the cloud customers with the only actual uses. Such features may help customers save significantly in both the short- and mid-terms. However, the decision to adopt cloud technology in the long term requires a careful calculation and comparison between leasing and owning the information technology equipment. However, with the flexibility of cloud computing, none of those mentioned earlier providers can guarantee that their cloud goods will operate right out of the box. Google Apps, for example, is an example of an out-of-the-box messaging and collaboration cloud solution, even though it still requires some configuration (Arif et al., 2019). Using the cloud providers’ APIs, some level of development (i.e., programming) will be necessary (application programming interfaces). These are the programming instructions cloud service providers produce and make available to anyone who wishes to use their goods. Many of the APIs are now proprietary. This topic will be discussed more when we look at some of cloud computing’s limits and concerns.

The cloud deployment model consists of four main types. The first type is the public deployment model. In this type, the model provides an almost free cloud computing service with nearly zero cost. However, the public model is considered the less secure model level (Jamsa, 2012). In contrast, the second model, i.e., the private model is the most expensive cloud deployment type, which provides the highest security level. The community model is the third deployment model type, which focuses on the same type of customers who share the same interests, such as universities, tourism companies, and libraries. In this model, the cost will be shared in the community. The security level is usually fair compared with the cost of this type. The last deployment model type is the hybrid model, which is simply a combination of two or more models (Sultan, 2010).

Cloud computing is considered an umbrella, including several online services and models. It uses servers hosted on the internet to process and store data instead of using in-house resources based on a pay-per-use business model. The pay-per-use business model could be presented according to the following equation based on an assumption:

$$ C1:{P}_i;A;P $$
(1)
$$ C1:\kern0.5em \forall {P}_i\in P;A\left({P}_i\right)\le A(H) $$
(2)

Where Pi is the cost of the process, N represents the number of activities “a” in the process of Pi, and cost (a) denotes the cost of each activity a ε A. While device H with area A(H) and pins T(H) (number of programmable input/outputs (I/Os) per device).

$$ C2:\mathrm{TCCost}=\sum \limits_{i=1}^k\mathrm{CCost}\left({P}_m\right)=\sum \limits_{m={1}_{T_i\in {P}_m;{T}_j\in \overline{P_m}}}^k{\alpha}_{i,j}\le T(H) $$
(3)

Where TC Cost denotes total communication cost, CCost (Pm) denotes the communication cost of the partition Pm and the weight αi,j of an edge, and ei,j defines the amount of data transferred from Ti to Tj.

5 Methodological Approach

In this study, the data was collected using the qualitative approach through semi-structured interviews with experts in the domain. The reason for selecting interviews as a data collection method is to collect high-quality data from experts instead of surveys with a random sample. Experts in this domain include IT managers, professors in cloud computing, and experts in Riva methods. On the other hand, primary data was collected from the literature review. For the data analysis process, the authors have adapted the Miles and Hebrman data analysis approach, which includes data reduction, data display, and conclusion drawing/validation and verification. In addition, several software tools are employed, such as Nvivo and Microsoft Visio (Huberman & Miles, 2002).

6 BPA and Riva Method

Malinova et al. (2013) present two tracks to process architectures (PAs) based on the outcome of an empirical study. The first one is the decomposition PAs which include the pipeline, the hierarchical, and the divisional PAs. The second one is the service-oriented PAs. PAs in this classification can be described as non-systematic since no clear steps or rules are followed by these organizations to design their PAs. Another classification by Dijkman et al. (2016) stems from the basis on which processes and their relations are identified. Accordingly, five types of modeling approaches are suggested: object-based, action-based, goal-based, function-based, and reference model-based.

The Riva method (Ould, 2005) is defined as one of the object-based BPA approaches that exist in this field. Ould proposes Riva as a simple, obvious, practical and systematic approach for developing PAs from the essential business entities (EBEs). He also affirms that Riva BPA is unaffected by an organization in the same business.

The development of a BPA using the Riva method includes several steps. The steps are followed in this paper to generate a UOWs diagram for the CC discipline. The steps of the Riva method are the following:

  • Step One: Agree on domain and business boundaries.

  • Step Two: Brainstorm the EBEs candidates (CEBEs) and filter them into EBEs.

  • Step Three: Determine the units of work (UOWs).

  • Step Four: Determine each dynamic relationship between UOWs and generate a UOWs diagram.

  • Step Five: Translate the diagram of UOWs into first cut PA diagram.

  • Step Six: Translate the first cut PA into the second process architecture.

6.1 Demonstration of Riva BPA on CC

In this section, we apply the four steps of the Riva method to generate the UOWs diagram of CCBPA.

  1. A.

    Step One

According to Ould (2005), we define in this step what we are looking at. In our case, we are looking at the CC discipline which is the domain and boundary we are identifying.

  1. B.

    Step Two

Brainstorming CEBEs of the CC domain and filtering into EBEs are the most critical steps in building a CCBPA. This is due to its importance in carrying on the remaining steps and discovering the probability of generating a BPA for a CC domain using the Riva method. CEBEs are suggested to be identified through Ould’s suggested prompt questions, which facilitate listing these CEBEs. The questions are customized to be appropriate for BPA development of a domain rather than an organization business. Table 1 presents these questions and their corresponding CEBEs in the CC domain.

Table 1 Extracting CC domain CEBEs/EBES corresponding to Ould prompt questions
Full size table

After identifying these CEBEs by using (Ould, 2005) suggested questions, we discussed them with experts in the domain and we concluded that all these CEBEs characterize cloud business and can be reported as EBEs.

  1. C.

    Step Three

In this step, determining the units of work is the main task that is required. A unit of work is an EBE with a lifetime during which we look after. Excluding non-UOWs from the EBEs list does not depend on this definition alone. Further filters should also be applied to EBEs to identify UOWs. These filters include (1) excluding EBEs that are not classified as UOWs, (2) excluding also EBEs that are not UOWs, even if they are for someone else, such as national standards, which can be a UOW for quality group and not for a hotel or other businesses, (3) excluding EBEs that are roles which contribute partly in processes, and (4) excluding any that is implicitly part of other EBE and does not have its own lifetime.

By applying these filters, we remove the following EBEs from the UOWs list:

  • Vendor and Cloud Standardization are not EBEs with a lifetime we look after.

  • Hardware Component, Software Component, Customization, Operating System, Middleware, Data, and Networking are only part of IaaS EBE and do not have their own lifetime.

  • Application, Storage, Structure, Database, and Information are only part of SaaS EBE and do not have a separate lifetime.

  • Program Unit is only part of PaaS EBE and does not have a separate lifetime.

  • Internet Connectivity is part of Service Provider EBE.

  • End User, Developer, and Expert are part of Cloud User EBE.

  1. D.

    Step Four

After filtering EBEs into UOWs, we identify the dynamic relationships between them and draw the UOWs diagram. In the UOWs diagram, each dynamic relationship emerges when a UOW (such as X, for example) involves or generates another UOW (such as Z, for example) during the lifetime of X. The relationship is implemented using an arrow from the generating UOW (X) to the generated UOW (Z). Figure 1 shows the UOWs diagram of CCBPA after the identification of dynamic relationships between the UOWs.

Fig. 1
A flow diagram which consists of, 1. Cloud user, 2. Service provider, 3. Management of Cloud deployment models, that splits into, 3 A. Hybrid model, 3 B. Community model, 3 C. Private model, and 3 D. Public model, 4. I a a S, P a a S, and S a a S, 5. Pay per use and 6. On demand computing.

Riva UOWs diagram of CCBPA

Full size image

The arrow between any two UOWs is nominated by “g” in addition to the relationship number. The relationship number is for discrimination and does not always mean the sequence or the synchronization in generating these relations. For example, g6, g9, g12, and g15 are different relationships that indicate the generation of SaaS UOW. However, the number of each one does not reflect the sequence in their occurrence. Thus, a SaaS case or UOW could be generated asynchronously by one of the cloud models, whether it is a hybrid, public, community, or private cloud model.

  1. E.

    Step Five

Riva’s first cut process architecture is generated in this step. Each UOW is translated into a case process (CP), case management process (CMP), and case strategy process (CSP). CSP is not considered in this paper as it is still not well developed or clear as other Riva remaining elements, i.e. CP and CMP. A new CP means a new case instance we are handling. The CP and CMP are sequentially recognized by the word “Handle” and the phrase “Manage the flow of.” Relationships between UOWs are also translated into “starts,” “requests,” and “delivers” relationships. By applying these rules to the UOWs diagram in step four, we can generate the first Riva cut process architecture of CCBPA (see Fig. 2).

Fig. 2
A flow diagram which consists of, 1. Manage the flow of cloud users, 2. Handle cloud user, 3. Manage the flow of service providers, 4. Handle service provider, 5. Manage the flow of management of cloud deployment models, 6. Handle management of cloud deployment models, 7. Manage the flow of hybrid models, 8. Manage the flow of public model, 9. Manage the flow of private model, 10. Handle the models, 11. Handle P a a s, S a a s and I a a s, and 12. Manage the flows.

Riva first cut diagram of CCBPA

Full size image
  1. F.

    Step Six

After the development of the first cut Riva BPA in Fig.  2, a series of heuristics are applied in this step, where they can be applied. Heuristics are a kind of reduction that is applied to Riva first cut architecture to reflect or simulate the actual practice that exists in the real business world. These heuristics include (1) merging CMP into the requesting CP when CMP is a task force, (2) replacing two CMPs by one when we cannot distinguish between these two CMPs, (3) delivering interactions or chains when there is no delivery between the requested CP and the requesting one, then delivery interaction is removed or short-circuited, i.e, the drawn arrow between the requested and requesting CPs is omitted, (4) merging CMP in the requesting CP when its root UOW is part of another UOW, (5) and emptying CMP when we have only one case instance of CP.

The heuristics that we have identified in CCBPA first cut architecture are as follows:

  • Merging CMP into the requesting CP when CMP is a task force. The merged CMPs are as follows: management of the flow of the public model, management of the flow of the private model, management of the flow of the community model, and management of the flow of the hybrid model. These CMPs are merged in the requesting CP, which is handling the management of cloud deployment models.

  • Emptying CMP when we have one instance of CP. In CCBPA, we have one instance of Service Provider, which is the company that offers cloud services. A one-case instance does not require a CMP to manage. Thus, we remove the management of the flow of Service Providers CMP.

The researchers identify no other heuristics. However, we have identified previous heuristics that require reconfiguring start (s) relationships by changing their source from CMP to CP. These new start relationships in Riva second cut process architecture of CCBPA are g0s, g2s, g3s, g4s, and g5s. Thus, the Riva second cut of CCBPA is generated by applying these heuristics and their required changes (see Fig. 3).

Fig. 3
A flow diagram which consists of, 1. Manage the flow of cloud users, 2. Handle cloud user, 3. Handle service provider, 4. Manage the flow of management of cloud deployment models, 5. Handle management of cloud deployment models, 6. Handle hybrid, community, private and public models, 7. Handle I a a S, S a a s and P a a s, 8. Manage the flow of S a a s, P a a s and I a a s, 9. Handle Pay per use, and On demand computing and 10. Manage the flow of on demand computing and Pay per use.

Riva second cut diagram of CCBPA

Full size image

6.2 Evaluation of CCBPA

An evaluation of CCBPA has been conducted after the generation of Riva-based CCBPA. The evaluation includes validation of CCBPA by checking the validity of its elements. It also involves checking the CCBPA support to understanding, presenting, and the ease of use of the CC domain; recognizing CC usefulness; deciding to adopt CC in business; and integrating CC with other related disciplines. EBEs, UOWs and their relationships, CMPs, CPs, first cut process architecture, and the adopted heuristics to the second cut process architecture are the essential elements that are hired to test validity. The evaluation has been performed with the collaboration of a few experts in the domain. Table 2 shows the results that indicate this evaluation through which the whole Riva-based CCBPA is evaluated.

Table 2 Evaluation of Riva-based CCBPA
Full size table

7 Conclusion

Developing a BPA for CC can support the understanding and simplifying of this domain. It also allows CC utilization and integration with other fields. An object-based BPA method called Riva has been adopted to achieve this aim. Riva has precise steps that have been applied to the CC domain. Accordingly, the main elements of Riva BPA have been generated. These elements characterize the CC domain including EBEs, UOWs diagram, and first and second cut process architectures.

Developing a CCBPA using the Riva method implies many implications. These implications are reflected through clarification and high-level presentation of CC models, services, and elements that a business might need, in addition to determining the track that an organization should follow in CC. The implications are also reported in support of resolving problems of complexity, compatibility, and technological readiness in CC. Furthermore, the managers’ awareness of CC usefulness is higher, and their decision on CC adoption is getting easier.

In conclusion, developing a CCBPA has provided a comprehensive view of CC and its business flow. It also paves the way to further business modeling and cloud computing research.

8 Research Limitations and Future Direction

Different business process architecture model lines that could be used as a benchmark to evaluate CCBPA in this paper are still not evident to the researchers. This includes approaches such as goal, action, and function-based approaches.

Further research is recommended to evaluate CCBPA by engaging new case studies that plan to adopt CC in the work environment. Also, knowledge life cycles and knowledge management processes are suggested to be mapped with elements of CCBPA.