Designing an Enterprise Architecture Using TOGAF Framework

Designing an Enterprise Architecture Using TOGAF Framework

Abstract

Healthcare institutions are among the most diverse public sectors that face difficulties in structuring and coordinating their IT resources. Systems in the hospital information system typically function separately and heterogeneously in delivering clinical data. The lack of coordination and compliance with the business goal contributes to an improvement in the inability to enforce IT (Seebregts et al., 2017). The organizational design is regarded as a remedy to these issues, but no systematic advice to apply it to the hospital is accessible at the moment. Existing theoretical strategies have not tackled two main criteria of hospital information systems designs which are the capability to accommodate several divisions, and the full vision of the whole topology, from the Organization to infrastructure design (Hakim et al. (2019). The paper aims at identifying the best way to construct business architecture for hospital data by specifying the requirements of the design, evaluating current systems to satisfy the needs, and designing an effective enterprise using TOGAF framework. The case study supports work at King Fahd University Hospital, the most significant hospital in Khobar, Kingdom of Saudi Arabia.

Introduction

In everyday life, the production and use of information technology continue to grow exponentially. Consequently, corporations or businesses have various options to determine what IT design is to be used in their companies or organizations. In healthcare institutions, applied IT systems do not only meet with the institution’s requirements but also with laws and legislation on healthcare sector (Seebregts et al., 2017).). The approaches selected must be attentive to the nature and state of the enterprise and its resources as well as the ability to integrate data and the business structure. The reason has been that medical organizations continue to provide scattered data and processes in different fields that may trigger multiple complications, such as lost data or program, and cannot be applied in all fields. Healthcare institutions have to ensure that their existing resources can grow from the present to the expected circumstances. Therefore, business architecture is the best information management approach for healthcare organizations. Enterprise architecture is typically an engineering and management approach intended to improve organizational success. It encourages businesses to look at their infrastructure tools, knowledge processing, operating processes, and strategic advice in a comprehensive and interconnected manner. There are various enterprise architecture system frameworks currently available for organizations or businesses. However, TOGAF frameworks are perceived to be far superior to other frameworks based on Urbaczewski & Mrdalj (2006) analysis into five most commonly implemented corporate architecture frameworks.

The TOGAF is a significant enabler of client design. TOGAF consists of an architectural structure to define what is required to create, execute, and sustain the business architecture and a systematic and validated step-by-step approach called the Architecture Design Approach (ADM). TOGAF has benefits such as completion of systems, TOGAF ADM, ease in usage in materials, interconnection/layer integration, neutralize of the manufacturer, and adherence to business requirements (Cabrera et al., 2016). This paper focuses on the design for King Fahd University Hospital an enterprise architecture using the TOGAF Structure Methodology that involves the usage of the TOGAF Architecture development Model (ADM) in incorporating current and applied data and systems at the institution.

Theoretical Framework

Enterprise Architecture

Business Architecture is a development and strategy methodology aimed at improving corporate success and helping companies appreciate their computing capabilities, knowledge processes, market strategies, and strategic advice in a comprehensive and interconnected manner (Jallow et al., 2017)). In deciding the complexity and extent of the organizational design within an organization, the business model principle is helpful. Organizations can have several enterprises to build and manage the separate infrastructure of the enterprise.  Both organizations share numerous aspects in common, including structures, roles, and data sets. In many situations, a similar organizational structure provides more capacity for benefit. A shared framework provides the foundation for designing specific building blocks and solutions as well as a collaborative software archive to incorporate and re-use business models, plans, data, and knowledge (Seebregts et al., 2017). All enterprise Architecture aims at simplifying processes, both manual and computerized, in a universal dynamic environment to reacts to fluctuations that affirm business strategy execution.

CEOs now recognize that effective knowledge processing and usage, as well as digital innovation, are the main drivers for performance and the necessary resources for gaining competitive advantages. The organizational architecture meets this requirement by offering a structural platform in reaction to the ever-changing demands of the corporate community to grow and achieve new potential (Seebregts et al., 2017). The exponential growth of social networks, the Internet of Things and cloud infrastructure, for example, has dramatically expanded the company’s capacity to generate new business possibilities.

Therefore, a robust Enterprise Architecture helps businesses to align market change with continuing organizational efficiency, to attain changing corporate goals and strategic edge and facilitates specific business divisions to evolve securely (Seebregts et al., 2017). The business model allows a cohesive approach for the requirements of the enterprise to be addressed, enabling the client and beyond to create the best potential synergies. A successful organizational infrastructure will provide the client with valuable benefits.

Enterprise Architecture’s unique advantages include; better and more effective business transactions, more reliable automated systems and IT services, higher return on current assets, minimizes risk for future investments, and offer quicker, more affordable procurement (Seebregts et al., 2017).

Enterprise Architecture Frameworks

Many frameworks of business architecture currently exist and can be used according to their specifications by organizations or businesses. Open Group Architecture Framework (TOGAF), Zachman System, Federal Enterprise Architecture (FEA), and Gartner System are the four commonly employed frameworks in business architecture design (Urbaczewski & Mrdalj, 2006). The figure below illustrates the various enterprise architecture frameworks.

Table 1.0 Comparisons Of Enterprise Architecture Frameworks.

Obstacles to Enterprise Architecture

There has been a shortage of conventional model acquisition, implementation, and management software which has made it hard to retain details of the enterprise architecture until designed.

Furthermore, the distribution of knowledge is challenging.  Everyone wanted a copy of the modelling method inside the company through the basic terminology and accuracy of the language for company architecture are lacking. As a result quantification of ROI of effective enterprise architecture deployment has been complicated.

Enablers of Enterprise Architecture

Modern technologies have arrived in recent years to render the infrastructure of the business achievable. Business intranet and the web offer a source of communication for all employees of an institution. Additionally, an innovative cohort of enterprise architectural designing tools has emerged that embraces a broad spectrum of modelling notations, offers a versatile and modular base store able to store and combine models across all architectural fields, and provides diverse reporting and publishing facilities (Goethals, 2005).

TOGAF Framework

The Open Group is the main collaborator for organizations that desire to minimize their costs and threats in incorporating multi-supplier elucidations that combine within and outside the businesses. The Collaborative Alliance puts together multinational information technology vendors and manufacturers. It encourages them to collaborate, both to ensure that the technologies satisfy consumers ‘requirements and to promote the company-wide adoption of IT. The primary facilitator in this role is the TOGAF norm. Usually, a study or improvement of the organizational architecture begins plans for market transition requirements or drastic technology improvements. Significant people also recognize the growing areas required to accomplish different market goals. Such entities are typically named “the participants” in the transition. Identification and clarification of the demands raised by the affected parties, creation of ideas about the project demonstrate how issues and specifications are handled (Kotusev, 2018). Additionally, negotiations must be created to unify possibly varying interests of patients, stakeholders and employees position of the architect.

It is incredibly doubtful that both problems and requirements can be taken into consideration and addressed without the Business Architecture (Kotusev, 2019). A community-wide partnership builds the TOGAF specification. The TOGAF model results in a coherent market design that addresses stakeholders ‘interests incorporate standard practices and takes into consideration the current demands and potential benefits of the Organization (Kotusev, 2018). Enterprise design creation and management is a technologically challenging mechanism that is requiring multiple actors and decision-making mechanisms throughout the cycle. For requirements and de-risks for the design production phase, the TOGAF framework is of great importance.

The TOGAF model offers a system of standard practices to add value, enabling the company to create feasible and sustainable approaches that solve its business challenges and needs. It also provides method efficiency, TOGAF ADM, components reliability, layer integration/ interconnection, provider independence, and compliance with market requirements (Cabrera et al., 2016).

Literature Review

Enterprise architecture (EA) is an organization-wide framework, sector, information technology, and IT infrastructure creation and application of concepts, approaches, and models. The amount of studies performed in this area has been gradually growing. Nonetheless, the emphasis on work in this area needs to be centralized. Hakim et al. (2019) centred on the implementation and integration of market infrastructure in the management of IT resources with an emphasis on the transformation and creation of ERPs based on the cloud utilizing multi-tenant principles. Though, evaluation is conducted without explicit or specified samples and references for the application of enterprise architecture. Rurua, Eshuis & Razavian (2019) provided strategies that ensure company and IT strategic compatibility built with the TOGAF meta-model by incorporation of SAM components. Though the findings are already too general, and no case studies, more collection, and clarification of the objects are necessary to carry out experiments. Sajid & Ahsan (2014) analyzed the developing conceptual business infrastructure that can be used for the development of information technology within the organization. His Work meets just the Technologize Architecture level of the TOGAF system, not the period of implementation of the business architecture. There was also no study to check that the organization architecture approach developed may be used for many market fields than multi-branch hospitals. Research on business architecture structures that are more commonly utilized by companies and the qualities an organization requires to ensure that the company’s projects meet their requirements.

TOGAF Framework Continuums

Enterprise Continuum

Organization Continuum is a tool and theory to establish architecture by reusable building blocks. Enterprise Process TOGAF defines an ongoing, iterative cycle for designing architectures and solutions utilizing design components (ABBs) and solution components (SBBs). Apart is essentially a set of functions to satisfy market requirements. The basic standard of description defines a building framework for design. For instance, an architecture block is defined as a wired catalogue for accessing system design (Kotusev, 2019). In the ADM, ABBs are substituted by SBBs representing specific goods or particular design innovations (Cabrera et al., 2016).

The design and approach system is at the peak of the design spectrum. It advises and promotes the unique application infrastructure, lays the ability to utilize the solutions spectrum. The architecture is designed such that enterprise can set up the building blocks of the architecture at respective points and the solution building blocks that implement it. Ultimately, Continuum Solutions describes solutions to include business infrastructure and tailored solutions for the organization.

Architecture Continuum

The architecture framework describes the elements essential in designing enterprise architecture for the company. Ideally, firms start the architecture initiative with a Framework Architecture (Kotusev, 2019). They later expand upon this base utilizing standard systems architectures such as generic protection architecture or to industry-relevant architectures such as retail business architecture to achieve the architecture unique to the organization. It is evident how significant base design is utilized during the preliminary stage of ADM.

Introduced to the TRM and the Standardization Information Base (SIB), TOGAF offers a Framework Architecture to assist you to continue (Urbaczewski & Mrdalj, 2006). After the first iteration of TOGAF ADM, the Engineering Design and solution collection form part of the Base Infrastructure for the next stage.  The beginning point is Base Architecture consists of building blocks of design and related specifications that underpin the whole programming system. Firms may use the Framework Design pre-submitted by TOGAF, which includes the Technological Reference Model and the Standards Knowledge Base (Kotusev, 2019). TOGAF ADM is adopted as a measure to meet a single organization from the base architecture.

Solutions Continuum

The Spectrum solutions describe the technologies that the design implements. In accordance with the Architecture Spectrum, you continue with the Base Architecture’s standardized set of goods and services that incorporate Frameworks and Market applications to create the business-specific solutions and technologies (Masuda & Viswanathan, 2019).

Devices and services-Items that you may buy contain hardware and apps. Training, assessments, and professional assistance are provided in the programs. Services allow you to leverage your expenditure on goods and enable others to work in a small period of time.

System Solutions-A System Solution is a Popular Application Architecture application consisting of a range of products and facilities which can be marketed or accredited.

Solutions for manufacturing– An engineering approach is the implementation of a design for the market. Applications may be a similar CRM program or a drug ordering method on the Web (Kotusev, 2019).

TOGAF Architecture Development Method (ADM)

The epicentre of TOGAF is the TOGAF ADM.  TOGAF ADM provides iterative and validated methods for design creation (Hadaya, Leshob & de Verteuil, 2019). Requirement control is at the core of ADM. The Organization, information technology, and technical structures often suit specifications and associated company priorities, and the arrows demonstrate that the ADM stage proceeds with a certain phase.

Stage A: Architecture Vision

The organizations in stage A resume research began in the initial stage and attached supplementary data to the study. The IT department reviews the structures the company currently has in place, and it examines how they may be replicated, such as the recorded infrastructure systems and the associated repositories (Hadaya, Leshob & de Verteuil, 2019). It is also necessary to ensure that the program is unique and more advanced than that of the other organizations.

Inputs and outputs are accessible at each TOGAF process. The primary input for stage A is a Proposal for Architecture Work. The documentation is a substantial output during the stage and the declaration of Architecture Work that specifies the research to be done and becomes an element in all subsequent ADM phases (Hermawan & Sumitra, 2019)

Diagram 1.0 Architecture Development Method Steps.

TOGAF points forth the kind of details this design question might entail. It may involve the company’s Core mission and how the design project applies to the Organization, the endorsed overall management objectives, organizational goals, limitations on the Organization for this function, the description of the current operating structure, and its name.

Stage B: Business Architecture

Step B builds and retains organizational infrastructure. The ‘AS-IS’ (underlying) and the ‘to-be’ enterprise architectures are described in Stage B.  The “AS IS” architecture is defined as required at the beginning of this stage to affirm the enterprise architecture goal (Jallow et al., 2017). TOGAF does not recommend wasting time on superfluous design specifics unless it forms the foundation of the “TO BE” software.

IT team then continue designing the company model ‘TO BE’ in doing three tasks namely;

• Formulate the points of view on which the enterprise design is being built such as processes, administration, finance, marketing or financial services to illustrate how the modelling project approaches to staff and patients concerns (Masuda & Viswanathan, 2019).
• Choose from Design Spectrum suitable business design services (such as pre-built templates)
• Determining which notations, processes, and methods can use to form the organizational architecture. Additionally, ‘TO BE’ patterns are created for a growing point of view (Kotusev, 2019).

Stage C – Information Systems Architectures

Stage C was recently implemented in TOGAF 8. Throughout the past, TOGAF focused on the market model established throughout stage B, which was the particular subject of TOGAF 7 and prior TOGAF models (Puspitasari, 2019). In Stage C, the emphasis is on the architecture of the information system, which comprises the architecture of the data and the software. TOGAF outlines comprehensive measures for data and applications designs (Moghaddam et al., 2017).

In input architecture, managers define the most critical styles and data sources required to help the enterprise. They do not build the architecture in an actual network at this point since the templates are different from the ultimate system (Pasaribu et al., 2019). Managers are advised to use conventional data modelling approaches like role modelling for objects, philosophical data modeling, and logical data modeling to in developing the system architecture. It is a big undertaking, and, as suggested, the TOGAF ADM contains comprehensive details regarding data entities ‘roles in the company environment, showing which of the essential tasks are carried out (Pasaribu et al., 2019). It is essential to create blocks of software that will be included in the data system during this phase. IT managers must generate the System Architecture Report, which contains the technical, functional, and practical system structures, application object and business feature matrices, as well as specifications for system standardization.

Stage D: Technology Architecture

IT administrators build software infrastructure after enterprise infrastructure are completed. Stage D is a mini-framework of its own and explains how to build the Organization’s infrastructure frameworks (Pasaribu et al., 2019). The built technology architecture is essential because it forms the foundation for all the functions of the Organization.

Stage E: Opportunities and Solutions

Stage E explores ideas and incentives. Models for current and future systems are reviewed by administrators. Large research packages or tasks to be performed for the execution of the future architecture are defined and categorized as new growth, acquisition potential, or the re-use of established schemes (Puspitasari, 2019). As part of this initiative, the discrepancy study carried out in stage D is checked. The outcome of the process is a high-level action schedule and overall integration approach and a performance review framework that provides a comprehensive target list of programs. Notably, TOGAF meaning does not apply to the typical “Effect Appraisal” “what would it imply if I alter XYZ?” But “what is the effect on the working capital available to execute this goal architecture?” In other terms, the work system to enforce the architecture is specified.

Stage F: Migration Planning

The target sequence of the tasks to pursue through migration preparation is more specifically discussed, taking into consideration the various real-world consequences and challenges, including value, gained short-term payouts, logistical obstacles, and organizational behavior consequences (Puspitasari, 2019). Managers perform a cost-benefit analysis and risk analysis at this level. A comprehensive effect analysis report consisting of a thorough implementation and relocation strategy is the product of this process.

Stage G: Implementation Governance

Throughout Stage G, the designs are carried out and operated as a structured operating system, which uses the developed design as an interconnected collection of components that correspond to the design. This stage performance is an architectural contract, and the framework is applied according to the design. The design department is regularly involved in (and will lead) main implementation initiatives in this process to maintain consistency with the approach introduced (Puspitasari, 2019).

Stage H: Architecture Change Management

The ADM describes drivers for transition and how institutions handle the transition from basic repairs to system redesigns (including technology-based drivers and company drivers). In this continuing step, the ADM delivers policy and advice. An Explorer diagram is a valuable resource offered by Application Architect. Graphic representation allows firms to visually examine the cause/impact relationships between software objects in their registry, which helps them to address questions such as the business processes that might be impacted when they upgrade the operating system on a specified server (Rurua, Eshuis & Razavian, 2019). Each item of the business sort can be dragged and dropped onto the map (from business processes to servers) and recorded on the diagram can then be dragged to establish a connection between each artifact.

Core- Requirements Management

The Maintenance of specifications is the core sphere of the TOGAF system and is related to all ADM levels. This is because requirements that are continually changing and optimized are defined, processed, and delivered in and out of different ADM processes. This is reflected in the fact that they have always been modified and have been improved (Rurua, Eshuis & Razavian, 2019). The design and management of requirements are other courses of study, and TOGAF provides an outline on how to aspire and meet the requirements in the areas of architecture that satisfy them.

The use of case diagrams is a timely strategy for designing market scenario specifications. Technological approaches for requirement management are provided through the modeling tools and requirement management tools along with their related repositories.

Iteration Cycle

This presentation approach is intended to explain the fundamentals of architectural creation and the life cycle of architecture rapidly. The two main principles that are used to address the difficulty of designing and maintaining a company model are its iteration and stages.  The ADM follows a variety of definitions, which are classified as iterations (Puspitasari, 2019). The first definition of iteration outlines the method of defining both the detailed landscape design in many ADM processes dependent on different programs relevant to the design job program.

Secondly, the iteration explains the interconnected phase of creating an architecture in which the mentioned events communicate with an interconnected architecture across different ADM cycles. This latter iteration is defined sequentially to define operation and performance concisely. Fourth, iteration illustrates the change management method in the technical capability of the company (Masuda et al., 2017).

When taking into account the use of iteration cycles, it is essential to consider when placing appropriate checkpoints in the process. Where stakeholder engagement is expected to be high, it can be sensitive to carry out very often, but informally, checks to make sure that the process goes in the right direction. If stakeholders participate less jointly, control points can be less often, but formal.

There are specific controls when each iteration process is finished or at the conclusion of many iteration cycles. A single design definition stage is achieved in each phase of the ADM process. For the facilitation of more comprehensive urban construction programs, the ADM strategy uses Step F (Migration Planning). This kind of iteration stresses the need for higher architecture to direct and restrict the overall architecture (Sajid & Ahsan, 2014). This often confirms that many ADM variations are used to create the whole Architecture Landscape.

Cycle Processes

Architecture Capability Iteration

Iterations promote the development and evolution of the necessary capability of architecture Initial mobilization by specifying or adapting architectural method, values, nature, vision, and governance of architectural operation to a particular intent or form of architectonic interaction (Masuda et al., 2017).

Iteration 1– Identify the layout of the Baseline.

The implementation comprises the ADM stages of Business Architecture, Data Management, and Software Architecture, which rely on the standard concept. Emphasis is also put on prospects, approaches, and implementation strategies for transition and testing.

Iteration 2– Describes the design of goals and shortcomings.

Each analysis provides a description of the ADM market architecture, information management architecture, and infrastructure organizational processes to identify the goal and examine baseline differences. Check feasibility frequently covers incentives, approaches, and relocation plans.

Iteration n– Actually, the design creation iterations are aimed at optimizing the task to achieve a positive, realistic, and viable result.

Architecture Development Iteration

Iterations permit the development of software material by or around the incorporation processes of industry, information management, and infrastructure design. These iterations allow an overall evaluation of the software. Usually, analysis by partners of this form of replication is more comprehensive (Masuda et al., 2017). The extensions in the Opportunities & Strategies and Migration Planning stage ensure that the operating ability of the system is regarded as the design is completed.

Iteration 1– Set the Architecture Goal.

Each implementation requires a ride through the ADM processes of enterprise infrastructure and architectural information systems, with an emphasis on identifying the goal. Focused on transition and evaluating effectiveness are often taken on prospects, approaches, and transformation schemes.

Iteration 2– Establish the design and holes in the baseline.

This iteration comprises of the ADM phases of market architecture, the architecture of information management, and development architecture, which focuses on establishing the benchmark and review of the discrepancies toward the goal (Masuda & Viswanathan, 2019). The assessment of feasibility shall also provide incentives, approaches, and relocation plans. Define the Baseline Architecture and gaps.

Iteration n– specification of the context aims and gaps.

Iterations from the following design creation work at improving and perfecting the purpose of producing a successful, realistic, and sustainable result.

Transition Planning Iteration

Iterations endorse the development of a given architecture systematic change roadmaps.

Iteration 1– Describes and decides on a variety of changes, compatible with a transitional framework for transformation. The first round of the transformation preparation aims at obtaining exposure to the array of alternative options at the ADM process Challenges & Options (Masuda & Viswanathan, 2019).

Iteration n– Agree with the model of transformation, to optimize the potential for change found. The strategic strategy is more streamlined and aims at taking challenges back to the refining stage of the possibilities & approaches.

Architecture Governance Iteration

Iterations help transition governance to a given Goal System.

Iteration 1– Mobilize governance of infrastructure and management methods. The first iteration on architecture governance lays out a framework for change governance and also introduces appropriate people, processes, and technologies for controlled access and alteration of established architecture.

Iteration n– Execute administration in design and the management of transition after implementations of the Architecture Governance Stage.  Emphasis is on frequent analysis and implementation with reform measures (Masuda & Viswanathan, 2019). The effects of the proposal for improvements will cause the modification of a new process, for example, feeding supports a new preliminary step need for the enhancement of capacities for architecture or a new architecture need in the phases of architectural design.

A software or design role can be considered to assist an organization in a variety of ways because the systems built will vary from description to detail, from wide to narrow scope, and from current to potential status.  The definition of replication will be used in this sense for the creation of the architecture.

Enterprise Architecture Engagements

Figure1.1 Enterprise architecture engagement.

Identification of Required Change

In order to facilitate strategic decision-making and policy coordination, architecture may be used as a tool to provide awareness of IT ability

Supporting Business Strategy– For through business strategies, priorities, goals and employees, the organization will change in order to retain cohesion.

• To provide insight for transition alternatives.
• To expand on the processes and results of a provided strategic choice.
• To check the effectiveness or efficacy of a specific strategic direction can be assisted by Organizational Architecture.

Architectural Portfolio Management of the Landscape– For a service management company, financial analysis and control of the IT portfolio are common practices among large companies.

Through promoting a correlation between organizational efficiency and strategic need for IT, Business Architecture will add another dimension to service management reporting (Kotusev, 2019).

The IT portfolio can be evaluated against operational performance data and business needs such as costs, operational functions, accessibility, receptivity by traceability between IT and enterprise architecture, in order to determine areas where misalignment has occurred and where changes have to occur.

Architectural Portfolio Management of Projects– A plan management agency offers operational analysis and control of the evolving inventory. It is standard procedure among major organizations. Based on a partnership between project scale, technical effect and market interest, enterprise design may also attach a dimension to project portfolio management reporting (Kotusev, 2019). To order alongside help rational decision-making with the project requirement and budget stages, design considerations should be applied alongside certain objective project variables.

Definition of Change

Where there has been a need for transition, design should be used to describe in a formal way the type and degree of transition.

Architectural Definition of Foundational Change Initiatives– Fundamental changes are attempts toward improvement which have a defined aim, but are not exclusively protected or limited by common goals or specifications. The main goal in fundamental change efforts is to understand the nature and context of the issue (Hermawan & Sumitra, 2019). Once the issue has been better understood, effective approaches can be established and stakeholders can be united with a common vision and intent.

Architectural Definition of Bounded Change Initiatives– Bounded improvements are actions of transformation, usually the product of a previous design plan, appraisal, or dream. The ideal outcome is already known and accepted in the context of specific reform initiatives (Tao et al., 2017). A simple approach to the defined criteria, problems, drivers and constraints is built successfully in the context of architectural activities in this form of commitment.

Implementation of Change

Architecture at all levels of the organization may be used as a strategy to regulate reform efforts by the introduction of a general perspective, institutional limitations and the specification of requirements for making technological decisions (Hermawan & Sumitra, 2019).

Architectural Governance of Change Implementation– It provides a framework for the design and execution when an architectural solution model has been developed. A continued Architecture Governance of the development phase is essential for a design review, refining of the architecture and the escalation problem to insure that the objectives and importance of the specified architecture are properly achieved (Seebregts et al., 2017).

Conclusion

TOGAF is generally known as the standard system for the development and maintenance of client architecture. Many technological enablers have rendered organizational infrastructure possible, like increasingly efficient server design techniques that publicize knowledge on Company Intranets. This integration of methods and methodologies allows businesses to make smarter choices on technological expenditure and the development of business processes through their organization architecture.

TOGAF has an existing methodology, which is the culmination of years of worldwide leading market architects research and growth. It guides architects in their usage for industry, IT, and application modeling of standard taxonomy. A common language allows us to learn and comprehend the knowledge in an organization. Organizational design templates creatively reflect company principles and spread information to employees as released on the organizational intranet. A well-developed design contributes to a more optimized system set, fewer configurations, more knowledge communication, improved process stability, and faster maintenance. The market objective of the phase of architectural construction and the need to collaborate closely to ensure that the approaches are compatible with business requirements is associated with the solution.

References

Cabrera, A., Abad, M., Jaramillo, D., Gómez, J., & Verdum, J. C. (2016). Definition and implementation of the Enterprise Business Layer through a Business Reference Model, using the architecture development method ADM-TOGAF. In Trends and Applications in Software Engineering (pp. 111-121). Springer, Cham.

Goethals, F. (2005). An overview of enterprise architecture framework deliverables. Available at SSRN 870207.

Hadaya, P., Leshob, A., & de Verteuil, J. N. (2019, October). An Artifact for Learning the TOGAF Architecture Development Method. In International Conference on e-Business Engineering (pp. 435-449). Springer, Cham.

Haghighathoseini, A., Bobarshad, H., Saghafi, F., Rezaei, M. S., & Bagherzadeh, N. (2018). Hospital enterprise architecture framework (study of Iranian university hospital organization). International journal of medical informatics, 114, 88-100.

Hakim, A., Arif, M., Nofita Saputri, D., Rizanah Warang, R., & Sfenrianto, S. (2019). Information Technology Architecture Design to Automate Enterprise Business Process Using Togaf Adm. Information Technology Architecture Design to Automate Enterprise Business Process Using Togaf Adm (September 13, 2019). International Journal of Mechanical Engineering and Technology, 10(3).

Hermawan, R. A., & Sumitra, I. D. (2019, November). Designing Enterprise Architecture Using TOGAF Architecture Development Method. In IOP Conference Series: Materials Science and Engineering (Vol. 662, No. 4, p. 042021). IOP Publishing.

Jallow, A. K., Demian, P., Anumba, C. J., & Baldwin, A. N. (2017). An enterprise architecture framework for electronic requirements information management. International Journal of Information Management, 37(5), 455-472.

Kotusev, S. (2018). TOGAF-based enterprise architecture practice: An exploratory case study. Communications of the Association for Information Systems, 43(1), 20.

Kotusev, S. (2019). The Process View of Enterprise Architecture Practice. British Computer Society (BCS), URL: https://www. bcs. org/content-hub/the-process-viewof-enterprise-architecture-practice.

Masuda, Y., & Viswanathan, M. (2019). Enterprise Architecture for Global Companies in a Digital IT Era: Adaptive Integrated Digital Architecture Framework (AIDAF). Springer.

Masuda, Y., Shirasaka, S., Yamamoto, S., & Hardjono, T. (2017). An adaptive enterprise architecture framework and implementation: Towards global enterprises in the era of cloud/mobile IT/digital IT. International Journal of Enterprise Information Systems (IJEIS), 13(3), 1-22.

Moghaddam, M., Kenley, C. R., Colby, J. M., Berns, M. N. C., Rausch, R., Markham, J., … & Deshmukh, A. V. (2017, July). Next-generation enterprise architectures: Common vernacular and evolution towards service-orientation. In 2017 IEEE 15th International Conference on Industrial Informatics (INDIN) (pp. 32-37). IEEE.

Pasaribu, F. A., Sipahutar, J. H., Situmorang, B. P., Sfenrianto, S., & Kaburuan, E. R. (2019, July). Designing Enterprise Architecture in Hospitals Group. In 2019 International Conference on Information and Communications Technology (ICOIACT) (pp. 862-867). IEEE.

Puspitasari, I. (2019, August). Extending IT-based Competitive Strategy Framework using Architecture Vision and Business Architecture of TOGAF Architecture Development Method (ADM). In Proceedings of the 9th International Conference on Information Communication and Management (pp. 37-42).

Rurua, N., Eshuis, R., & Razavian, M. (2019). Representing Variability in Enterprise Architecture. Business & Information Systems Engineering, 61(2), 215-227.

Sajid, M., & Ahsan, K. (2014). Enterprise architecture for healthcare organizations. World Applied Sciences Journal, 30(10), 1330-1333.

Seebregts, C. J., Pillay, A., Crichton, R., Singh, S., & Moodley, D. (2017). 14 Enterprise Architectures for Digital Health. Global Health Informatics: Principles of EHealth and MHealth to Improve Quality of Care, 173.

Tao, Z. G., Luo, Y. F., Chen, C. X., Wang, M. Z., & Ni, F. (2017). Enterprise application architecture development based on DoDAF and TOGAF. Enterprise Information Systems, 11(5), 627-651.

Urbaczewski, L., & Mrdalj, S. (2006). A comparison of enterprise architecture frameworks. Issues in Information Systems, 7(2), 18-23.