1 Introduction

Modernizing or designing a new business process by reusing the functionality of existing software can be of great benefit to organizations. Leveraging previous developments and considering internal company solutions enriched with external ones, can help facilitate the development of complex systems at controlled costs while maintaining delivery times.

When developing a software, the first thing to do is to understand and describe in a precise way the problem that the software must solve. Requirements for a targeted system describe what the system should do, what the services it should provide, and what quality or constraints it must have to make it attractive and acceptable to the owner [1]. These requirements reflect the needs of customers for a system. The process of analyzing, eliciting, and checking these services and constraints is called requirements engineering [2].

To maximize the reuse opportunities for companies, a component view with a concise evaluation model of software components (that describe in detail the capabilities of software) provides an overview of existing solutions and facilitates the discovery, selection, and decision to reuse [3]. This, combined with an organization of the different artifacts (an artifact is a more granular architectural work product that describes an architecture from a specific viewpoint. Examples include a class diagram, a server specification, a list of architectural requirements, etc.) resulting from this evaluation model, aligned with a requirement engineering approach, aims to reduce the complexity when searching and selecting software components to reuse. In addition, focusing on service-oriented solutions, many opportunities for reuse of functionality will arise, resulting in more efficient use of existing resources.

To reduce the complexity of the description of software components that result from the evaluation model and to present the required detail of information at each level of its exploitation, enterprise architecture is of great value. Enterprise architecture (EA) is the definition and representation of a high-level view of IT systems and enterprises business processes. By considering an enterprise architecture-based approach, it is possible to organize the different artifacts in a way that enables to analyze the reuse possibilities for an organization, and ensure the feasibility of a targeted system or project. The insights or information provided by an enterprise architecture is needed, on the one hand, to determine, from a business perspective, the needs, and priorities for change [4] and, on the other hand, to organize the various components and technical artifacts and assess how an organization can exploit them.

With reference to this context, this research is an extended work of an already published work in [5]. The latter was focused on the design of a software capability profile implemented as a semantic model to gather description of the capabilities of existing solutions from several perspectives (organizational, business, technical and technological aspects). For the sake of readability, the proposed model and contributions published in [5] are presented in the following sections, as well as the new contributions related to the exploitation of the capability profiles through the alignment of a requirements engineering approach and an enterprise architecture method. As discussed earlier, the objective of this research work is to leverage the model already published in [5] to address stakeholder requirements and efficiently reuse existing solutions, by investigating the highest functional and non-functional compatibility of existing software capability profiles with stakeholder’s desired features to be implemented. The expected result from this work is an exploitation process of the software capability profiles, based on the architecture development method from TOGAF [6], aligned to a requirements engineering approach implemented using Volere Specification [1]. However, the problem we faced is how to align requirements and architecture artifacts in an engineering cycle, to help in the refinement of requirements and select the best candidate components to serve as building blocks in a new system?

To respond to this research problem, this paper is organized as follows: Section 2 focuses on the related work. We focus afterward on the principal building blocks of the proposed solution and present first the Enterprise Architecture Capability Profile (EACP) in Sect. 3. Section 4 presents a concrete use-case scenario on which this approach has been applied and that serves as an example throughout the description of the exploitation process in Sect. 5. Section 6 presents an implementation of the proposed approach. Section 7 discusses our work, and finally, a conclusion is drawn in Sect. 8.

2 Related work

2.1 Requirements engineering in software development process and service reuse

Classical techniques for software solution specification are structured analysis and object-oriented techniques [7]. The view of requirement engineering as solution specification is taken by the IEEE 830 standard [8] and by other authors on requirements [1, 9]. In this view, and as mentioned by [7], a requirements specification consists of a specification of the context where the system operates, desired system functions, semantic definition of these functions, and quality attributes of the functions.

Several research works and methods ([10, 11] or [12]) exist in the literature to enhance software requirement specifications and for feature selection. Robertson and Robertson [1] propose Volere as a basis for a requirement specification. It is a result of many years of practice, consulting, and research in requirement engineering and business analysis. Volere provides template sections for each of the requirement types appropriate to today’s software systems. Xu et al. [13] propose a paradigm for software service engineering to reuse services for developing new applications more rapidly with the aim of satisfying individualized customer requirements. The proposed approach uses service context as a mediating facility to match a service requirement with a service solution. The requirements are defined by the targeted business functionality, service performance, and value. However, no details about the service pattern description or repository, the requirement template nor an implementation of the approach are proposed. Chen and He [14] propose a method that allows users of services to express their requirements. The authors propose a meta-model for elements required in-service consumption, such as process, goal or role. The proposed method helps to discover errors and conflicts during requirement refinement. Zachos et al. [15] propose a service selection algorithm based on textual requirement expressed by the service consumer. The service selection is based on a discovery algorithm, which uses XQuery and WordNet and focuses on the disambiguation and completeness of the requirements and retrieving discovered services from UDDI registry. There are additional ontology-based research works such as [16], where the authors took the CORE Ontology (for Core Ontology for Requirements) [17] for requirement elicitation, and established a relationship with the concepts of Web Service Modeling Ontology (WSMO) [18].

2.2 Knowledge management and service repositories for service reuse

Research on repositories for an effective and useful management and discovery of services for service-oriented paradigm has recently earned significant impulse. Some specifications as UDDI [19] or ebXML Registry [20] have provided primary support to register, discover and integrate services. Due to limited capabilities offered by existing registry specifications for services discovery, some research works in the literature aim at improving service repositories with ontology-based discovery facilities. Later, semantic models have been proposed to enrich service registry with semantic annotations, combined with matchmaking algorithms to match service capabilities.

Based on the systematic analysis of relevant research works regarding service discovery with consideration of our needs, Table 1 classifies the related service registry and discovery works published between 2002 and 2019 according to the following criteria: (C1) Organizational level: exploitation based on the identification of the stakeholders, business problems, goals, and objectives of the targeted project. (C2) Functional level: exploitation based on service interfaces, the business functions and related inputs and outputs. (C3) Technical level: exploitation based on the identification of relevant technical requirement, interoperability requirement and technology constraints. (C4) Technology level: exploitation based on the identification of the platforms and infrastructure. (C5) Non-functional properties (QoS, Security...). (C6) Exploitation based on a Requirements Engineering Process (it involves all the mentioned levels)

Out of Table 1, we notice that several research works considered the functional level and QoS to manage service repository and matchmaking, but few of them considered the other levels such as the organizational level, the technical or technology level. We notice also that few research works considered the exploitation of the service registry in a software engineering cycle using a requirement engineering process to manage the user requirements for service discovery and matchmaking. Software architecture helps to manage the complexity of software by providing an abstraction of the system. Requirement engineering process drives the architecture actions, whereas decisions made in the architectural phase can affect the achievement of initial requirements and thus change them. We should go through these two fundamental activities, namely requirement engineering and software architecting during the engineering process. These activities should evolve together to offer support to the developer or architect for formalizing the requirements and architectural artifacts to enable software and service discovery and reuse. There is, however, no structured solution (as depicted in Table 1) on how to perform the co-development of requirements and architecture actions to select the suitable software or services to reuse for the development of new business software.

Table 1 Service repository and discovery for reuse
Full size table

2.3 Scientific relevance and discussion

From the state of the art on service-oriented software reuse, we analyzed that currently ad hoc methods are still used to identify the most suitable service-oriented software or artifacts to reuse, and a methodology or standardized process enabling this is still missing. Moreover, the description, the capability, or qualification of these software are lacking wider view qualification taking into consideration the business, operational, and technical views of the software and their related services [5]. In addition, no solution has been provided to fit the requirements engineering along with the impact of architecture on requirements when dealing with the identification of the most suitable components and avoid the misevaluation during the selection phase. Therefore, enhancing the capability description of the software and its related services in different levels of service description, along with its exploitation based on requirement engineering and architecting actions, is a big challenge. This analysis highlighted the need for an Enterprise Architecture-based methodology for describing and classifying different artifacts to be available as building blocks for reuse in future projects.

From the above analysis, we propose the following research directions: (i) improve software and related service capability profile to bring value-in-use of the qualified feature for an organization that is interested into reuse; (ii) shape a mechanism to identify the most suitable software with specific features or functionalities helping to overcome the use of ad hoc methods; (iii) improve the reuse of service-oriented solutions by considering a process that includes requirements engineering and enterprise architecture for formalizing the requirements.

Fig. 1
figure 1

Proposed meta-model

Full size image
Fig. 2
figure 2

Basic pattern of the main classes and relationships in the EACP ontology

Full size image

3 Qualification model—software capability profile

To bring the value-in-use of existing software and facilitate the discovery and reuse, we present in this section the meta-model of the software capability profile (see Fig. 1) and its related EACP Ontology that is presented in detail in [5] and depicted in Fig. 2. The meta-model is inspired mainly from TOGAF [6], ISO 16100 [55], Microsoft Application Architecture Guide [56] and ISO 25010 [57]. It aims to gather functional and non-functional specifications; the organizational impact of an organizations’ software; it links the business services to their related physical components to offer a wider view qualification and improve the reuse when developing a new business application. The proposed meta-model is composed of six packages. (i) Organization package: Composed by the organizational unit, with its related business goals and objectives that guided the development of existing software. (ii) Architecture building blocks package: This entity is constructed according to the life-cycle creation of architecture building blocks (ABBs) based on the ADM method. An ABB describes the business problem for which this component was developed for, its implementation specification, standards used, the stakeholders concerned. It provides other details such as the operational vision of the component, the definition of the business function of the ABB, its attributes and constraints, data and application interoperability requirements and design-time quality attributes. (iii) Solution building blocks package: SBBs represent the physical equivalent of ABBs and describe the components exposed by software. The SBB is linked to the exposed service or API, for instance, over the web in case of a REST-based application. This latter is defined by the URI, the HTTP method needed to get access to the resource, the related parameters and the serialization used in communication (for instance JSON). It defines run-time and transversal quality attributes, which might be updated according to the defined frequency for each attribute. (iv) Application package: Describes the technical requirements of the service-oriented software in general with its exposed components (for instance, REST services). It also describes the execution environments on which the application is running. (v) Business process package: This package is used in the exploitation phase and represents the “to-be” business application to realize. (vi) Requirements package: This package is used in the exploitation phase and represents the requirements elicitation process, helping to guide the developer or the architect during the engineering life cycle. The requirements are elicited in each phase of the ADM, going from the definition of project driver to the definition of the use cases and requirements in different levels.

Fig. 3
figure 3

Screenshots of the targeted business application

Full size image

The resulted EACP profile instances are saved in a semantic repository called in this context the Enterprise Architecture Knowledge Repository (EAKR repository) as an ontology instance. Regarding the design effort of the EACP Ontology, we identified from state-of-the-art solutions some existing ontologies to reuse. We have selected those that cover some of our needs and that are well-defined, consistent, and reused in other projects. We selected Basic Formal Ontology (BFO) which is a top-level ontology and four domain ontologies, namely Ontology Web Language for Services (OWL-S) [58], The Open Group Architecture Framework ontology (TOGAF-Ontology) [59], BPMN 2.0 Ontology [60] and Information Artifact Ontology (IAO) [61]. Third, we managed the selected foundational and domain ontologies, by integrating and extending in a coherent way the different ontologies into the targeted EACP ontology using the Protégé Ontology Editor. Finally, we evaluated the consistency of the resulted model using the Fact++ reasoner. An extract of the related Ontology to EAKR repository is presented in Fig. 2.

The scope of this paper does not concern the presentation of the qualification model and the design of its ontology mentioned above and presented in [5]; however, the elements presented above are enough for the understanding of the exploitation phase that will follow.

Fig. 4
figure 4

Exploitation plan

Full size image

4 Use-case scenario

This section presents the use case that will serve as an example for the description of the following exploitation process. This use-case scenario involves two companies. The first company is specialized in plastic manufacturing, and the second in metal manufacturing. Both companies have significant expertise in engineering and transforming plastic and metal, respectively, parts using several technologies. Their key business issue is the difficulty to detect the most appropriate business collaboration opportunities among common customer projects. Starting from a computer-aided design (CAD) description of customer projects, the companies consortium needs to quickly detect the set of projects that they are enabled to produce. The proposed use-case aims to accelerate and maintain a collaboration channel in two complementary business domains. The objectives are to reduce project quotation costs and reduce the delay of customer quote treatment.

Currently, clients send product requests to one of the companies in the form of CAD/PDF files. Then, the chosen company decomposes all the projects features (e.g., parts, dimensions, type of surface, and type of raw material) to understand customer needs to verify the feasibility of the product, and to determine the relevance of the business opportunity in terms of return on investment. After the decomposition and if there is a need for subcontracting (especially for multi-physical and complex products), the two companies will carry out a succession of negotiations, explore several ways to reach the clients requirements and submit their best offer to the client. For this purpose, we derive from this use case all needed requirements that we need to discover existing technical services that allow to reduce cost and development time. In what follows, we present how the developer goes through an architecture and requirement elicitation process to discover existing services and develop the needed business application. We present an example of the inputs needed in each phase of the exploitation process. A screenshot of the developed prototype is presented in Fig. 3.

5 Exploitation process

To design a new business application reusing technical services from the EAKR, the architect or developer goes through a requirement elicitation process. This process depicted in Fig. 4 is structured in several phases starting by the architectural vision, going through the business architecture, data, application, and technology architecture phase, leading to the generation of an implemented BPMN which uses the qualified services if a match confirmed. In the following subsections, we describe the actions to realize in each phase, enriched with a concrete example from the use-case scenario to strengthen the understanding. Templates in JSON format are also proposed to formalize the architecture artifacts and requirement specifications in each phase.

Fig. 5
figure 5

Phase A: alignment of architecture and requirements artifacts

Full size image
Fig. 6
figure 6

Example of architecture artifacts managed during phase A and related model

Full size image

5.1 Phase A: architecture vision

The objective of this phase is to develop a high-level vision of the business value to be delivered as a result of the project. This phase is mainly focused on gathering the business goals and related objectives of the targeted project. Other architecture artifacts are used to structure the project drivers, such as the identification of stakeholders, definition of the organizational model of the company, and KPIs enabling to evaluate the targeted business application. Based on the architectural artifacts of phase A (see Fig. 5 for the exhaustive list—column ADM artifacts), we fetch requirement patterns (see Fig. 5 for the exhaustive list from Volere specification—column Requirements) produced during previous projects to guide and support the developer for the upcoming requirement definition. If a template is found, it is presented to the developer. In addition to the architecture artifacts, the developer formalizes his requirements by defining the project drivers such as the business actors, the client, and customer if applicable. These inputs help to consolidate the elicitation phase and redesign his requirements before going further in the process. All the artifacts once validated are saved in the EAKR to be reused as requirements templates in future exploitation process.

Figure 6 illustrates an example from the use case with some proposed architecture artifacts and requirements for phase A. The main inputs are the definition of business goals and objectives of the targeted system, along with stakeholders that define people who have an interest in the targeted system and whose inputs are needed to build the product.

5.2 Phase B: business architecture

The objective of this phase is to develop the target business architecture that describes how the enterprise needs to operate to achieve the business goals previously defined and responds to stakeholder concerns. This phase focuses on the business side and supports the developer or architect to prepare all required inputs which are presented in Fig. 7.

Fig. 7
figure 7

Phase B: alignment of architecture and requirements artifacts

Full size image
Fig. 8
figure 8

Example of architecture artifacts managed during phase B and related model

Full size image

The most important architectural artifact in this phase is the high-level business scenario. This is designed using BPMN which is a standard language for business process modeling. This first high-level modeling is designed using ArchiMateFootnote 1 which is recognized as a standard for EA modeling by the Open Group [62] and that supports business process modeling. This high-level modeling helps to define the business-entity relationship to know which entities are needed for every business action or behavior.

This business model is enriched with other architectural artifacts (see Fig. 7 for the exhaustive list—column ADM artifacts) such as the actor catalog updated with their related roles, and the definition of the architecture requirements specification which form a major component of an implementation contract and provides quantitative statements as required in ADM Phase B outputs. It requires the definition of the implementation specifications to guide the development work, implementation standards in case the implementation should follow some specific standard. Figure 8 depicts the model of some architecture artifacts managed during this phase and shows an example of the proposed template for some of these architecture artifacts.

Once these elements are defined, a request is sent to the EAKR to fetch requirement templates of phase B produced during last projects to be reused. The aim is to guide the developer to define the project constraints and the functional requirements as depicted in Fig. 7 and inspired from Volere specification (column Requirement). The resulted templates from the request (if any) present the scope of previous projects sharing the same context, the existing business events connected to the actual business scenario, the use cases of the project or solution, and a set of functional requirements related to the selected use cases and their type, i.e., service type component related to an SBB or user task activity if it is a user action. Figure 9 depicts the model of the different artifacts that may result from the EAKR and shows an example of the proposed template for some of these artifacts.

These resulted templates are presented to the developer to guide him during this phase B for the consolidation and refinement of his requirements. It helps to offer support for defining and consolidating the use cases and related functional specifications. The proposed template is inspired from the Atomic Requirement Template, which is proposed by [1] and depicted in Fig. 10. This phase B ends with well formalized, testable, and categorized as user or service task functional requirements.

Fig. 9
figure 9

Example of requirement artifacts managed during phase B and related model

Full size image
Fig. 10
figure 10

Phase B: requirements template selection

Full size image

5.3 Phase C: information systems architecture—data architecture

The objective of Phase C is to develop the targeted information system architecture. It involves a combination of data and application architecture. Therefore, this phase is composed of two sub-phases, the data and application architecture.

Data architecture phase enhances the definition of the relation between data entities and targeted business functions previously defined in phase B. We have already depicted in Fig. 9 the models that enable to link data entities associated with each business function. Then, the needed action in this phase is to define the properties of each business entity involved in the business functions using relevant data models such as the class diagram in the Unified Modeling Language (UML). To this end, we propose templates based on the proposed models for the definition and formalization of the data entities involved in a business function. An example related to the use case is depicted in Fig. 12. The left side of the figure depicts the definition of a class model, and the right-side links an entity with its attributes to a specific business function where the entity is used.

Additional architecture requirements specifications are as-well formalized such as Data Interoperability or Technology Architecture Constraints (see Fig. 11 for the exhaustive list—column ADM artifacts). These constraints have the same description template as for requirements. The data interoperability requirement is needed to formalize specific needs for security policies as for example input validation or for data format and serialization. Regarding the technology architecture constraint, it helps to identify constraints on the infrastructure about to be designed (Fig. 12).

During this phase, architecture artifacts and requirements are defined at the same time because we are reaching the low-level description regarding the business application to develop. Based on these inputs, we fetch and map in the EAKR the ABBs and business functions using the defined data entities, and which are compliant with the constraints if defined (see Fig. 13-left column for an ABB template example). The related SBBs and their corresponding technical components are gathered to highlight potential problems of integration and are presented in the proposed template depicted in Fig. 13-right column. The related models of ABB, SBB, and application package are already described in Sect. 3 and in [5].

Fig. 11
figure 11

Phase C—data architecture: alignment of architecture and requirement artifacts

Full size image
Fig. 12
figure 12

Data architecture artifacts example for Phase C

Full size image
Fig. 13
figure 13

Requirement: partner or collaborative applications (to highlight potential problems of integration)

Full size image
Fig. 14
figure 14

Phase C—application architecture: alignment of architecture and requirement artifacts

Full size image

5.4 Phase C: information systems architecture—application architecture

This phase deals with the application architecture artifacts and the corresponding requirements (see Fig. 14 for the exhaustive list of the artifacts). The developer or architect is guided to define the technical requirements in the same template as for the atomic requirement (see Fig. 15—left side for an example). Technology or infrastructure constraints and application interoperability requirement are either defined in this phase. Those constraints are added to previous ones to fetch for SBBs and related applications in the EAKR. The resulted SBBs and related application (middle and right sides of Fig. 15) offer the first overview of existing applications and related technical services (in case of service-oriented solution) to reuse. These solutions fit the requirements and constraints from a functional, technical, and technology constraint side. Up to this requirement level, a first version of the targeted business application based on BPMN 2.0 is generated. The user and service tasks are generated and a link between service tasks and a set of existing services is performed based on the elements defined during previous phases (related to selected SBBs). This first solution reflects the prototype to realize, aiming to resolve and meet the business need expressed during this elicitation process.

Fig. 15
figure 15

Application architecture artifacts for Phase C

Full size image
Fig. 16
figure 16

Phase D: alignment of architecture and requirements artifacts

Full size image
Fig. 17
figure 17

Phase D: technology architecture artifacts template example

Full size image

5.5 Phase D: technology architecture

The last phase D is about the technology architecture artifacts (see Fig. 16 for the exhaustive list of the artifacts). The objective of this last phase is to define the basis of the implementation work. As part of phase D, the developer or architect needs to consider what relevant resources are available in the EAKR repository to ensure that the target system will meet some or all the requirements and constraints. It is important to recognize that in practice it will be rarely possible to find and reuse components that reach 100% coverage of all defined requirements and constraints. During the previous phase C, technical and technological constraints are formalized. These latter are considered during this phase D when matching the final SBBs, enriched with non-functional properties defining the Quality of Service needed from the existing services.

The model of non-functional requirement is based on the atomic requirement model. An example of the definition of this non-functional requirement is depicted in Fig. 17. The resulted SBBs, if a match is confirmed, reflect strongly the defined requirements and constraints. This helps to implement the business process already produced during the last phase with the final SBBs and related services with their service endpoints to support the business application. The resulted SBBs are ranked as already defined by [63] for QoS ranking, reflecting the non-functional specifications before selecting the final SBB and generate an implemented business process. The result of this ranking process is used during the generation of the implemented BPMN, where for each business function (only service tasks), we assign the first ranked SBB to the related task (see Fig. 18 for an example). In the next section, we present the implementation of a prototype of this exploitation process developed as a Web Application.

Fig. 18
figure 18

Example of an implemented BPMN resulted from Phase D

Full size image

6 Framework implementation

We implemented the exploitation process as a Web Application as depicted in Fig. 19. The source code is available at Github repository.Footnote 2 The video of this technical presentation is available hereFootnote 3 and of the entire use case is available here.Footnote 4 We selected AngularJS [64] as a Web Framework that enables the development of single-page applications following the MVC (Model-View-Controller) pattern for the front-end environment, and NodeJS Framework [65] which is a popular platform for building server-side Web Applications written in Javascript. Regarding the EAKR repository, we deployed the EACP Ontology along with example of qualified open-source solutions from vf-OSFootnote 5 and FITMAN projectFootnote 6 in Apache Jena Fuseki [66] (see Fig. 20).

Fig. 19
figure 19

EACP Web Application—Phase A: architecture artifacts

Full size image
Fig. 20
figure 20

EAKR based on the EACP Ontology and Apache Jena SPARQL Endpoint

Full size image

In the following subsections, we describe how a developer or architect can interact with this application in each phase, what inputs are required (based on the use case presented earlier in this paper), how information is presented, and how validation occurs.

Note that in the case where no artifact was found in the repository with a perfect match, we used string similarity based on Dice’s coefficient. Several open-source JavaScript packages exist. We selected the string-similarity package that is publicly offered in GitHub repository.Footnote 7 We fixed the threshold to 90%, which could be modified to get flexible results.

6.1 Phase A: architecture vision

In this phase, one of the artifacts to provide is about the business goals and associated objectives of the targeted project. The offered design possibility is to upload the inputs designed in ArchiMate using the motivation extension. Figure 19 depicts an example from the proposed use case of the motivation diagram. An export in XML format is needed to import it to the EACP Web Application to parse it and retrieve the needed inputs for phase A. Figure 19 depicts the phase A of the Web application. The first column is the architecture and requirements elicitation process that guides the developer to consolidate and validate their requirements during this phase. The second column displays the actual phase state and the progression rate of the process. The developer can as well add other stakeholders not mentioned in the motivation diagram to be considered for the next actions.

Once the motivation diagram uploaded to the framework, a parsing of the XML source file is realized to retrieve the defined business goals and objectives. Based on these inputs, a request is sent to the EAKR (see an example of a SPARQL request in Fig. 20) to fetch existing requirement templates guiding the developer during this requirement elicitation phase. Since it is the first instance of this process, we are not supposed to get any template. However, and for illustrative reasons, we defined one template that shares the same business goal to have an example of a template to reuse for defining and consolidating the required requirements for this phase. As we may notice in Fig. 19, the requirements needed are the definition of the business context, the client and the customer of the system which is not applicable in this context, and the users that will interact with the targeted system. The retrieved templates are presented in the ”EAKR Templates Requirement” side. The process progression column is updated, and the application now is waiting for the validation of the requirements to redirect the developer to phase B of the exploitation process.

6.2 Phase B: business architecture

Based on ArchiMate Business Entity Relationship diagram, the developer uploads the designed diagram to the architecture artifacts user interface. This latter is parsed to retrieve the actors, the business processes and related data entities involved in each business process or use case. These inputs are considered during the requirement pattern search in the EAKR repository and retrieved using the process depicted in Sect. 5.

The requirements specification of phase B deals with the functional requirements and constraints of the project. Based on the use case list and their related data entities, we fetch the previous project that has been saved to the EAKR based on a string similarity. These existing requirements help to offer support for defining and consolidating the use cases and functional specifications close to the actual context, the business events connected to the actual business scenario and a set of functional requirements related to the selected use cases and their type (i.e., service-type component related to an SBB or user task activity if it is a user action). In the case of our business scenario, no template has been found but for illustrative reasons, we initialized requirement templates that correspond to the actual business scenario to be reused.

In this phase, there is a possibility to enrich the functional specifications by adding required constraints or architecture requirements specification such as the specification of implementation or the usage of a specific standard for the future development of the functional requirements. In the context of this proposed scenario, we link an implementation standard to the functional requirement “Visualize CAD file” as depicted in Fig. 21.

Fig. 21
figure 21

EACP Web Application—Phase B: requirement specification

Full size image

6.3 Phase C: data and application architecture

Data architecture phase enhances the definition of the relation between data entities and targeted business functions previously defined in phase B. Then, the next needed action is to define the properties of each business data involved in the business functions using relevant data models such as the Class Diagram in Unified Modeling Language (UML) that is serialized to retrieve the entities with their related attributes.

Based on these inputs, the application fetches and maps in the EAKR the business functions with the architecture building blocks using the defined data entities, and which respects the interoperability and infrastructure constraints as defined in Sect. 5.3. This latter matches between the defined functional requirements with business functions defined in ABB model. ABBs that correspond to the conditions are selected with their related SBB and corresponding applications. The objective is to highlight potential problems of integration in case any selected ABB presents data interoperability constraint which is different from the defined constraint in this phase C. Regarding the Application Architecture phase, the developer is guided to define the technical requirement using the same template as for the functional requirements. Technology or infrastructure constraint is either defined. Those constraints are added to previous ones to select the SBBs as described in Sect. 5. For instance, in this use-case scenario, we define a technical requirement related to the targeted business function ”Visualize CAD File”. Indeed, we target an SBB which manages the CAD Objects with a specific file extension ”STL extension” and that is based on the JavaScript library Three.js. Then the action ”Fetch ABBs” triggers the selection of the targeted ABBs and related SBBs in the EAKR that respect the defined technical requirement for each business function along with the technology constraints if defined. The result of this action is depicted in Figure 22.

Fig. 22
figure 22

EACP Web Application—Phase C: requirement specification

Full size image

To this level, these inputs enable to download a first version of the targeted business application based on BPMN 2.0 specification. Based on the functional requirements defined in phase B which are composed by user and service tasks, we generate an XML template (see Fig. 18).

6.4 Phase D: technology architecture

During the previous phase, technical and technological constraints are formalized. These latter are considered when matching the final SBBs, enriched in this phase with non-functional properties defining the Quality of Service needed from the existing services. This to consider what relevant resources are available in the EAKR repository to ensure that the target system will meet the requirements and constraints. In the proposed use-case scenario, we define an example for the QoS which is depicted in Fig. 23 (NFR List). We set the average instance time metric as a non-functional requirement applicable for all the targeted technical services. After validation, SBBs are ranked based on the defined QoS threshold values.

For each business function, we select the first SBB resulted from the ranking process as a building block to reuse for the implementation of the targeted business application. As a final result, we get a last version of an implemented BPMN with the related service endpoints of the solution building blocks.

Fig. 23
figure 23

EACP Web Application—Phase D: requirement specification

Full size image

7 Discussion

In this work, we propose an Enterprise Architecture Capability Profile specifically designed for service-oriented software enabling the qualification, the discovery, the reuse, and the sustainability for new business applications development. We demonstrate how the proposed approach can assist developers or architects in the qualification process using the semantic Enterprise Architecture Knowledge Repository, based on a proposed meta-model inspired mainly from TOGAF and ISO 16100 Standard and formalized using semantic web techniques. This helps to offer a wider view qualification process that deals with the two perspectives of services which are the business perspective which brings value-in-use of the qualified feature for an organization that is interested into reuse, and the technical side along with a quality of service of the feature encapsulated by the software service. An exploitation methodology is defined to overcome the use of ad-hoc methods to identify the most suitable components or artifacts to reuse. The proposed solution is designed based on the alignment of architecting actions with a requirement engineering process, and evolve together helping to investigate the highest functional compatibility of the desired functionalities and its related constraints.

As discussed in [67], on some projects, architectural requirements can be significantly more important than their domain-specific equivalents (as for instance, if we are designing a business application with a specific high availability as implementation constraint, the “up time” metric would be with a high importance). Regarding the proposed exploitation methodology, it carries the validation of the requirements and drives the design of the foundations (i.e., architecture) and the requirement definition of the business application we are building. This means at least, we offer the necessary structure for defining and validating architectural artifacts and requirement specifications, and at best, propose templates and artifacts of previous projects or qualified solutions for recycling and reuse to meet the business need.

Regarding the exploitation process, as you may notice at run time, the process finds few results because no previous project with its related requirements has been already introduced and capitalized. Also, it depends on the number of the qualified solutions and related services considered as architecture and solution building blocks in the EAKR Repository. Continuous qualification is needed to maximize the exploitation and must be realized frequently to take full advantage of this proposed methodology.

8 Conclusion

In this work, we defined the Enterprise Architecture Capability Profile that describes the business, operational and technical aspects for service-oriented software. It is designed based on an Enterprise Architecture Framework (TOGAF) and the best practices related to the implementation of ISO 16100 standard concepts. An exploitation methodology of the designed capability profile is proposed and based on the alignment of a requirements engineering process with the Architecture Development Method from TOGAF. These latter evolve together to investigate the highest functional and technical compatibility of the desired functionalities and related constraints, to respond to end-users’ requirements and efficiently reuse the qualified solutions. Finally, we provided an implementation with an industrial use case to demonstrate the effectiveness of this approach. Concepts presented in this research work have been implemented as open-source prototypes based on Node JS and Java platforms. These prototypes cover the entire exploitation process that leads to the targeted ready-to-use business application.