=Paper=
{{Paper
|id=Vol-3327/paper06
|storemode=property
|title=Role Clusters and Representative Skill Sets for Designing EAM Teams: A Quantitative Approach
|pdfUrl=https://ceur-ws.org/Vol-3327/paper06.pdf
|volume=Vol-3327
|authors=Hasan Koc,Samuel Dennis Mietke
}}
==Role Clusters and Representative Skill Sets for Designing EAM Teams: A Quantitative Approach==
https://ceur-ws.org/Vol-3327/paper06.pdf
Role Clusters and Representative Skill Sets for
Designing EAM Teams: A Quantitative Approach
Hasan Koç1,* , Samuel Dennis Mietke1
1
Berlin International University of Applied Sciences, Salzufer 6, 10587 Berlin, Germany
Abstract
Due to its holistic nature, different units and roles typically co-exist in Enterprise Architecture Man-
agement (EAM) teams. Such roles are defined by the organizational leaders based on uncoordinated
and vague requirements, which might lead to problems. A solution proposal is focusing on the required
competencies of the roles, rather than their naming and definition. When studying the roles, EAM litera-
ture rarely revolves around the skills. Albeit its considerable complexity, TOGAF’s Architecture Skills
Framework aims to close this gap. We argue that it is an intricate undertaking to analyse 790 different
values per position when acquiring an EAM team member. Hence, this study presents a quantitative
approach that aims to reduce the complexity of Architecture Skills Framework in designing Enterprise
Architecture Management teams. The approach consists of i) clustering the EAM roles from TOGAF
using ANOVA, ii) reducing the number of skills, and iii) creating a well-defined set of competencies for
each group using a survey. Against this background, the initial contributions of this work are the four
role clusters that can be used when designing EAM teams, a representative set of skills that the roles
require and recommendations for EAM practitioners.
Keywords
Enterprise Architecture Management, ANOVA, Architecture Skills Framework, TOGAF
1. Introduction
Driven by the new technologies, customer needs, regulations, and pressure from market players,
organizations are in constant need of transformation. Transformation can be addressed from
several perspectives, such as strategy (goals, challenges, opportunities, capabilities), business
operations (processes, actors, resources), information (business concepts, products), information
technology (requirements, components), etc. However, to develop effective solutions and to
ensure their fit in the organization, these perspectives need to be analyzed in an integrated
manner. For example, business processes should support goals, manage the information objects,
and motivate requirements for supporting information systems. Enterprise Architecture Man-
agement (EAM) is one approach which allows organizations to manage their structures, and
navigate their way through the complexity by adopting Enterprise Modeling methods. This
integrated and multi-perspective way of capturing and analyzing enterprise solutions is at the
PoEM 2022 Forum, 15𝑡ℎ IFIP Working Conference on the Practice of Enterprise Modeling 2022 (PoEM-Forum 2022),
November 23-25, 2022, London, UK
*
Corresponding author.
$ koc@berlin-international.de (H. Koç); samueldennismietke@berlin-international.de (S. D. Mietke)
0000-0002-1614-0230 (H. Koç)
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
core of EAM. Offering a holistic perspective, EAM links different views of an organization in a
meaningful way.
Traditionally EAM consists of various modeling dimensions, such as business, application,
technology or data, different organizational units, teams and roles typically co-exist in EAM
teams. For example, in a transformation project, a business architect provides knowledge
on business requirements, a solution architect provides the details of the to-be application
landscape, a data architect ensures adherence to corporate data standards and infrastructure
architect plans the underlying technologies and systems.
In practice, such roles are defined by the organizational leaders based on uncoordinated and
vague requirements when putting a team together. This rather inconsistent approach might
lead to some problems [1]. First, there is a lack of standardization within the organizations,
i.e., role definitions are generated arbitrarily. Oftentimes the name of the architectural layer
that a team member is responsible for is just used as a prefix to the term "architect", such as
"Application Architect". A common challenge in EAM projects is the lack of understanding
of EAM benefits, followed by a biased perception on its technical nature [2]. Defining roles
arbitrarily might strengthen this perception and enforce the view that EAM is operating in
an ivory tower. Furthermore, given the lack of expert knowledge in the market, it is rather
unrealistic to aim at filling the open positions in EAM teams with respective architects. What
could be more feasible is training the employees of the organization for EAM tasks based on
their competencies and interests.
A solution proposal against the above-mentioned problems could be focusing on the required
skills of the roles, rather than paying too much attention on the naming of the roles and their
definitions. As discussed in Section 2, there is a plethora of roles discussed in the EAM literature,
yet the required levels for the skills are missing. One exception is TOGAF Architecture Skills
Framework which documents roles in EAM projects and their required proficiency levels [3].
The Architecture Skills Framework includes 10 roles, 79 skills, and four competency levels,
totaling in the analysis of 790 different values per position in an EAM team. This is a large
number, which should be reduced for a practical application in designing EAM teams. Against
this background, this study shows how the Architecture Skills Framework can be compressed
both from roles and skills perspectives by adopting quantitative methods. Hence, our research
question is "How can the roles and skills of the TOGAF Architecture Skills Framework can be
clustered for a practical use in designing EAM teams?".
This work is organised as follows: Section 2 reviews the literature on the EAM roles and
introduces three approaches when defining the roles. Section 3 details the research method,
data collection and data analysis process. Section 4 documents the results, clusters the EA roles
and attributes them a distinct set of skills. The results are discussed in Section 5 in a greater
detail. Section 6 summarizes the findings, informs on the limitations of this work and mentions
the future studies.
2. Literature Review
2.1. Enterprise Architecture Management
Enterprise Architecture Management is a management discipline that “establishes, maintains and
uses a coherent set of guidelines, architecture principles and governance regimes that provide
direction and practical help in the design and development of an enterprise’s architecture to
achieve its vision and strategy” [4]. [5] defines the implementation of an Enterprise Architecture
(EA) as a multidisciplinary process. Alternatively, [6] describes EA as a “structured and aligned
collection of plans [to represent the] business and [IT] landscape of the enterprise”. [7] goes
one step further by defining it as the description of the enterprise that aligns business with
IT as well as their stakeholders. Ultimately, EAM aims to create business-IT alignment in the
enterprise with the use of various Enterprise Architecture artifacts [8, 7, 9].
2.2. Approaches for Defining EAM Team Roles
Our literature review shows three approaches for defining the EAM team roles. The first
approach determines roles within an enterprise architecture team that are based on the respon-
sibilities and tasks required in an EA endeavor. Here, [10] conducts a survey with more than 350
experts in the EA domain. Arguing for a new perspective of roles in EAM, the study describes
the roles, tasks, and skills of enterprise architects in today’s volatile, uncertain, complex, and
ambiguous (VUCA) world. The roles are distributed into two categories, the "general roles"
(e.g. Change Agents, Communicators, Leaders) and the "domain-specific roles" (e.g. Applied
Enterprise Architects, Enterprise Business Architects). Furthermore, 7 skill facets of enterprise
architects are presented which are applied to both categories.
In a similar manner, [11] conducts an extensive literature review by analyzing more than 50
EAM frameworks and uses seven of them to compile a comprehensive overview of eleven roles
(e.g. Business Architect, Application Architect, Infrastructure Architect) in an EAM team. The
study present an overview of the required core skills and competencies for the aforementioned
roles.
The second approach is defining the enterprise architect as a multidimensional role. Each
dimension of the enterprise architect is responsible for another functional activity within the
EAM process, which makes this approach comparable to Mintzberg’s managerial roles [12].
One example is [13], which conducts a thematic analysis of expert interviews and argues that
the enterprise architect is a “multifaceted” role with two distinct global themes; the Manager
and the Technologist. The Manager global theme comprises seven subset roles (e.g. Vendor
Manager, Standards Enforcer) that are of holistic, organizational nature, while the four roles
of the Technologist global theme are rather specialized and execution-focused (e.g. System
Architecture Designer, Business Process Modeller). Together both themes comprise a total
of eleven subset roles of the enterprise architect that are based on its various responsibilities
and functions within the company. Similarly, [14] argue that the enterprise architect is a
multidimensional role, divided into five broad categories (e.g. Change Agent, Communicator,
Leader). All categories of the enterprise architect require joint competencies (e.g. Analytical
and Problem Solving Skills, Modeling Skills).
Figure 1: Architecture Skill Framework: Role Skill Matrices based on [3]
The third approach groups roles within the enterprise architecture team, based on a hier-
archical structure. One example is [15], which proposes a hierarchical design by dividing the
company’s EA stakeholders into three clusters (Core, Implicit and Applied Enterprise Architects).
Similarly, [16] propose hierarchical division of roles and introduce an EA Role structure as
a three-level pyramid. The higher a role is located within the pyramid, the more holistic its
responsibilities within the organization become. Lower positions within the pyramid entail a
rather operational focus on their responsibilities.
The general field of EAM has been abundantly studied in the past, yet the literature shows
diverging approaches of defining roles in EAM. While the roles and responsibilities are tied
to competencies, proficiency levels for those skills are not sufficiently investigated within the
aforementioned approaches. The Open Group Architecture Framework (TOGAF) Version 9.2
attempts to close this gap with the Architecture Skills Framework [3], which is a supportive
resource to train and develop EAM staff in an organization. The framework comprises of
10 roles, 79 EA-related skills, and 4 knowledge levels for the skills and roles. For example,
a Business Architect (role) needs to be an expert (level) in Business Process Design (skill),
whereas an Architecture Sponsor (role) needs to have background knowledge (level) in this
area. The Architecture Skills Framework is quite extensive since the levels ranging from 1
(background knowledge) to 4 (expert knowledge) are attributed to each of the 79 skills of the
10 roles. However, due to this complexity, the framework might be rather difficult to apply in
practical scenarios. Motivated by the solution proposal mentioned in Section 1, we suggest that
the roles can be clustered into groups of distinct skill requirements. Next sections detail this
process.
Figure 2: Line chart with error bars of mean proficiency levels per role
3. Research Method
The research method utilised in this study is quantitative and comprises of three phases;
organizing the data (Section 3.1), analyzing the data (Section 3.2), and designing a survey
(Section 3.3).
3.1. Data Organization
Given its popularity in EAM [17, 18] and extensive focus on skill/ knowledge levels, TOGAF
9.2 Architecture Skills framework has been chosen as a base for further analysis of the roles of
enterprise architects and experts in the field. A visual inspection of the skill matrices revealed
that some of the roles share the same skill proficiency levels across a selection of skills.
The initial step of the research process was the organization of data from the TOGAF 9.2
Architecture Skills Framework [3]. Its role-skill matrices were gathered in a spreadsheet (see
Figure 1), compiled via a union join, and subsequently transposed into the long format for
further analysis. Further cleansing of the data was not necessary, as it contained no missing
values and was sufficiently structured. The resulting table was imported into an R environment.
After this, line chart with error bars of the roles’ mean values with a 95% confidence interval
was created to visually inspect the differences between the mean values, as depicted in Figure 2.
3.2. Data Analysis
We used the Analysis of Variance (ANOVA) method to cluster the roles in the Architecture
Skills Framework. This method comprises a selection of models to test the null hypothesis of
whether mean values between three or more groups are equal, i.e. 𝐻0 = 𝜇1 = 𝜇2 = ... = 𝜇𝑘 . In
other words, we investigated the claim that mean skills proficiency levels of all groups (roles) are
statistically similar to each other. Rejecting 𝐻0 would indicate that the roles’ mean proficiency
levels deviate significantly from each other. The two objectives of the ANOVA have been to
review the ten roles of TOGAF 9.2, and empirically group and reduce the number of roles
appropriately.
To avoid committing a Type I error, we tested the two assumptions "normality of observations"
and "homogeneity of variance" [19]. A histogram was used to verify the normal distribution of
the skill proficiency levels. After performing the ANOVA, the insights from the histogram have
been controlled with the analysis of normality of residuals via a Quantile-Quantile plot (Q-Q
plot). The homogeneity of variance required testing whether the variances in skill proficiency
levels among the roles were similar. Initially, Levene’s test was performed. The test turned out
to be significant, indicating a violation of the homogeneity of variance, 𝐹 (9, 780) = 3.089, 𝑝 <
0.001, 𝜔 2 = 0.320. In line with [19], we performed a Welch’s F instead of a basic ANOVA.
Welch’s F involved one response variable (skill proficiency level) and ten control groups
(roles from TOGAF 9.2) as the independent variable. Welch’s ANOVA was conducted with
the intention of rejecting its 𝐻0 . A rejection would support the clustering of roles into groups
of similar skill requirements. To further explore the between-role differences between the
roles’ means Bonferroni correction, has been conducted (see Table 1. Statistically relevant
p-values (p<0.05) suggest significant differences between two roles. Insignificant differences
were therefore used to propose clusters of groups.
3.3. Survey Design
The goal of the third phase was condensing the skills for the clustered groups. The Architecture
Skills Framework defines seven skill groups, hence all seven matrices were compiled into one
large matrix, containing all 79 skill rows, as well as the roles that have been clustered via
ANOVA. Subsequently, the authors reduced the skills based on the following criteria.
• Skills with equal proficiency values for all roles were eliminated as the roles would have
been indistinguishable based on these particular skills. Eliminated skills based on these
criteria are "Teamwork", or "Business Metrics", which seem to have equal importance for
all ten roles (cf. Figure 1).
• If two or more skills were too similar in terms of their definition and mean values, they
have been reduced to one or combined with an existing skill.
– "Information Consumer Applications" ( 𝑥 = 2.8) and "Information Provider Ap-
plications" (𝑥 = 2.7) were reduced to "Information Applications (consumer and
provider)".
– "Written Communications" ( 𝑥 = 3.6), and "Oral Communications" ( 𝑥 = 3.7) were
combined with "Inter-personal" skills ( 𝑥 = 3.8).
– "Managing Business Change" ( 𝑥 = 3.3) was combined with "Change Management"
( 𝑥 = 3.2).
– "Business Process Design" ( 𝑥 = 2.6) was combined with "Business Modeling" (
𝑥 = 2.8).
– "Solutions Modeling" ( 𝑥 = 3.0) was combined with "Modeling Skills" ( 𝑥 = 3.1).
– "Data Interchange" ( 𝑥 = 2.6) and "Data Management" ( 𝑥 = 2.7) was reduced to
"Data Management and Interchange".
– "Security" ( 𝑥 = 2.8) was combined with "Identity Management" ( 𝑥 = 2.6).
One author discussed the results with three practicing enterprise architects in a workshop
setting. Before the workshop, the enterprise architects were informed on the study and were
provided with the reduced skills framework. The goal of the workshop was identifying further
skills that do not adhere to the above-mentioned criteria but deem as generic or not relevant.
There was a consensus on removing "Contract Law" and "Fraud" from the Legal Environment
set, "International Operations", "Graphics Image" from the Technical IT Skills set, as well as
"End User Support", "Systems", and "Web-based Services" from the IT General Knowledge Skills
set. Note that those skills are removed only after reaching an agreement among the workshop
participants. In case of differing opinions, the respective skill was kept in the matrix.
The result was a matrix including 59 skills, based on which a survey1 was generated. The
survey participants were asked to identify five distinct skills per clustered role. This approach
was favored to prevent an overlap of the same skill for two different roles. Five enterprise
architects participated in the survey. Section 4 documents and discusses the findings.
4. Results and Findings
4.1. Clustering the EA Roles
Due to the potential violation of the assumption of homogeneity of variance (See section
3.2), Welch’s ANOVA was performed. Welch’s adjusted F-ratio has shown high statistical
significance, 𝐹 (9, 317.23) = 40.424, 𝑝 < 2.2𝑒 − 16, 𝜔 2 = 0.310, which supports the rejection
of 𝐻0 . Thereby, we reject the null hypothesis that mean skills proficiency levels of all roles
are statistically similar to each other. In other words, the roles’ mean proficiency levels in
Architecture Skills Framework deviate significantly from each other.
Based on the insights from Welch’s ANOVA, the between-group differences in means were
checked via post-hoc test. The Bonferroni correction examined which of the roles were signifi-
cantly different from, or similar to, each other using p-values in a pairwise comparison matrix.
Table 1 shows p-values < 0.05 highlighted in blue, which indicate a significant difference between
means while p-values = 1 indicate potentially equal means. Some roles share statistically similar
means with others while having distinctly different means from the rest of the roles.
Based on the Bonferroni correction, following clusters were determined.
• Cluster 1: Architecture Board Member, Architecture Sponsor
1
The survey can be downloaded here.
Table 1
Bonferroni correction table with p-values
p-Values
Roles 1 2 3 4 5 6 7 8 9 10
Application Architect -
Architecture Board Member <2e-16 -
Architecture Sponsor <2e-16 1 -
Business Architect 0.114 8.9e-15 8.7e-16 -
Data Architect 1 <2e-16 <2e-16 0.381 -
Enterprise Architecture Manager 1 <2e-16 <2e-16 0.212 1 -
IT Designer 1.3e-11 3.0e-03 8.6e-04 5.6e-04 1.9e-10 5.0e-11 -
Program/ Project Manager 5.3e-08 7.6e-06 1.6e-06 0.082 5.2e-07 1.7e-07 1 -
Solution Architect 9.0e-05 2.5e-09 3.7e-10 1 5.6e-04 2.3e-04 0.381 1 -
Technology Architect 1 <2e-16 <2e-16 0.082 1 1 6.4e-12 2.9e-08 5.6e-05 -
• Cluster 2: Application Architect, Business Architect, Data Architect, Enterprise Architec-
ture Manager, Technology Architect
• Cluster 3: Program/ Project Manager, IT Designer, Solution Architect
The results were mostly in line with our initial analysis, except for Cluster 3. Cluster 3
included the two roles Solution Architect and IT Designer, which have a slight overlap as shown
in Figure 2. This cluster might contradict the commonly accepted state of the literature regarding
the Solution Architect role, a view supported by [20, 21]. [20] argues that there are “important
differences” between the Solution Architect and the IT Designer. Hence, we decided to perform
an additional ANOVA on the roles of the third cluster.
The data set was reduced to only the three roles, ANOVA’s assumptions (cf. Section 3.2)
have been checked. According to the histogram the reduced data was normally distributed.
The Q-Q plot, however, revealed an under-dispersion, within ANOVA’s residuals, relative to a
normal distribution. Although the results of these two methods contradict each other, the F-ratio
of an ANOVA can still be robust to violations of normality when the sample sizes are equal
[19], which is the case here (n=79). Levene’s test was not significant suggesting homogeneous
variances across all three roles 𝐹 (2, 234) = 1.814, 𝑝 = 0.165, 𝜔 2 = 0.019. To successfully
verify this outcome, the Residuals vs. Fitted plot was inspected afterwards. After fulfilling
its assumptions, a basic one-way ANOVA was performed. The test produced a significant
F-ratio, 𝐹 (2, 234) = 3.314, 𝑝 = 0.038, 𝜔 2 = 0.019, therefore supporting the rejection of 𝐻0
and indicating that at least one of the roles in Cluster 3 had a significantly different mean skill
proficiency level.
Two post-hoc tests were applied to this reduced data set to identify the between-group
differences in the roles’ means. The Bonferroni correction revealed that the Program / Project
Manager shares significant similarities with both other roles, which coincides with Figure 2. The
Solution Architect and the IT Designer differ significantly from each other based on their mutual
p-value (𝑝 = 0.032). Tukey’s honesty significance difference (HSD) multiple comparisons
test, as well as its 95% confidence intervals confirm the observations from Bonferroni test with
significant differences between the Solution Architect and the IT Designer, 𝑡 = −2.574, 𝑝 = 0.029.
The result of the HSD test is shown in Table 2. In other words, the proficiency levels required for
IT Designer and Solution Architect roles in Architecture Skills Framework deviate significantly
from each other. Due to its lower mean estimate value (0.165 vs. −0.177), Program/ Project
Table 2
Tukey’s HSD multiple comparison results
Linear Hypothesis Mean Estimate lower CI upper CI SE t-Value p (>|t|)
IT Designer - Solution Architect == 0 -0.342 -0.655 -0.029 0.133 -2.574 0.029
Program/ Project Manager - Solution Architect == 0 -0.177 -0.490 0.136 0.133 -1.335 0.377
Program/ Project Manager - IT Designer == 0 0.165 -0.149 0.478 0.133 1.239 0.431
Table 3
Respondent’s vote counts per skill, per role
Enterprise Architect Votes Solution Architect Votes
Strategic Planning 4 Systems Integration 3
Modeling Skills 3 Data Design 2
Enterprise Architecture Tools 3 Application Design 2
Architecture Principles Design 2 Migration Planning 2
Architecture Views & Viewpoints Design 2 Network & Communications Infrastructure 2
Architecture Sponsor Votes Program / Project Manager Votes
Business Culture 3 Stakeholder Management 4
Value Management 3 Project Management 4
Business Scenario 2 Business Case 2
Visioning 2 Change Management 2
Legacy Investments 2
IT Industry Standards 2
Manager was kept within the same cluster as the IT Designer.
Based on the post-hoc tests correction, the clusters were finalised as follows.
• Cluster 1: Architecture Board Member, Architecture Sponsor
• Cluster 2: Application Architect, Business Architect, Data Architect, Enterprise Architec-
ture Manager, Technology Architect
• Cluster 3: Program/ Project Manager, IT Designer
• Cluster 4: Solution Architect
4.2. Skill Sets for the Role Clusters
As mentioned in Section 3.3, we created a matrix comprising of 59 skills and four representative
roles for each cluster. For evaluation purposes, the respondent’s answer matrices were rear-
ranged and regrouped by roles, resulting in four new matrices. In this context, the clusters were
named as Enterprise Architect, Architecture Sponsor, Program/Project Manager, and Solution
Architect, respectively.
The survey was completed by the practicing enterprise architects which were contacted
based on convenience sampling. To derive the skills for each cluster, the vote counts of the roles
were compared. Skills with less than two votes have been sorted out. If the same skill had votes
among two or more roles, the skill with the lower vote count was dropped. If the skills had
equal vote counts among two or more roles, a subjective decision has been made in accordance
with the approval of an enterprise architect. This decision was based on whether the other roles
already had a representative skill assigned with a similar definition to the skill in question.
Five of the ten participants answered the survey. In each matrix, the number of respondent
votes per skill has been counted. The skills with the highest agreement among respondents
were Strategic Planning for Enterprise Architects, as well as Stakeholder Management and Project
Management for Program/ Project Managers. The final selection of representative skills per
role cluster is shown in Table 3.
EAM is a holistic discipline, and it uses the methods of Enterprise Modeling. This is reflected
within the most voted three skills of the Enterprise Architect cluster. In modeling the as-is and
to-be of the organization, the Enterprise Architect defines the underlying rules and guidelines,
i.e. the architecture principles. Since the resulting models need to be communicated with the
leadership, appropriate report types need to be designed and selected. Knowledge within this
domain is represented within the Architecture Views & Viewpoints Design skill.
Any EAM project faces the risk of having reluctant information providers [22]. Removing
blockers, promoting and championing the EA projects, Architecture Sponsors need to know
the Business Culture of the company, its vision and legacy investments. Taking an external
perspective, they need to be able to create sustainable value for the organization, and its
stakeholders. Skills in IT Industry Standards seem to be perceived as helpful in this role.
Solution Architects have the responsibility for architectural design and documentation at a
system or subsystem level [3]. Compared to other roles in our cluster, their skills are rather
on the technical side with the goal of ensuring the Business-IT alignment. In developing and
implementing the technical solutions for business problems, solution architects need to be
skillful in systems integration and Migration Planning. Also, Data Design and Application
Design skills are critical for aligning the IT Strategy to the needs of business.
Program and Project Managers obviously need skills in managing the stakeholders and projects.
Their knowledge in Business Cases might be helpful in defining pilot scenarios in the early
phases of the EAM projects, where modelling patterns, meta-models and conventions are created.
Change Management skills are needed to use the results of the pilot scenarios, and raise the
awareness of the EAM projects, which is a key success factor as studied in [23].
5. Discussion and Recommendations
The research question this study aims to answer is "how can the roles and skills of the TOGAF
Architecture Skills Framework be clustered for a practical use in designing EAM teams". Our
investigation suggests four prominent role clusters, which we termed as "Enterprise Architect,
Architecture Sponsor, Program/ Project Manager", and "Solution Architect" in EAM.
The literature review shows that consensus between the resources is limited due to the
divergence of the approaches mentioned in section 2.2. A reoccurring role is the Architect that
in some publications appears as one independent role [13, 24], while being split up in other
works into various roles based on their scope of duties [16, 3, 10, 11]. Change Agent is only
found in the publications from the second approach [13, 14]. The Standards Manager[11] or
Standards Enforcer [13], as well as the Solution Architect [3, 11] share the same definition in
their respective papers. But apart from that all publications examined propose considerably
distinct sets of roles. As a consequence, Architecture Skills Framework of TOGAF 9.2 was used
as a foundation to establish a set of roles that was used for further analysis.
We produced a total of twenty skills as illustrated in Table 3 for the four role clusters derived
from the Architecture Skills Framework. The Enterprise Architect and the Solution Architect
included five, the Architecture Sponsor included six, and the Program/ Project Manager included
four skills that are representative for each role, according to the survey respondents. Except
for the Architecture Sponsor, which has one skill (IT Industry Standards) that does not comply
with the role-skill matrices of the framework, the skills from the survey, and their allocation to
the roles, generally coincides with the skill proficiency levels in the matrices. The "IT Industry
Standards" skill was mentioned also once for the Solution Architect role cluster.
The skills "Strategic Planning", "EA Tools", as well as "Architecture Principles Design" and
"Architecture Views & Viewpoints Design" are mentioned only in the Enterprise Architect role
cluster. This is in line with the key characteristics of an enterprise architect proposed in [24].
"Modeling Skills" are also attributed to the Solution Architect role. Indeed, migration planning
is a task where the Solution Architect should be able to model the future landscapes of the
organization.
The characteristic skills of the Architecture Sponsor role are "Visioning", "Business Culture",
"Legacy Investments", and "Business Scenario". This might translate to the practice that Archi-
tecture Sponsors should be helpful in providing support in terms of resources/ information from
various teams and units. Furthermore, they should provide the EA teams with requirements
for strategic decision making, since the sponsors define the company vision, and are aware of
the "Business Scenario" within which the EA Project is being implemented. Having profound
knowledge on the business culture, they should serve as a point of escalation and remove
blockers within their control sphere.
"Stakeholder Management" is the single skill which is attributed to all groups, except for the
Enterprise Architect role cluster. Given the amount of dependency on the organisational units
in the EA projects, we interpret this finding that enterprise architects certainly need support
especially when other stakeholders are involved. This finding should not be understood in
a way that enterprise architects do not need this skill at all. On the contrary, managing the
stakeholder requirements is one key task of every enterprise architect. Hence, our interpretation
is that in an environment where skills do not overlap much, "Stakeholder Management" is
not a characteristic attribute of an Enterprise Architect, but of the Program/ Project Manager.
Furthermore, one common EAM challenge cited frequently in the literature is the lacking
influence of EA on activities of organizational development [25]. To overcome this challenge,
EAM practitioners should ensure to include team members who are skillful in managing the
stakeholders.
6. Summary and Future Work
This study presented an initial quantitative approach that aims to reduce the complexity of
Architecture Skills Framework in designing Enterprise Architecture Management teams. The
approach consisted of i) grouping the roles in EAM via ANOVA, ii) Reducing the number of
skills, and iii) Creating a well-defined set of competencies for each group using a survey. Against
this background, two main contributions of this work are creating role clusters for designing
EAM teams and attributing a representative set of skills for them.
Although our results are generally in line with the Architecture Skills Framework of TOGAF
9.2, their generalizability is limited due to the small sample size of the survey. Out of the ten
architects, only five have responded to the survey. That made it difficult to find a significant
consensus between the respondents about which skills are truly representative, as some of
the skills were determined to be representative based on two votes. Future work considers
performing the study with a larger sample of practicing architects. Potential benefits of reducing
skills are tied to the risk of information loss. In order to mitigate this risk, we plan to involve
the participants of the study already during the skill reduction step (cf. Step ii above). Doing so
should allows us to gather insights on the problems that might arise due to the reduction.
TOGAF 10 was published in 2022 by The Open Group as the newest version of the TOGAF
framework, also including the Architecture Skills Framework [24]. In an initial analysis, the
newer framework has proven to have the same structure, roles, skill categories, skills, and
proficiency levels. The notional alignment of maturity/skill level versus role has not been
checked. Thus, we are planning to perform further analysis with the newer data set, which
possibly requires involving the utilization of robust methods against the violations of the
ANOVA assumptions and investigate whether our findings still hold.
Currently and using the results of our study, we are developing an "EA Roles and Skills"
test that asks job candidates for their own perceived proficiency levels for the skills shown in
Table 3. For each skill, the candidates should be able to select a skill proficiency level value
between one and four. That is the same scale that Architecture Skills Framework introduced for
its role-skill matrices [3]. That way, the responses should be easily compared to the matrices
for evaluation. Based on the evaluation, the candidate’s role should be predicted. A further step
in this endeavour relates to designing a personality test, which is tied to the identified skills in
this study. The reviewed literature provided only very few insights for straightaway applicable
personality test. Especially in the domain of EAM, there seems to be no study conducted
regarding the development of such tests. Instead, some publications have conducted research
about tests in domains partly related to EAM, such as software engineering. While literature
reviews of [26] and [27] are focused on the popular psychometric test methods, such as MBTI
or FFM, [28] and [29] present more complex analysis methods, e.g. k-Nearest Neighbors (k-NN)
or the FLORA personality test method.
We hope to contribute to the literature and practice by creating role clusters when designing
EAM teams as well as skill sets thereof. Rather than limiting oneself to the role names that
might vary depending on the circumstances, competence-based role clusters can be used. The
fact that the clusters were created with a smaller sample calls for further broadening the data
basis to improve the generalizability of the outcomes. Initial results indicate that EA leaders and
practitioners can take this representative set of skills into consideration when putting together
a team of architects.
References
[1] D. H. Olsen, Enterprise architecture management challenges in the norwegian health
sector, Procedia Computer Science 121 (2017) 637–645. URL: https://www.sciencedirect.
com/science/article/pii/S1877050917322846. doi:https://doi.org/10.1016/j.procs.
2017.11.084, cENTERIS 2017 - International Conference on ENTERprise Information
Systems / ProjMAN 2017 - International Conference on Project MANagement / HCist 2017 -
International Conference on Health and Social Care Information Systems and Technologies,
CENTERIS/ProjMAN/HCist 2017.
[2] S. Lauvrak, V. K. Michaelsen, D. H. Olsen, Benefits and challenges with enterprise archi-
tecture: a case study of the norwegian labour and welfare administration, in: Proceedings
from the annual NOKOBIT conference, 2017.
[3] TOGAF9, The togaf standard, version 9.2: Architecture skills framework, 2018. URL:
https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap46.html.
[4] F. Ahlemann, E. Stettiner, M. Messerschmidt, Strategic Enterprise Architecture Manage-
ment, Management for Professionals, Springer, Dordrecht, 2012.
[5] E. Kalampokis, E. Tambouris, M. Zotou, K. Tarabanis, The enterprise architecture
competence framework, International Journal of Learning Technology 7 (2012) 79.
doi:10.1504/IJLT.2012.046867.
[6] D. Simon, K. Fischbach, D. Schoder, An exploration of enterprise architecture research,
Communications of the Association for Information Systems 32 (2013). doi:10.17705/
1CAIS.03201.
[7] S. Kotusev, Enterprise architecture and enterprise architecture artifacts: Questioning the
old concept in light of new findings, Journal of Information Technology 34 (2019) 102–128.
doi:10.1177/0268396218816273.
[8] D. Q. Birkmeier, A. Gehlert, S. Overhage, S. Schlauderer, Alignment of business and it
architectures in the german federal government: A systematic method to identify services
from business processes, in: 2013 46th Hawaii International Conference on System Sciences,
2013, pp. 3848–3857. doi:10.1109/HICSS.2013.77.
[9] M. Zhang, H. Chen, A. Luo, A systematic review of business-it alignment research with
enterprise architecture, IEEE Access 6 (2018) 18933–18944. doi:10.1109/ACCESS.2018.
2819185.
[10] A. Ullrich, C. Bertheau, M. Wiedmann, E. Sultanow, T. Körppen, S. Bente, Roles, tasks
and skills of the enterprise architect in the vuca world, in: 2021 IEEE 25th International
Enterprise Distributed Object Computing Workshop (EDOCW), 2021, pp. 261–270. doi:10.
1109/EDOCW52865.2021.00057.
[11] M. Wißotzki, F. Timm, P. Stelzer, Current state of governance roles in enterprise archi-
tecture management frameworks, in: B. Johansson, C. Møller, A. Chaudhuri, F. Sudzina
(Eds.), Perspectives in Business Informatics Research, Springer International Publishing,
Cham, 2017.
[12] H. Mintzberg, The nature of managerial work, Addison-Wesley Educational Publ, New
York, 1997.
[13] K. Mapingire, P. van Deventer, A. van der Merwe, Positioning the role of the enterprise
architect: An independent study in a mobile telecommunications organisation, in: 2018
Conference on Information Communications Technology and Society (ICTAS), 2018, pp.
1–6. doi:10.1109/ICTAS.2018.8368767.
[14] C. Strano, Q. Rehmani, The role of the enterprise architect, Information Systems and
e-Business Management 5 (2007) 379–396. doi:10.1007/s10257-007-0053-1.
[15] J. Gøtze, The changing role of the enterprise architect, in: 2013 17th IEEE International
Enterprise Distributed Object Computing Conference Workshops, 2013, pp. 319–326.
doi:10.1109/EDOCW.2013.42.
[16] H. Shah, M. El Kourdi, Frameworks for enterprise architecture, IT Professional 9 (2007)
36–41. doi:10.1109/MITP.2007.86.
[17] S. Kotusev, A comparison of the top four enterprise architecture frame-
works, 1/7/2021. URL: https://www.bcs.org/articles-opinion-and-research/
a-comparison-of-the-top-four-enterprise-architecture-frameworks/.
[18] B. Cameron, E. McMillan, Analyzing the current trends in enterprise architecture frame-
works, Journal of Enterprise Architecture (2013) 60–71.
[19] A. Field, J. Miles, Z. Field, Discovering Statistics Using R, SAGE PUBLICATIONS, London,
2013.
[20] R. Tandon, The role of solution architects in systems integration, IT Professional 9 (2007)
26–33. doi:10.1109/MITP.2007.40.
[21] C. Gellweiler, Collaboration of solution architects and project managers, International
Journal of Human Capital and Information Technology Professionals (IJHCITP) 10 (2019)
1–15. URL: https://ideas.repec.org/a/igg/jhcitp/v10y2019i4p1-15.html.
[22] M. Hauder, S. Roth, C. Schulz, F. Matthes, An examination of organizational factors influ-
encing enterprise architecture management challenges, ECIS 2013 Completed Research
(2013). URL: https://aisel.aisnet.org/ecis2013_cr/175.
[23] M. Lange, J. Mendling, J. Recker, An empirical analysis of the factors and measures of
enterprise architecture management success, European Journal of Information Systems 25
(2016) 411–431. doi:10.1057/ejis.2014.39.
[24] TOGAF10, The togaf standard, version 10: Architecture skills framework, 2022.
URL: https://pubs.opengroup.org/togaf-standard/architecture-skills-framework/index.
html#_Toc95293203.
[25] V. Seppänen, K. Penttinen, M. Pulkkinen, Key issues in enterprise architecture adoption in
the public sector, Electronic Journal of e-Government 16 (2018).
[26] M. Erder, P. Pureur, What type of people are software architects?, IEEE Software 34 (2017)
20–22. doi:10.1109/MS.2017.103.
[27] J. Gulati, P. Bhardwaj, B. Suri, Comparative study of personality models in software
engineering, in: I. Nair (Ed.), Proceedings of the Third International Symposium on Women
in Computing and Informatics, 2015, pp. 209–216. doi:10.1145/2791405.2791445.
[28] R. Bhannarai, Agile person identification through personality test and knn classifica-
tion technique, in: 2nd International Conference on Science in Information Technology
(ICSITech), 2016, pp. 215–219. doi:10.1109/ICSITech.2016.7852636.
[29] R. Sartori, A. Ceschi, A. Costantini, A. Scalco, Big five for work and organizations: Flora
(role related personal profile), an italian personality test based on the five-factor model
and developed for the assessment of candidates and employees, Quality & Quantity
50 (2016) 2055–2071. URL: https://link.springer.com/article/10.1007/s11135-015-0250-9.
doi:10.1007/s11135-015-0250-9.