1 The Need for Enterprise Architecture
2 Current Research on Enterprise Architecture Benefit Realization
2.1 Enterprise Architecture and Its Use
2.2 Realizing Benefits from Enterprise Architecture
Document knowledge on the enterprise | Improve resource quality |
Identify resource dependencies | Improve return on investments |
Identify resource synergies | Improve situational awareness |
Identify suboptimal resource use | Improve solution development |
Improve alignment with partners | Improve stability |
Improve change management | Increase agility |
Improve compliance | Increase economies of scale |
Improve customer satisfaction | Increase efficiency |
Improve decision-making | Increase growth |
Improve employee satisfaction | Increase innovation |
Improve enterprise-wide goal attainment | Increase market share |
Improve information quality | Increase resource flexibility |
Improve investment management | Increase resource reuse |
Improve measurement | Increase resource standardization |
Improve organizational alignment | Increase revenue |
Improve organizational collaboration | Provide a high-level overview |
Improve organizational communication | Provide directions for improvement |
Improve resource alignment | Provide standards |
Improve resource consolidation | Reduce costs |
Improve resource integration | Reduce complexity |
Article | Number of constructs | Number of interrelationships | Included constructs (or categories for the constructs) | Constructs leading to benefits |
---|---|---|---|---|
Aier (2014) | 6 | 5 | Group culture, EAP management, EAP application, EAP guidance, EA consistency, EA utility | EA consistency |
Alaeddini et al. (2017) | 12 | 16 | Communications, competency/value measurements, governance, partnership, scope and architecture, skills, EA framework, organization size, organization type, country, EA, business-IT alignment | Communications, competency/value measurements, governance, partnership, scope and architecture, skills |
Bischoff et al. (2014) | 2 | 1 | Use intensity of artifact, realization of benefit | Use intensity of artifact |
Boh and Yellin (2007) | 13 | 11 | Governance mechanisms for EA standards management, use and conformance to EA standards, outcomes (main categories) | Use and conformance to EA standards |
Boucharas et al. (2010) | 4 | 3 | Contexts, intervention, mechanisms, organizational outcomes | Mechanisms |
Foorthuis et al. (2015) | 6 | 10 | EA approach, project compliance with EA, architectural insight, EA-induced capabilities, organizational performance, project performance | Architectural insight, EA-induced capabilities |
Lagerström et al. (2011) | 2 | 1 | EAM maturity, successful execution of IT | EAM maturity |
Lange (2012) | 6 | 6 | EAM product quality, EAM infrastructure quality, EAM service delivery quality, EAM use, EAM cultural aspects, EAM benefits | EAM product quality, EAM use |
Lange et al. (2016) | 6 | 6 | EAM product quality, EAM infrastructure quality, EAM service delivery quality, EAM organizational anchoring, intention to use EAM, EAM organisational and project benefits | EAM product quality, organizational anchoring, intention to use EAM |
Lux et al. (2010) | 9 | 7 | EAM-related human IT resources, EAM-related intangibles, EAM-related technological IT resources, other IS resources, EAM capability, other IS capabilities, (IT resource exploitation in) business processes, business process performance, organizational performance | EAM capability, other IS capabilities, (IT resource exploitation in) business processes |
Schmidt and Buxmann (2011) | 17 | 17 | IT compatibility, IT connectivity, EA communication and support, firm decentralization, documentation, duration of EAM implementation, EAM approach, IT efficiency, IT flexibility, EA governance, EA implementation, mergers and acquisitions, IT modularity, stakeholder participation, EA planning, EA programming, firm size | EAM approach |
Shanks et al. (2018) | 6 | 7 | EA service capability, EA governance, use of EA services in IT-driven change, use of EA services in business-driven change, project benefits, organizational benefits | Use of EA services in IT-driven change, use of EA services in business-driven change |
Tamm et al. (2011) | 6 | 8 | Enterprise architecture quality, organizational alignment, information availability, resource portfolio optimization, resource complementarity, organizational benefits | Organizational alignment, information availability, resource portfolio optimization, resource complementarity |
van Steenbergen and Brinkkemper (2008) | Numerous constructs | Numerous interrelationships | Enterprise architecture practice, architectural results, organizational performance, business goals, ultimate business goals (main categories) | Architectural results, organizational performance |
van der Raadt et al. (2010) | 26 | 32 | Attributes, consequences, values (main categories) | Consequences |
van der Raadt et al. (2007) | 10 | 23 | Governance, processes, communication, support, scope, resources, architecture awareness, architecture maturity, Architecture alignment, architecture effectiveness | Architecture awareness, architecture maturity, architecture alignment |
van Steenbergen et al. (2011) | 5 | 5 | Project conformance to EA, choices in EA explicitly linked to business goals, organized knowledge exchange between architects, EA in general a good instrument, economic sector | Project conformance to EA, choices in EA explicitly linked to business goals, organized knowledge exchange between architects, economic sector |
Weiss et al. (2013) | 10 | 9 | Social legitimacy, efficiency, organizational grounding, trust, governance, goal alignment, enforcement, response, EA consistency, benefits | Enforcement, response, EA consistency |
3 The Case Study
The organization is governed by a centralized group administration and has several fairly independent lines of business (LoBs). A multitude of development initiatives are constantly underway. In addition to EA, these are governed by typical governance processes such as portfolio management, project management, procurement, and IT governance. The organization utilizes EA to concretize strategic plans, set architectural guidelines for development initiatives, and to guide individual projects in conforming to EA |
The EA work is carried out by a semi-centralized EA team on several architectural levels: EA, reference architecture, LoB architecture, project architecture, and implementation architecture. The central EA team is responsible for EA, reference architecture, and LoB architecture, which are mainly used to set the direction for development at a high level. Project architecture and implementation architecture are defined in individual projects, and constitute a detailed view of the particular project and its dependencies to the overall EA. The organization uses an established EA framework and methodology. EA modeling is carried out with a proprietary EA modeling tool. EA models are extracted from the tool into documents for communication outside the architect community |
The organization had defined the EA framework, methodology, roles, and objectives seven years earlier. Architects and owners had been, for the most part, named for the EA viewpoints. While the architects in the central team were full time, most architects were actually not. As a consequence, the EA methodology and the role descriptions did not fully realize in practice. Even though the lack of resources was often highlighted as a major problem, the EA organization structure and methodology were also regarded as overly heavy. There were plans for streamlining and rationalizing the EA organization and methodology. EA was also considered somewhat separate from the other planning and governance methods. Especially on the project level, governance methods partly overlapped, as similar information was required from the projects in different formats, causing an extra burden |
Interviewee | Work role | Level | EA team |
---|---|---|---|
Architect A | Technical-functional architect | LoB | Central |
Architect B | Domain architect | EA | Central |
Specialist C | EA framework specialist | LoB | Central |
Specialist D | Lifecycle management specialist | LoB | Decentralized |
Project manager E | Project manager | Project | N.A. |
Line manager F | Line manager, specialist in projects | Project | Decentralized |
CIO G | Head of information systems | LoB | Decentralized |
Project manager H | Project manager | Project | N.A. |
Development manager I | Development manager | EA | Central |
Architect J | Technical architect | LoB | Central |
Program manager K | Program manager | Project | N.A. |
Project manager L | Project manager | Project | N.A. |
Architect M | Functional architect | LoB | Central |
Architect N | Architect | LoB | Central |
4 Findings from the Study
Construct | Definition | Attributes |
---|---|---|
EA Process Quality | Measures of EA processes, methodologies, tools, and organization | Clear EA scope and purpose |
Cohesion with other governance | ||
EA framework quality | ||
EA modeling conventions | ||
EA modeling tool quality | ||
EA process task timing | ||
Non-architecture source material quality | ||
Resource availability | ||
Stakeholder participation | ||
Support documentation quality | ||
EA Product Quality | Measures of EA products | Availability |
Clarity | ||
Cohesion and uniformity | ||
Correctness | ||
Granularity | ||
Usefulness | ||
EA Service Quality | Measures of EA services | Activeness |
Availability | ||
Competence | ||
Usefulness | ||
EA Results Use | Consumption of the output of EA processes (i.e., EA results) by EA stakeholders | Amount of use |
EA results used | ||
Motives of use | ||
Stakeholders | ||
Timing of use | ||
User satisfaction | ||
First-level Benefits | Effects of EA that arise directly from the EA processes | Allow project to proceed |
Identify dependencies | ||
Improve alignment | ||
Improve implemented solutions | ||
Improve project governance | ||
Improve project management | ||
Improve service management | ||
Increase understanding/new insight | ||
Provide answers quickly | ||
Provide common vocabulary | ||
Provide example | ||
Provide guiding framework | ||
Provide overview | ||
Provide standards | ||
Reduce duplication | ||
Reduce workload in EA work | ||
Second-level Benefits | Effects of EA that arise (depending on the situation) either directly from the EA processes or as a result of the First-level Benefits | Improve decision-making |
Increase interoperability between solutions | ||
Increase standardization in solution portfolio | ||
Identify requirements and restrictions | ||
Speed up project initialization | ||
Third-level Benefits | Effects of EA that arise as a result of the second-level benefits | Decrease IT costs |
EA Social Environment | Organizational factors external to the EA undertaking that have an effect on the EA benefit-realization process | Common approval and understanding of EA |
Top-management commitment | ||
Understanding of EA work in other organizations |
Codes | Quotes from the interviews |
---|---|
EA Process Quality (stakeholder participation) → Second-level Benefits (Identify requirements and restrictions) Second-level Benefits (Identify requirements and restrictions) → Third-level Benefits (decrease IT costs) | “…there was a large group of people doing the requirements analysis, we had even the architect at the time taking part and bringing issues he thought relevant for the program, there were a lot of requirements related to information security, for example … it is critical that the planning team is large enough … if [EA] has not been able to influence a project in the requirements analysis … there the larger problems arise … it is more expensive, if not impossible, to make changes later.” [Architect J] |
EA Process Quality (Support documentation quality) → EA Product Quality (Availability, Cohesion) EA Process Quality (Support documentation quality) → First-level Benefits (Provide guiding framework) | “Yes, [the guidelines] are for suppliers, they present the architecture and tell us what the views are that they need to produce … in an ideal situation, we get the [architectural] descriptions directly from the supplier and only need to copy them to the [EA modeling tool] … when we send out a request for a proposal, we add these guidelines as an attachment to specify what descriptions we require.” [Architect N] |
EA Product Quality (Granularity) → EA Results Use (EA results used, Motives of use, Stakeholders) EA Results Use (EA results used, Motives of use, Stakeholders) → First-level Benefits (Identify dependencies, Provide guiding framework), Second-level Benefits (Identify requirements and restrictions) | “[The program architecture description] did not bring a lot more than restrictions and a number of interfaces, and as a matter of fact, maybe some taxonomy things as well came from there. But because it was on a slightly different level than we really went in this program … that is why it merely gave a kind of framework for our work.” [Program Manager K] |
EA Results Use (EA results used) → First-level Benefits (Provide common vocabulary) First-level Benefits (Provide common vocabulary) → Second-level Benefits (Increase interoperability between solutions) | “I think it could be a vehicle for coherent and congruent communication, at its best. And through that, a tool for making sure that the interface that has been procured [between particular systems] fits there and works, in the end.” [Project Manager E] |