Another Look at Enterprise Architecture Framework

Although there were many comparison literatures of EA frameworks, these literature use qualitative criteria based on intuitive practitioner’s experience. The paper first defines 36 concrete features of EA frameworks using six categories and six interrogatives. Then we concretely compare typical EA frameworks based on the key features. The result shows the easiness and concreteness of the proposed EA comparison framework

product quality, EA service quality, and EA results use in the EA benefit realization process. They also identified dimensions of constructs. For example, dimensions of EA service quality are activeness, availability, competence and usefulness. Moreover, they identified twenty two dimensions of EA benefits, such as reduction of IT cost, increased interoperability, and improved alignment. Saint-Louis et al. (2017) surveyed systematically literatures to clarify common understanding in EA definition. Although the significant divergence of different EA definitions, they found the five categories of generic EA elements are: 1) deliverable, 2) process, 3) tool, 4) people, and 5) principle and practice. Dang and Pekkola (2017) surveyed 71 EA research articles in the public sector. They suggested that future GEA needs to focus interoperability and integration, and alignment and strategy to reduce the number of fragmented business services. Nikpay et al. (2015) found requirements of EAF implementation evaluation method including artefacts quality assurance, scientific foundation, and holistic evaluation view. Nikpay et al. (2016) conducted a systematic review on post implementation evaluation models of EA artefacts. They categorized EA practices into initiation, controlling and sustainability. They also showed that current EA evaluation approaches were not covered all aspects, lacked of structured models, difficult to understand, and lack of evaluation method. Proenca and Borbinha (2017) Gill et al. (2015) showed that an adaptive enterprise service system meta-framework has been used to develop an agile or Adaptive Service Resilience Architecture (ASRA) capability. Purnawan and Surendro (2016) showed their own EA process model was able to define mainly based on TOGAF ADM for the Indonesian hospital information system. Santikarama and Arman (2016) derived an enterprise architecture framework for migrating to cloud using TOGAF. They chose TOGAF by comparing with other EA frameworks using the criteria such as Process Completeness, Reference Model Guide, Implementation Guide, Business Focus, Governance Catalogue, Vendor Neutrality, and Information Availability. Korhonen et al. (2016) proposed three levels of EA by comparing EA schools of Enterprise IT Architecting (EITA), Enterprise Integrating (EI), and Enterprise Ecological Adaptation (EEA). The EA schools have been proposed by . The EA levels are Ecosystemic, Socio-Technical, and Technical Architecture. At the Ecosistemic Architecture level, EEA collaboratively evolves with business eco-system, industry, markets, and the large society. The collaboration derives structural embeddedness among external environments, partners, and open ended interrelationship with others. Korhonen and Halen (2017) compared the aspects of digital capability for digital transformation with two levels of the enterprise-strategic and the ecosystem-adaptive EA. The aspect of digital capability consists of business digitalization, work digitalization, collaboration and connectivity, customer engagement, information and technology management, and resource use.  compared EA frameworks by using the five constitutive elements that are Meta model, Procedure model, Techniques, Role, and Specification document. The evaluation result did not reflect the latest version of TOGAF, because the paper was written in 2006. Rouhani et al. (2013) compares EA implementation methodologies using three major aspects, i.e., Concepts, Modeling, and Process. For example, modeling aspects elements are easy to use, easy to learn, traceability, consistency, different views, complexity, and dynamic. As these elements are difficult to concretely evaluate, the comparison was subjective. Kotusev (2016a) historically categorized EA frameworks into three types, i.e., Business Systems Planning (BSP) until 1980s, early EA from 1980s to 1990s, and modern EA from 1990s through present. Kotusev (2016b) categorized EA frameworks into three types, i.e., Traditional, MIT, and DYA. Then he compared the three EA types from six items, i.e., essentials approach, EA artifacts, key terms, advantages, disadvantages, and applicability. Purnawan and Surendro (2016) Compares EA frameworks by using criteria consists of Taxonomy completeness, Process completeness, Business focus, Governance guidance, Partitioning guidance, Vendor neutrality, Information availability, Time to value, Readiness assessment, and Business process standardization. They concluded that TOGAF is the most suitable for implementing hospital information systems based on the methodological capabilities. Nikpay et al. (2017) defined a comparison framework for EA frameworks. The criteria are: 1) Initiative, 2) Management process, 3) maintenance process, 4) Ability to work with other EAF, 5)

Comparison of EA Frameworks
Requirements management process, 6) Step by step guideline, 7) Easy to understand, 8) Non-functional requirements, 9) Complexity management, 10) Supporting toll, 11) Governance, 12) Type-usage, 13) Repository, and 14) Easy to use. Based on the criteria, they compared EAP, TOGAF, FEAF, and DoDAF. The comparison was basically used the previous review literatures and practitioners' interviews. Moreover, they proposed a five phased EA implementation approach consists of Initiation, As-Is, To-Be, Implementation, and Governance. They also defined checklists for each phase.

Features of Enterprise Architecture Frameworks
A new comparison framework is necessary to concretely evaluate EA Frameworks (EAF). To design concrete comparison framework, we omit subjective evaluation items such as understandability, complexity, and usability. Evaluation values of these items may conflict between different analysts.
We identified thirty six feature elements using six dimensions and six Interrogatives as shown in Table   1. Feature categories are Layer, Model, Method, Governance, Capability, and Extensibility. Explanations of proposed features are described below.

Layer
"What" column of Layer shows that EAF has the hierarchy concept of EA. "How" column of Layer shows that EAF has Business, Data, Application, and Technology architectures in the hierarchy of EA.
"Why" column of Layer shows the existence of the strategy architecture that defines the reason of EA.
"When" column of Layer shows the transition architecture to define EA implementation plan. "Where" column of Layer shows physical architecture to allocate EA components in the physical environment.
"Who" column of Layer shows stakeholders who are looking and understanding for EA layers.

Model
"What" column of Model shows that EAF has diagrams to represent EA artifact. "How" column of Model shows that EAF has Language to describe diagrams of EA artifact. "Why" column of Model shows the existence of the Meta model that defines the EA Language. "When" column of Model shows the Reference model of EA. Reference architecture is necessary to reduce duplication of EA artifacts.
"Where" column of Model shows the existence of Repository to store EA models. "Who" column of Model shows EA model architects who are developing EA models.

Method
"What" column of Method shows that EAF has process definition to implement EA. "How" column of Method shows that EAF clarifies Base Line Architecture (BLA) and Target Architecture (TGA).
"Why" column of Method shows EAF has the Reuse method. "When" column of Method shows the Iteration process of EA. Iteration is necessary to revise inappropriate portions of EA. "Where" column of Method shows the existence of tailoring process to adopt EA for individual organizations. "Who" column of Method l shows EA method architects who are developing EA methods.

Governance
"What" column of Governance shows that EAF explains EA Principles (EAP). "How" column of Governance shows that EAF explains Governance meeting to achieve EA governance. "Why" column of Governance shows the EAF mentions compliance that governs EA activities. "When" column of Governance shows Risk management to resolve unexpected incidents against EA governance. "Where" column of Governance shows the existence of Governance log to record EA governance activities.
"Who" column of Governance shows EA board who are responsible for EA governance.

Capability
"What" column of Capability shows that EAF has the Maturity model to represent implementation capability of EA. "How" column of Capability shows that EAF denotes the incremental capability of implementing EA. "Why" column of Capability explains the Skill framework of EA architects to achieve necessary levels of maturity. "When" column of Capability shows the Capability based planning necessary to achieve the capability increment of EA. "Where" column of Capability shows the Capability dimensions to evaluate EA capability. "Who" column of Capability shows EA architect who are implementing EA based on their own capability.
Published by SCHOLINK INC.

Extensibility
"What" column of Extensibility shows that EAF describes Model evolution of EA. "How" column of Extensibility shows that EAF provides means of Method evolution of EA. "Why" column of Extensibility shows the concept of EA continuum that describes from generic EA to specific organizational EA through industry EA. "When" column of Extensibility shows Forum establishment to start for extending EA. "Where" column of Extensibility shows the Forum standard to realize EA extension. "Who" column of Extensibility shows Forum team who are developing extended EA standard.

Result
This section compares six EA frameworks by using key EA features mentioned above.

Using Comparison Framework to Compare EA Frameworks
Above mentioned EA frameworks are compared below using the comparison framework in section three.
Features of EA framework A is defined as follows.  framework, Increment, EA architect}, Extensibility=>{Method evolution, Model evolution, Evolution}) Table 2 shows the result of comparison using the comparison framework in Table 2. The values in Table   2   Extensibility 0 0 0 0 2 6 Figure 1 shows the radar chart to compare EA frameworks based on Table 2.

Discussion
This paper proposes a comparison framework of EA frameworks based on concrete features. The comparison framework consists of six dimensions and six interrogatives as shown in Table 1. The feature categories are Layer, Model, Method, Governance, Capability, and Extensibility. The characteristic of the comparison framework is able to evaluate concretely. This section discusses the effectiveness, novelty and limitations of the proposed comparison framework.

Effectiveness
The proposed comparison framework is effectively applied to compare EA frameworks. As the comparison task is achieved by counting feature elements based on six categories, it is easy and concrete. There is no ambiguous decision on the way to select existed features from EA framework text book.
Using the comparison result to integrate different EA frameworks also be able. For example, model features of TOGAF can be integrated to those of EAAS, because the model feature of EAAS is weak.

Novelty
So far, there is no concrete evaluation framework on comparing EA frameworks. The proposed comparison framework only consists of objective thirty six features in two dimensions that are six categories and six interrogatives. We introduced extensibility features in the proposed EA framework comparison method for the first time. The past and current EA comparison literature did not consider the extensibility features that are significant EA framework evolution mechanism.

Limitations
The number of compared EA framework is six. It is necessary to compare other EA frameworks, such as DoDAF (DoD Architecture Framework), FEAF (Federal Enterprise Architecture Framework) and Gartner frameworks. We intentionally omitted Zachman framework, because it did not have any other features than hierarchy of Layer.
The comparison framework omits quality criteria such as understandability and complexity. These criteria is difficult to evaluate objectively. Therefore different research might have the conflict for the same criteria. Moreover, as intuitive opinion of practitioners were used to evaluate these qualitative criteria, the result depends on the expertise of practitioners.
The proposed comparison framework consists of six feature categories and interrogatives. The feature categories can be extended to more than six. It also did not evaluate the representation power of features. As shown in Figure 2, the comparison framework can be extended to add the third dimension of representation power of features. For example, the Language feature depends on the representation power of Languages.

Representation power
Categories Interrogatives