Requirements for Domain-Specific Language in Enterprise Architecture-based SDGs Orchestration

— Coherence is a crucial issue in orchestrating Sustainable Development Goals (SDGs) at the society level. The various parties involved with different language standards further increase the complexity of communication. Enterprise Architecture (EA), which emphasizes consistency and coherence as the pillars of its concept, can be used to address coherence issues in the SDGs orchestration. This study aims to build a Requirements Framework for developing an architecture description language as a domain-specific language used for EA-based SDGs orchestration. To clarify the purpose of the research, a motivating scenario was built in the form of the SDGs Participation Platform (SDGs-PP). SDGs-PP becomes the context in which EA-based SDGs orchestration involves society-level actors (orchestrators) and enterprise-level actors (enterprise architects). This Requirement Framework is built using design science methodology as a part of ongoing research. The requirements consisting of context, concept, and collaboration domains and nine action requirements (elicit, separate, connect, classify, manifest, map, arrange, separate, and set up) were successfully formulated. The Context domain was developed from the ISO/IEC/IEEE 42010 standard. The Concept domain focuses on elaborating the SDGs means of implementation and the business ecosystem concept. The Collaboration domain discusses the separation in the model canvas between the enterprise and society domains. Apart from being used as a requirement framework for the meta-model development of an architecture description language, the results of this study can also be used further as a research framework in the domain of EA-based SDGs orchestration.


I. INTRODUCTION
Enterprise architecture (EA), which emphasizes coherence and consistency as the main pillars of its concept, can be used in the domain of sustainable development goals (SDGs).Research on EA and SDGs domains can be grouped into two types.First, research that uses EA as an instrument in achieving sustainability (EA as a means for sustainability) [1], [2].Second is research that focuses on incorporating sustainability into EA [3].For the second type, some researchers argue that incorporating sustainability into EA is not yet explicit and comprehensive [3].Both types of research depart from an internal-enterprise perspective on how the EA concept helps enterprises achieve various SDGs targets, whether mandatory or voluntary.
The SDGs are a society-level issue.Achieving the SDGs requires collective action by the government, the private sector, and the society with a multi-stakeholder, multisectoral (horizontal integration), multi-level (vertical integration) approach to the localization of strategies [4], [5], as well as orchestration governance modes [6]- [8].Therefore, a research initiative with a more comprehensive perspective is needed, not limited to a corporation-level perspective (internal enterprise) but encompasses the society-level perspective.
Research related to SDGs orchestration predominantly focuses on finding various prerequisite conditions, resources, and capabilities needed [9], [10].Relevant to orchestration needs, Villareal [11] emphasizes the importance of explicit concerns, shared understanding, concept relations, and causality to assist in clarifying objectives, setting milestones, indicators, policy identification, action plans, implementation, and monitoring processes.One of the challenges in orchestration is the issue of coherence.The exchange of information and cooperation on technical issues, combined with the readiness to consider various management concerns of other institutions, will be an appropriate means to achieve coherence [9].
To overcome coherence, the EA concept uses an architectural description language [12].This language is used as a communication tool for stakeholders to convey various concerns according to their respective perspectives.Therefore, the architectural description language can be used for SDGs orchestration at the society level.This idea is based on the fact that the society in which an enterprise exists can also be seen as an "enterprise" dependent on defined boundaries [13], which can have a certain degree of architectural substance.
This study aims to find the requirements needed to develop a domain-specific language based on architectural description language in EA-based SDGs orchestration.This domainspecific language bridges the communication between community-level actors (e.g., orchestrators) and enterpriselevel actors (e.g., corporate architects)

II. MATERIAL AND METHOD
This section will explain the main concepts, the way of thinking, motivating scenarios, and the methods used in obtaining the initial requirements framework.

A. SDGs Orchestration and Enterprise Architecture
Achieving the SDGs requires collective action by the government, the private sector, and the society with a multistakeholder, multi-sectoral (horizontal integration), multilevel (vertical integration) approach to the localization of strategies [4], [5], as well as orchestration governance modes [6], [7].
Orchestration is a soft and indirect mode of governance in the form of interaction between the first set of actors (called the orchestrator) acting through the second set of actors (called intermediaries) to manage the third set of actors (called the target) to align with the interests or goals of the orchestrator [6], [7].Orchestration is considered appropriate to be used as a governance mode for achieving the SDGs because it involves various parties across levels and across sectors with various unique interests with their respective autonomy.
In this paper, EA is defined as a set of fundamental, coherent, and consistent concepts, principles, and properties that guide the design process covering the business, organizational, information systems, and technology infrastructure aspects of the enterprise within its environment, along with the management principles in the realization, evolution and life cycle of the enterprise.
Research and articles linking the SDGs with Enterprise Architecture (EA), are generally divided into two types.The first is research that places EA as an instrument in achieving sustainability (EA as a means for sustainability) [1], [2].The second type is research that incorporates sustainability into EA [3].
These studies lack concern about the enterprise's external (society) perspective as the eco-systemic view [14], which is the main perspective in addressing the issue of sustainability.Another thing that was not found in previous research is the incorporation of sustainability into the level of the architecture description language or Enterprise Architecture Modeling Language (EAML), which bridges the perspectives of the orchestrator and the enterprise architect.Common understanding through common language is very important in addressing sustainability issues.

B. Architecture-Thinking Based Collaborative Action
Architecture thinking and collaborative action are needed to solve complex problems such as SDGs orchestration [15].This collaborative action requires consolidating and integrating information related to various resources and capabilities of actors that can be empowered in the SDGs orchestration.
The enterprise architecture approach allows all stakeholders to have the same conceptual foundation and understanding in managing complex problems coherently [16].Through the architecture description language, the concerns of each stakeholder are made explicit so that the orchestrator can consider the concerns of the enterprise level in managing the SDGs program and vice versa.The enterprise architect can also consider the orchestrator's concerns when developing the architecture.Even in the future, the orchestrator and the enterprise architect can jointly design and execute collaborative actions that are beneficial for all.This architecture description language is expected to be the foundation for improving the quality of the SDGs orchestration, which was originally a consolidation based on regulatory alignment, results reports, and lesson-learned reports on the achievement of SDGs at the enterprise level to consolidation based on the utilization of resources and capabilities of the enterprise to be proactively empowered in the SDGs program.

C. Motivating Scenario: SDGs Orchestration Using SDGs Participation Platform (SDGs-PP)
To clarify the proposed concept, the following will describe a motivating scenario for the SDGs orchestration in an imaginary city Z using the SDGs Participation Platform (SDGs-PP).SDGs-PP (Fig. 1) involves various entities, including government, private sector, education, NGOs, and other elements.The function of this platform is not only to share information or knowledge but also to function as a platform that orchestrates the collaborative actions of all parties in achieving the SDGs at the society level.This paper focuses on the architecture description language as an artifact used in the interaction between the orchestrator and the enterprise architect.Both actors already understand and agree on which architecture description language to use.This language is a domain-specific language that accommodates the design needs of society-level SDGs and enterprise-level EAs.
As an illustration, the orchestrator can use this architecture description language to publish artifacts as model representations of various SDGs programs or constructs.The enterprise architect can then use these artifacts in developing the EA design.Through this artifact, enterprise architects can incorporate the SDGs construct from high-level design to manifest in all elements of enterprise architecture.
Collaboration using an architecture description language was chosen based on the following considerations:  EA is an important element for the enterprise.EA development projects are expensive.EA development is an enterprise priority and is supported by the best resources.With this assumption, the output of EA artifacts must be of the best quality. The EA artifact's content describes the enterprise's current state and future direction while providing an overview of the stages or steps in achieving that direction.Thus, various enterprise resources and capabilities can be captured in the frame of current and future potential. Concerns related to SDGs are very important to be anticipated in the high-level design of EA development.This makes it possible for the SDGs to manifest in various enterprise elements.This is important because, in addition to supporting the achievement of the SDGs at the society level, the manifestation of the SDGs by enterprises also ensures the sustainability of the enterprise itself. Because it is already included in EA development, the enterprise does not need to allocate separate planning activities if you want to contribute to the achievement of the SDGs.Enterprises can focus on converting them into real action and linking them to SDGs programs at the society level. At the orchestrator level, knowledge related to SDGs has been documented.Nevertheless, there is still a need for a mechanism to translate it into a familiar construct, especially for enterprise architects, thereby increasing the opportunities for enterprise involvement.The uniformity of language in this artifact also makes it easier for the orchestrator to be more complete in mapping and extracting enterprise resources and capabilities. The development of EA automation research [17] has made it possible for machine-aided management of SDGs artifacts.Automation makes extracting data easier and processing it into actionable information and knowledge.This automation process can apply artificial intelligence [18] This paper focuses on exploring the various requirements for realizing an architectural description language (domainspecific language) that will be used in the SDGs orchestration according to motivating scenarios.

D. Design Science Research Methodology
This paper is part of an ongoing research aimed at producing information technology artifacts in the form of domain-specific languages for the SDGs orchestration.Design Science Research (DSR) [19] is used as a method with detailed steps following design science activities [20], which consists of explicating problems, defining requirements, designing and developing artifacts, demonstrating artifacts, and evaluating artifacts.This paper elaborates explicitly on the stages of the explicate problem and defines requirements.Other stages in design science activities, such as designing and developing, demonstrating, and evaluating artifacts, are outside this paper's scope.

1) Explicate Problem:
Problem can be interpreted as a gap between the desired and current conditions.With this definition, problems are not only associated with threats but can also be associated with opportunities [20].In the context of this research, the desired condition is the implementation of SDGs-PP as described in the motivating scenario, emphasizing the interaction between two stakeholders, namely the enterprise architect (representing the enterprise) and the orchestrator (representing the government).
The SDGs-PP scenario will be successful if the enterprise architect and orchestrator have the same understanding.One way to build this understanding is through shared mental models that shape interactions and resource sharing practice.In the context of this research, this mental model is related to the discourse on achieving SDGs through SDGs-PP.This understanding is manifested in the use of the same modeling language so that orchestrators and enterprise architects can produce artifacts that correspond to their respective scope of work.
First, from the enterprise architect's point of view, it is hoped that they will be able to address the SDGs concern from the high-level EA design process and have gained access to various artifacts or constructs relevant to enterprise involvement in SDGs-PP.Enterprise architects are fully aware that enterprises (besides being required to achieve profit) have the responsibility and potential to be actively involved in the SDGs program at the societal level.
All resources and capabilities owned by the enterprise to run its core business, with certain mechanisms, can also be converted (to be contributed) as resources and capabilities for the achievement of the SDGs.This awareness makes enterprise architects design EAs that go beyond their core business.Enterprise architects can give a certain status to the resources and capabilities of the enterprise, whether they will be contributed directly to the SDGs program or left to the orchestrator to determine alternative empowerment.
EA artifacts are submitted to the SDGs-PP.These artifacts follow the agreed format and modeling language so that the EA artifacts produced by the enterprise can conform to the SDGs-PP.The platform then extracts enterprise resource and capability information through these artifacts.The orchestrator will then analyze the extraction results to be considered in making decisions regarding the SDGs achievement program.
Second, from the orchestrator's point of view, the compiled program is converted into various forms of artifacts to be communicated to all related parties.Communication built through SDGs-PP is actionable communication.Program conversions include plugins or EA modeling language libraries so that enterprise architects can directly use them in their modeling activities.When there are changes related to the SDGs program, the orchestrator updates the master plugin or library and then redistributes it with versioning to various parties involved.
The orchestrator then processes the information resulting from the extraction of EA artifacts which is submitted to the SDGs-PP by the enterprise architect.The results of this extraction are mapped against the need for resources and capabilities to implement the SDGs program.From this mapping, the orchestrator can see the potential that can be empowered and also see which points are still lacking.This map then becomes the material for making a more detailed action plan for the SDGs program.In the process, the orchestrator also conducts a feasibility study of the potential of these resources and capabilities and ensures that this involvement brings benefits to all parties.
Nowadays, communication between enterprises and the government goes conventionally.The government socializes the SDGs program along with various separate documents.Understanding and aligning the document with EA development activities requires a separate effort.Enterprise contributions are often optional (tends to be voluntary) in certain sectors that are limited by its core business.This reality raises problems including:  SDGs engagement is very dependent and limited on the capabilities and knowledge of stakeholders or in this case the enterprise architect.The EA concept does not yet can act as an explicit and authoritative guide in accommodating the SDGs. Enterprise contribution in achieving the SDGs is not optimal because the enterprise (in this case the enterprise architect) has difficulty aligning the profit achievement strategy (which is contained in the enterprise architecture) with the achievement of the SDGs at the society level. The government (as an orchestrator) is not optimal in accessing the potential resources and capabilities of the enterprise. Cumulatively, the above problems can cause the achievement of the SDGs at the society level to be less than optimal.
2) Define Requirement: Architecture description language can be one of the answers to this problem.A language that can be used for enterprise design as well as design in the SDGs domain.The language is used as a design tool for orchestrators and enterprise architects.
This architecture description language is expected to be able to:  Accommodating enterprise architects in constructing enterprise architecture models that address the SDGs. Accommodating the orchestrator in constructing the SDGs program design  Become a bridge between the potential of the enterprise and the various needs of the SDGs achievement program at the society level.Further elaboration of the requirements framework for building the architecture description language will be described in the results section.This requirements framework is positioned as a conceptual framework that must be met as a guide in the development of further meta-models.

III. RESULT AND DISCUSSION
In general, the resulting requirements framework covers the domains of context, concepts, and collaboration (Fig. 2).These domains covers some notions that need to be considered in building an architecture description language.The result is an initial exploration, some of which are expressed using the UML notation version 2.5.

A. Context
Enterprise architects and orchestrators need to have a common context when interacting using an architecture description language.This context was developed from the ISO/IEC/IEEE 42010, a standard on the description of system and software architectures (Fig. 3).
This Common context is expected to provide a common understanding of the various knowledge, terminology and applicable standards.The context referred to here is the SDGs orchestration at the society level through the implementation of SDGs-PP in City Z as explained previously in the motivating scenario.An overview of the context can be seen in Fig. 4. Some explanation of the image provided below:  Enterprise (as a system) is situated during society (ZCitySociety) which is also a system. As a system, both Enterprise and ZCitySociety have certain concerns.In this context, enterprise concerns are goals related to core business (EnterpriseBusiness Goals) and enterprise goals related to SDGs (EnterpriseSDGs).ZCitySociety concerns are also defined related to SDGs (ZCitySocietySDGs).Orchestration ensures how concerns at these different levels (enterprise with the society) can be achieved, support and harmonize with each other. The SDGs' goals at the societal level (ZCitySocietySDGs) are achieved through the preparation and implementation of various programs (ZCitySDGsProgramme).These various programs are manifested into a participation platform (SDGs-ParticipationPlatform) that can be accessed by various stakeholders, including enterprises.On this platform, orchestrators and enterprise architects interact using media in the form of architecture description language artifacts. As a system, an enterprise has an architecture form (Enterprise Architecture) which is expressed in a certain architecture description format (EnterpriseArchitectureDesc)  As a system, the SDGs-Participation Platform has an architecture form (SDGs-PPArchitecture) which is expressed in a particular architecture description format (SDGs-PPArchitectureDesc) Based on the explanation of the context, it can be concluded that the relevant needs for the development of an architecture description language are:  The identification of enterprise goals related to the SDGs (EnterpriseSDGs).There is a need for a mechanism that separates the business enterprise Goals from the SDG-related Goals at the enterprise level. The identification of SDGs goals at the society level (ZCitySocietySDGs).A mechanism is needed to link the SDGs' goals at the enterprise level with the SDGs' goals at the society level.The achievement of the SDGs at these two levels must be mutually aligned and support each other, including its relation to enterprise business goals. It is necessary to create a mechanism in the language description of the architecture to be built so that it can be a medium between EnterpriseArchitecture and EnterpriseArchitectureDesc to be aligned with SDGs-PPArchitecture and SDGs-PPArchitectureDesc.

B. Concept
The concept domain discusses the notion which is the main ingredient in the development of an architecture description language.Due to the limited number of pages, this chapter will only discuss two things, namely the concept of SDGs with a focus on means of implementation (MOI) [21], and the concept of business ecosystems as a typology of systems relevant to the implementation of SDGs-PP as in the motivating scenario.

1) SDGs Means of Implementation (MOI):
The MOI is explored from various experiences and lessons learned in achieving the millennium development goals (MDGs) and sustainable development goals (SDGs) from the perspective of the country to the corporate/organizational level.Focus on MOI is expected to produce an actionable construct that directly impacts the achievement of the SDGs.
In our ongoing research, semantic analysis of the literature related to MOI generates various relevant keywords, some of the results are shown in Table 1.These keywords are positioned as construct candidates that need to be analyzed further to be manifested (as constructs) in the architecture description language.Table 1 also identifies the essential functions of digital government, active broker, driver, coordinator, backbone organization and endorser that are relevant in achieving the SDGs.A brief explanation of these functions will be presented below.
From a society perspective, achieving the SDGs requires a relevant government function, namely digital governance.Digitization of government (especially for the achievement of SDGs) is believed to be the answer to the complexity of the SDGs issue [22].In addition, an active-broker [23] is needed as a party that connects various potential resources in the society to optimize these potentials together.Endorser and driver [23] functions are needed to maximize socialization, education, motivation and mobilization.
Next, which is no less important is the function of the coordinator who is responsible for organizing all parties involved and it is preferably at the society level that a special organization is formed as a backbone not just an ad-hoc committee [24]) that focuses on ensuring the implementation of the SDGs agenda properly.
All the functions mentioned above can be played by various entities that are members of society (including enterprises), even though each of these entities already has or carries out functions in accordance with its core business.Analysis of Table 1 produces conclusions in the form of relevant requirements for the development of an architecture description language consisting of:  The need for separation between the relevant construct's candidate manifested in the architecture description language and those manifested in SDGs-PP governance.A conceptual basis and an appropriate classification method are needed to perform this separation.Backbone Organization

Digital Government
 A mechanism is needed to represent the essential functions in achieving the SDGs (digital government, active-broker, coordinator, endorser, driver, organizational backbone) into an architecture description language.With this requirement, the architecture description language that is built should be able to accommodate the internal perspective of the enterprise as well as the perspective of the enterprise's role in its environment (external perspective).
2) Business Ecosystem: Business Ecosystem is a typology of systems that has the potential to be further developed (with some adjustments) to become a means of achieving society progress.This kind of progress requires enterprises (corporations) to cooperate with the government, NGOs, competitors, consumers and the wider society to build ecosystem of shared value [25], which is SDGs value related.Therefore, the business ecosystem is considered appropriate to be used as an approach to describe the implementation of SDGs-PP scenario.
Business Ecosystem is defined as a collection of suppliers, customers, associations and other stakeholders who coordinate all activities to produce goods or services for customers where in fact the customer is also a member of that ecosystem [26].Coopetition takes place in this business ecosystem.
Coopetition is an interaction between participants in a business ecosystem who compete and collaborate to create value [26].Various objects of value flow in the business ecosystem in the form of services, goods, money, or experience [26].Table 2 shows the main elements of the business ecosystem.One of the challenges in the business ecosystem is to have a common language in communication which is expressed by means of the same elements that have similar semantics (definition of concepts), similar structures (relationships between concepts) and syntactic similarities (modeling language).Another challenge in the business ecosystem is related to resource management, which consists of the acquisition (connection), configuration, and orchestration stages.
As described in the motivating scenario, the SDGs orchestration requires the active participation of multistakeholders with their various interests.This situation (some parts of it) is represented in the business ecosystem.In the business ecosystem, no one has a role as central governance; each member of the ecosystem has a business goal, can legally protect their own interests, and has the freedom to carry out other activities.Some principles must be applied for the successful implementation of a business ecosystem.These principles are [26] fairness, reciprocity, positive income, transparency, access rights, agreement to the rules of the game, mutual trust, privacy and security.These principles can be derived to generate candidate requirements for either an architecture description language or SDGs-PP governance.A brief explanation of the principles and candidate requirements derived from these principles can be seen in Table 5.
To meet the needs of the motivating scenario, the business ecosystem concept needs to be adjusted so that it can accommodate the implementation of SDGs-PP.This adjustment needs to be made because of fundamental differences related to the initial objectives of business ecosystem development which cannot be separated from the dominance of profit orientation (economic motives), while the achievement of these SDGs requires motives that go beyond mere economic interests.Business ecosystem participants interact with the orientation of increasing their business revenue and profit, while participants in the SDGs-PP interact with the main orientation of achieving SDGs at the society level as well as ensuring that their business continues to earn revenue and profit.One form of adjustment is the new setting of various main roles in the SDGs-PP.New definite roles are proposed consist of orchestrator, consolidator, auditor and contributor.These definite roles manifest the function of digital government, active broker, driver, coordinator, backbone organization and endorser as mentioned in Table 1.The explanation about this definite role can be seen in Table 3.
From the business ecosystem section, the conclusions regarding the relevant requirements for the development of an architecture description language are:  The need for mapping between the existing roles in the business ecosystem, the essential functions in SDGs MOI, and new-setting roles in the SDGs-PP.
Comparison of these roles can be seen in Table 4.
 Once these roles are mapped, a mechanism is needed to manifest these roles into architecture description language constructs.
 Based on the analysis of

C. Collaboration
The collaboration section discusses how to build a collaboration mechanism (way of working and modeling) between actors.In the context of this research (according to the motivating scenario), orchestrators and enterprise architects are actors who will collaborate on the SDGs-PP by using an architecture description language.Each of these actors has a different base domain.A good EA modeling language can model the general structure of each domain, show each element and its relationships, and be able to model the relationships between these domains [27].This architecture description language needs to accommodate base-domain differences.Each participant gets a fair distribution of costs, benefits and risks comprehensive information is available regarding the quantitative value of the costs, benefits and risks that take place within the business ecosystem network Fairness also meaning that participants will receive a responsibility according to their abilities and participants will benefit according to their contribution The openness of each participant in reporting their resources and capabilities.The availability of resources and capabilities of participants is dynamic, so it is necessary to prepare an update mechanism in real time Reciprocity Each participant must get feedback for every action they take in the business ecosystem.
Availability of a two-way interaction mechanism or a mechanism that ensures involved participants get feedback

Privacy and Security
Each participant is respected for their privacy and security Mechanisms for protecting the privacy and security of participants The orchestrator and the enterprise architect construct the model on the same canvas to achieve the commonalities.The modeling canvas is divided into the enterprise and society domains or the SDGs domains to accommodate these needs.The society domain is the domain for the orchestrator, while the enterprise domain is the domain for the enterprise architect.
Furthermore, the enterprise domain was separated into the business mindset sub-domain and the SDGs mindset subdomain.The business mindset sub-domain is a domain that has been a natural characteristic of enterprises, the profitseeking mindset (financial aspect).The SDGs mindset subdomain is a new domain that was introduced in the context of this research.The SDGs mindset is a place where constructs related to the contribution and involvement of enterprises in the SDGs program are expressed.An illustration of this domain separation requirement can be seen in Fig. 5.
This separation in the enterprise domain does not change the existing base domains (business, application, and technology).The purpose of this separation is to complete the enterprise concept so that it can accommodate the needs of EA-based SDGs orchestration.The next things that need to be set are:  Construct ownership.Which constructs belong only to certain domains (sub-domains), and which constructs can exist in all domains.
 Cross-domain construct relationships.What kind of relationships are allowed for cross-domain constructs. Limits of Model Construction.The extent to which enterprise architects and orchestrators can construct models outside of their domain. Limits of Authority.The extent to which enterprise architects and orchestrators can extract information from collaborated-models developed in SDGs-PP.

D. Requirement Revisited
The requirements explained above are built on three domains: context, concept, and collaboration.Context talks about where and in what situations the architecture description language is used, the concept talks about various main concepts as the ingredient for the development of the architecture description language, while collaboration talks about how the architecture description language is used (the way of working and the way of modeling).Each of these domains is also a concept that will be directly or indirectly manifested in the architecture description language.An illustration of the requirements (as a framework) can be seen in Fig. 6.This requirement contributes in two ways.The first is a framework in elaborating the need for the meta-model development of an architecture description language.The second is this requirement can be further developed as a research framework within the domain of EA-based SDGs orchestration.

IV. CONCLUSION
This study presents a framework of requirements for the development of an architecture description language used in a specific domain of enterprise-architecture-based SDGs orchestration.This study proposed a requirement consisting of context, concept, and collaboration built on a motivating scenario called SDGs-PP.This study uses the ISO/IEC/IEEE 42010 standard in developing the context.This standard is intended to guide enterprise-and society-level architecture development.This standard will make efforts to align the two levels easier.
In the concept domain, SDGs are discussed by emphasizing the concept of SDGs means of implementation.The use of SDGs MOI is expected to produce a more actionable construct.SDG-related concepts can also be elaborated based on report standards related to SDGs, such as the GRI standard [28].MOI-based concepts can be combined with SDGs report-based concepts (e.g., GRI) for further research.
In the concept domain, a business ecosystem typology is also introduced.This typology is considered appropriate for the needs of implementing SDGs-PP in the real world.Further research can also be elaborated on the business ecosystem architecture built based on enterprise architecture theory [26], [29].This elaboration (from EA point of view) is to get a more complete element regarding the needs of an eco-systemic perspective as a digital ecosystem [30].
The collaboration domain focuses on the way of working and modeling.The architecture description language should be developed based on existing architecture description languages such as Archimate and DEMO [31].For further research, extracting and classifying constructs candidates can be carried out using a more empirical method, whether through questionnaires or computed using natural language processing.Future research can also focus on evaluation aspects such as feasibility analysis of the SDGs-PP concept or architecture description language meta-model evaluation.

Fig. 3
Fig. 3 Context of Architecture Description According to ISO/IEC/IEEE 42010 Standard

Fig. 4
Fig. 4 Context for Orchestrator and Enterprise Architect Interaction

Table 5
, a mechanism, property, or attribute is needed to accommodate the recording and calculation of various values such as the value of costs, benefits and risks  Based on the analysis of table 5, a mechanism, property or attribute is needed to accommodate the setting of information access rights

TABLE V PRINCIPLES
OF BUSINESS ECOSYSTEM AND REQUIREMENT CANDIDATES FOR SDGS-PP