Enterprise Architecture Value Framework (EAVF) - Revision history

User at 15:28, 7 December 2022

2022-12-07T15:28:41Z

User at 15:24, 7 December 2022

2022-12-07T15:24:55Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T15:40:32Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 18:14, 5 December 2019

2019-12-05T18:14:34Z

User at 00:37, 5 December 2019

2019-12-05T00:37:17Z

User at 00:27, 5 December 2019

2019-12-05T00:27:33Z

User: EAVF is a framework to quantify the benefits of EA. EAVF uses the four perspectives of the Balanced Scorecard as a dimension in classifying EA benefits in line with the idea that the purpose of EA is to enable organisations to realize their business goals

2018-12-24T16:05:53Z

EAVF is a framework to quantify the benefits of EA. EAVF uses the four perspectives of the Balanced Scorecard as a dimension in classifying EA benefits in line with the idea that the purpose of EA is to enable organisations to realize their business goals

User: Created page with "'''Content Coming Soon'''"

2018-12-06T21:45:16Z

Created page with "'''Content Coming Soon'''"

New page

'''Content Coming Soon'''

@@ Line 2: / Line 2: @@
-EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases that may be discerned in the process from idea to delivered result: the development of the architectural artifacts (principles and models), the application of the architecture in projects and the resulting changes in business processes and systems. In these three phases, different stakeholders are involved who may benefit in different ways. During the development of the EA artifacts, benefits may occur because conversations take place between architects and decision-makers, and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the EA insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework, the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective, we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>
+EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases that may be discerned in the process from idea to delivered result: the development of the architectural artifacts (principles and models), the application of the architecture in projects, and the resulting changes in business processes and systems. In these three phases, different stakeholders are involved who may benefit in different ways. During the development of the EA artifacts, benefits may occur because conversations take place between architects and decision-makers, and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the EA insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework, the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective, we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>
 '''The Categories, Phases, and Dimensions of Enterprise Architecture Value Framework (EAVF) (See Figure 1.)'''<ref>The Categories, Phases, and Dimensions of Enterprise Architecture Value Framework (EAVF) [https://link.springer.com/chapter/10.1007%2F978-3-642-34163-2_5 Henk Plessius, Raymond Slot and Leo Pruijt]</ref><br />
-To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition, value can be a contribution to the profit of the organization, but also a growth in customer satisfaction or in the agility of the organization. It may even be a decrease in productivity (which, when the goal is to increase productivity, is an example where value is negative). There are only four categories or perspectives and to decision-makers in organizations. Hence, the value
+To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition, value can be a contribution to the profit of the organization, but also a growth in customer satisfaction or in the agility of the organization. It may even be a decrease in productivity (which, when the goal is to increase productivity, is an example where value is negative). There are only four categories or perspectives to decision-makers in organizations. Hence, the value
 measurements will be carried out with respect to the following four perspectives:
 *Financial: the financial perspective can be characterized as the shareholders' view of the organization. The keywords here are costs, risk, and compliance.
 *Customer: the customer perspective is the organization. Customer satisfaction and market share are generally important questions here.
-*Internal: the internal perspective is its managers and employees. The focus is normally on internal efficiency and productivity, but work satisfaction account as well.
+*Internal: the internal perspective is its managers and employees. The focus is normally on internal efficiency and productivity, but work satisfaction accounts as well.
 *Learning & growth view. The central question is the continuity of the organization in the long term. Typical keywords here are innovation and change.
-So, apart from being related to the goals of the organization, value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the model, which below are summarized and related to the familiar phases in the [[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]] of TOGAF9 as well:
+So, apart from being related to the goals of the organization, value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from the plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the model, which below are summarized and related to the familiar phases in the [[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]] of TOGAF9 as well:
-*Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture Vision, [[Business Architecture]], [[Information System Architecture|Information Systems Architectures]], and [[Information Technology Architecture|Technology Architecture]].
+*Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture Vision, [[Business Architecture]], [[Information Systems Architecture (ISA)]], and [[IT Architecture|Technology Architecture]].
-*Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases Opportunities and Solutions, Migration Planning and Implementation Governance.
+*Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases of Opportunities and Solutions, Migration Planning, and Implementation Governance.
 *Use: After the implementation, changes have been implemented in the organization and the time to collect the promised benefits has come. Monitoring the new architecture (Architecture Change Management in ADM) is a continuing activity in this phase.
-*Re-use: the Re-use phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus yield value.
+*Re-use: the Reuse phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus yield value.
-While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, portfolio managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase the architecture and change function should both be responsible.
+While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, portfolio managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase, the architecture and change functions should both be responsible.
-Since in the model the two dimensions (perspectives and phases) are mutually independent, they can be combined a framework: the Enterprise Architecture Value Framework (EAVF) as shown in figure 1.
+Since in the model the two dimensions (perspectives and phases) are mutually independent, they can be combined into a framework: the Enterprise Architecture Value Framework (EAVF) as shown in figure 1.
@@ Line 26: / Line 26: @@
-The primary strength of a complete framework is that it subdivides the value universe. For example, in the framework each cell is focused on a specific aspect and timeframe which makes it easier to identify where benefits and costs may originate and who are the stakeholders. The difficult question remains however if the changes in value are (at least partly) the result of the EA.
+The primary strength of a complete framework is that it subdivides the value universe. For example, in the framework, each cell is focused on a specific aspect and timeframe which makes it easier to identify where benefits and costs may originate and who are the stakeholders. The difficult question remains however if the changes in value are (at least partly) the result of the EA.
 ===See Also===
 *[[Enterprise Architecture Framework]]
 *[[Enterprise Architecture Management (EAM)]]
 *[[Federal Enterprise Architecture Framework (FEA)]]

@@ Line 1: / Line 1: @@
-'''Enterprise [[Architecture]] [[Value]] [[Framework]] (EAVF)''' is a framework to quantify the benefits of [[Enterprise Architecture]]. EAVF uses the four perspectives of the [[Balanced Scorecard]] as a dimension in classifying [[Enterprise_Architecture|EA]] benefits in line with the idea that the purpose of EA is to enable organisations to realize their [[business]] [[goals]] (Steenbergen and Brinkkemper, 2008) where the [[Balanced_Scorecard|Balanced Scorecard]] is commonly used for structuring business goals.<ref>[https://cioindex.com/cio-reference-library/enterprise-architecture/ Definition of Enterprise Architecture Value Framework (EAVF)]</ref>
+'''Enterprise Architecture Value Framework (EAVF)''' is a framework to quantify the benefits of [[Enterprise Architecture]]. EAVF uses the four perspectives of the [[Balanced Scorecard]] as a dimension in classifying EA benefits in line with the idea that the purpose of EA is to enable organizations to realize their business goals (Steenbergen and Brinkkemper, 2008) where the Balanced Scorecard is commonly used for structuring business goals.<ref>[https://cioindex.com/cio-reference-library/enterprise-architecture/ Definition of Enterprise Architecture Value Framework (EAVF)]</ref>
-EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases may be discerned in the [[process]] from idea to delivered result: the development of the architectural artefacts (principles and models), the [[application]] of the architecture in projects and the resulting changes in business processes and systems. In these three phases different stakeholders are involved who may benefit in different ways. During the development of the EA artefacts, benefits may occur because conversations take place between architects and decision-makers and experts about several aspects of the [[organization]], from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the [[Enterprise Architecture|EA]] insights enable better [[management]] of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the [[target]] architecture have been implemented, the organization should be able to reap benefits such as increased [[agility]], lower costs or greater operational [[efficiency]]. On the horizontal axis of the framework the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>
+EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases that may be discerned in the process from idea to delivered result: the development of the architectural artifacts (principles and models), the application of the architecture in projects and the resulting changes in business processes and systems. In these three phases, different stakeholders are involved who may benefit in different ways. During the development of the EA artifacts, benefits may occur because conversations take place between architects and decision-makers, and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the EA insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework, the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective, we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>
-'''The Categories, Phases and Dimensions of Enterprise Architecture Value Framework (EAVF) (See Figure 1.)'''<ref>The Categories, Phases and Dimensions of Enterprise Architecture Value Framework (EAVF) [https://link.springer.com/chapter/10.1007%2F978-3-642-34163-2_5 Henk Plessius, Raymond Slot and Leo Pruijt]</ref><br />
+'''The Categories, Phases, and Dimensions of Enterprise Architecture Value Framework (EAVF) (See Figure 1.)'''<ref>The Categories, Phases, and Dimensions of Enterprise Architecture Value Framework (EAVF) [https://link.springer.com/chapter/10.1007%2F978-3-642-34163-2_5 Henk Plessius, Raymond Slot and Leo Pruijt]</ref><br />
-To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition value can be a contribution to the [[profit]] of the [[Organization|organization]], but also a growth in [[Customer Satisfaction|customer satisfaction]] or in [[Enterprise Agility|agility of the organization]]. It may even be a decrease in [[Productivity|productivity]] (which, when the goal is to increase [[productivity]], is an example where value is negative). There are only four categories or perspectives and to decision makers in organizations. Hence, the value
+To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition, value can be a contribution to the profit of the organization, but also a growth in customer satisfaction or in the agility of the organization. It may even be a decrease in productivity (which, when the goal is to increase productivity, is an example where value is negative). There are only four categories or perspectives and to decision-makers in organizations. Hence, the value
-measurements will be carried out in respect to the following four perspectives:
+measurements will be carried out with respect to the following four perspectives:
-*Financial: the financial perspective can be characterized as the [[Shareholder|shareholders]] view on the organization. The keywords here costs, [[risk]] and [[compliance]].
+*Financial: the financial perspective can be characterized as the shareholders' view of the organization. The keywords here are costs, risk, and compliance.
-*[[Customer]]: the customer perspective is the organization. Customer satisfaction and [[market]] share are generally important questions here.
+*Customer: the customer perspective is the organization. Customer satisfaction and market share are generally important questions here.
 *Internal: the internal perspective is its managers and employees. The focus is normally on internal efficiency and productivity, but work satisfaction account as well.
-*Learning & growth view. The central question is the continuity of the organization in the long term. Typical keywords here are [[Innovation|innovation]] and change.
+*Learning & growth view. The central question is the continuity of the organization in the long term. Typical keywords here are innovation and change.
-So, apart from being related to the [[Business Goals|goals of the organization]], value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the [[model]], which below are summarized and related to the familiar phases in the [[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]] of [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF9]] as well:
+So, apart from being related to the goals of the organization, value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the model, which below are summarized and related to the familiar phases in the [[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]] of TOGAF9 as well:
-*Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture [[Vision]], [[Business Architecture]], [[Information System Architecture|Information Systems Architectures]] and [[Information Technology Architecture|Technology Architecture]].
+*Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture Vision, [[Business Architecture]], [[Information System Architecture|Information Systems Architectures]], and [[Information Technology Architecture|Technology Architecture]].
-*Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases Opportunities and Solutions, Migration Planning and Implementation [[Governance]].
+*Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases Opportunities and Solutions, Migration Planning and Implementation Governance.
-*Use: After the implementation, changes have been implemented in the organization and the time to collect the promised benefits has come. Monitoring the new architecture (Architecture [[Change Management]] in ADM) is a continuing activity in this phase.
+*Use: After the implementation, changes have been implemented in the organization and the time to collect the promised benefits has come. Monitoring the new architecture (Architecture Change Management in ADM) is a continuing activity in this phase.
-*Re-use: the Re-use phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus [[yield]] value.
+*Re-use: the Re-use phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus yield value.
-While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, [[portfolio]] managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase the architecture and change function should both be responsible.
+While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, portfolio managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase the architecture and change function should both be responsible.
 Since in the model the two dimensions (perspectives and phases) are mutually independent, they can be combined a framework: the Enterprise Architecture Value Framework (EAVF) as shown in figure 1.
@@ Line 30: / Line 30: @@
 ===See Also===
-[[Enterprise_Architecture|Enterprise Architecture]]<br />
+*[[Enterprise Architecture Framework]]
-[[Enterprise_Architecture_Framework|Enterprise Architecture Framework]]<br />
+*[[Enterprise Architecture Management (EAM)]]
-[[Enterprise_Architecture_Management_(EAM)|Enterprise Architecture Management (EAM)]]<br />
+*[[Federal Enterprise Architecture Framework (FEA)]]
-[[Federal_Enterprise_Architecture_Framework_(FEA)|Federal Enterprise Architecture Framework (FEA)]]<br />
+*[[Department of Defense Architecture Framework (DoDAF)]]
-[[Department_of_Defense_Architecture_Framework_(DoDAF)|Department of Defense Architecture Framework (DoDAF)]]<br />
+*[[Adaptive Enterprise Framework (AEF)]]
-[[The_Open_Group_Architecture_Framework (TOGAF)|The Open Group Architecture Framework (TOGAF)]]<br />
+*[[Technical Architecture Framework for Information Management (TAFIM)]]
-[[Adaptive_Enterprise_Framework_(AEF)|Adaptive Enterprise Framework (AEF)]]<br />
+*[[Zachman_Framework|Zachman Framework]]

@@ Line 1: / Line 1: @@
-'''Enterprise Architecture Value Framework (EAVF)''' is a framework to quantify the benefits of [[Enterprise Architecture]]. EAVF uses the four perspectives of the Balanced Scorecard as a dimension in classifying [[Enterprise_Architecture|EA]] benefits in line with the idea that the purpose of EA is to enable organisations to realize their business goals (Steenbergen and Brinkkemper, 2008) where the [[Balanced_Scorecard|Balanced Scorecard]] is commonly used for structuring business goals.<ref>[https://cioindex.com/cio-reference-library/enterprise-architecture/ Definition of Enterprise Architecture Value Framework (EAVF)]</ref>
+'''Enterprise [[Architecture]] [[Value]] [[Framework]] (EAVF)''' is a framework to quantify the benefits of [[Enterprise Architecture]]. EAVF uses the four perspectives of the [[Balanced Scorecard]] as a dimension in classifying [[Enterprise_Architecture|EA]] benefits in line with the idea that the purpose of EA is to enable organisations to realize their [[business]] [[goals]] (Steenbergen and Brinkkemper, 2008) where the [[Balanced_Scorecard|Balanced Scorecard]] is commonly used for structuring business goals.<ref>[https://cioindex.com/cio-reference-library/enterprise-architecture/ Definition of Enterprise Architecture Value Framework (EAVF)]</ref>
-EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases may be discerned in the process from idea to delivered result: the development of the architectural artefacts (principles and models), the application of the architecture in projects and the resulting changes in business processes and systems. In these three phases different stakeholders are involved who may benefit in different ways. During the development of the EA artefacts, benefits may occur because conversations take place between architects and decision-makers and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the [[Enterprise Architecture|EA]] insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>
+EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases may be discerned in the [[process]] from idea to delivered result: the development of the architectural artefacts (principles and models), the [[application]] of the architecture in projects and the resulting changes in business processes and systems. In these three phases different stakeholders are involved who may benefit in different ways. During the development of the EA artefacts, benefits may occur because conversations take place between architects and decision-makers and experts about several aspects of the [[organization]], from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the [[Enterprise Architecture|EA]] insights enable better [[management]] of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the [[target]] architecture have been implemented, the organization should be able to reap benefits such as increased [[agility]], lower costs or greater operational [[efficiency]]. On the horizontal axis of the framework the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>
 '''The Categories, Phases and Dimensions of Enterprise Architecture Value Framework (EAVF) (See Figure 1.)'''<ref>The Categories, Phases and Dimensions of Enterprise Architecture Value Framework (EAVF) [https://link.springer.com/chapter/10.1007%2F978-3-642-34163-2_5 Henk Plessius, Raymond Slot and Leo Pruijt]</ref><br />
-To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition value can be a contribution to the profit of the [[Organization|organization]], but also a growth in [[Customer Satisfaction|customer satisfaction]] or in [[Enterprise Agility|agility of the organization]]. It may even be a decrease in [[Productivity|productivity]] (which, when the goal is to increase productivity, is an example where value is negative). There are only four categories or perspectives and to decision makers in organizations. Hence, the value
+To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition value can be a contribution to the [[profit]] of the [[Organization|organization]], but also a growth in [[Customer Satisfaction|customer satisfaction]] or in [[Enterprise Agility|agility of the organization]]. It may even be a decrease in [[Productivity|productivity]] (which, when the goal is to increase [[productivity]], is an example where value is negative). There are only four categories or perspectives and to decision makers in organizations. Hence, the value
 measurements will be carried out in respect to the following four perspectives:
-*Financial: the financial perspective can be characterized as the [[Shareholder|shareholders]] view on the organization. The keywords here costs, risk and compliance.
+*Financial: the financial perspective can be characterized as the [[Shareholder|shareholders]] view on the organization. The keywords here costs, [[risk]] and [[compliance]].
-*[[Customer]]: the customer perspective is the organization. Customer satisfaction and market share are generally important questions here.
+*[[Customer]]: the customer perspective is the organization. Customer satisfaction and [[market]] share are generally important questions here.
 *Internal: the internal perspective is its managers and employees. The focus is normally on internal efficiency and productivity, but work satisfaction account as well.
 *Learning & growth view. The central question is the continuity of the organization in the long term. Typical keywords here are [[Innovation|innovation]] and change.
-So, apart from being related to the [[Business Goals|goals of the organization]], value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the model, which below are summarized and related to the familiar phases in the [[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]] of [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF9]] as well:
+So, apart from being related to the [[Business Goals|goals of the organization]], value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the [[model]], which below are summarized and related to the familiar phases in the [[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]] of [[The_Open_Group_Architecture_Framework (TOGAF)|TOGAF9]] as well:
-*Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture Vision, [[Business Architecture]], [[Information System Architecture|Information Systems Architectures]] and [[Information Technology Architecture|Technology Architecture]].
+*Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture [[Vision]], [[Business Architecture]], [[Information System Architecture|Information Systems Architectures]] and [[Information Technology Architecture|Technology Architecture]].
-*Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases Opportunities and Solutions, Migration Planning and Implementation Governance.
+*Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases Opportunities and Solutions, Migration Planning and Implementation [[Governance]].
-*Use: After the implementation, changes have been implemented in the organization and the time to collect the promised benefits has come. Monitoring the new architecture (Architecture Change Management in ADM) is a continuing activity in this phase.
+*Use: After the implementation, changes have been implemented in the organization and the time to collect the promised benefits has come. Monitoring the new architecture (Architecture [[Change Management]] in ADM) is a continuing activity in this phase.
-*Re-use: the Re-use phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus yield value.
+*Re-use: the Re-use phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus [[yield]] value.
-While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, portfolio managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase the architecture and change function should both be responsible.
+While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, [[portfolio]] managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase the architecture and change function should both be responsible.
 Since in the model the two dimensions (perspectives and phases) are mutually independent, they can be combined a framework: the Enterprise Architecture Value Framework (EAVF) as shown in figure 1.

← Older revision		Revision as of 18:14, 5 December 2019
Line 2:		Line 2:


−	EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases may be discerned in the process from idea to delivered result: the development of the architectural artefacts (principles and models), the application of the architecture in projects and the resulting changes in business processes and systems. In these three phases different stakeholders are involved who may benefit in different ways. During the development of the EA artefacts, benefits may occur because conversations take place between architects and decision-makers and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the [[Enterprise-Architecture\|EA]] insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)\|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>	+	EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases may be discerned in the process from idea to delivered result: the development of the architectural artefacts (principles and models), the application of the architecture in projects and the resulting changes in business processes and systems. In these three phases different stakeholders are involved who may benefit in different ways. During the development of the EA artefacts, benefits may occur because conversations take place between architects and decision-makers and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the [[Enterprise Architecture\|EA]] insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)\|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>

@@ Line 21: / Line 21: @@
 '''The Enterprise Architecture Value Framework with horizontal the four perspectives of the Balanced Scorecard and vertical the four phases where value may be created.'''<br />
 [[File:EAVF.png|300px|Phases and Dimensions of Enterprise Architecture Value Framework (EAVF)]]<br />
@@ Line 37: / Line 36: @@
 [[Department_of_Defense_Architecture_Framework_(DoDAF)|Department of Defense Architecture Framework (DoDAF)]]<br />
 [[The_Open_Group_Architecture_Framework (TOGAF)|The Open Group Architecture Framework (TOGAF)]]<br />
-[[Adaptive_Enterprise_Framework_(AEF)|Adaptive Enterprise Framework (AEF)]]
+[[Adaptive_Enterprise_Framework_(AEF)|Adaptive Enterprise Framework (AEF)]]<br />
-[[Technical_Architecture_Framework_for_Information_Management_(TAFIM)|Technical Architecture Framework for Information Management (TAFIM)]]<br />
+[[Technical Architecture Framework for Information-Management (TAFIM)]]<br />
 [[Zachman_Framework|Zachman Framework]]

← Older revision		Revision as of 16:05, 24 December 2018
Line 1:		Line 1:
−	'''~~Content Coming Soon~~'''	+	Enterprise Architecture Value Framework (EAVF) is a framework to quantify the benefits of Enterprise Architecture. EAVF uses the four perspectives of the Balanced Scorecard as a dimension in classifying [[Enterprise_Architecture\|EA]] benefits in line with the idea that the purpose of EA is to enable organisations to realize their business goals (Steenbergen and Brinkkemper, 2008) where the [[Balanced_Scorecard\|Balanced Scorecard]] is commonly used for structuring business goals.<ref>[https://cioindex.com/cio-reference-library/enterprise-architecture/ Definition of Enterprise Architecture Value Framework (EAVF)]</ref>
		+
		+
		+	EAVF adds a second dimension to account for EA benefits' evolution over time. EA lifecycle has three main phases may be discerned in the process from idea to delivered result: the development of the architectural artefacts (principles and models), the application of the architecture in projects and the resulting changes in business processes and systems. In these three phases different stakeholders are involved who may benefit in different ways. During the development of the EA artefacts, benefits may occur because conversations take place between architects and decision-makers and experts about several aspects of the organization, from a holistic perspective. This may create awareness and insights. When the EA prescriptions are applied in business projects, benefits may occur because the [[Enterprise-Architecture\|EA]] insights enable better management of projects: risks for instance can be assessed more precisely or timelines can be predicted better. Finally, when parts of the target architecture have been implemented, the organization should be able to reap benefits such as increased agility, lower costs or greater operational efficiency. On the horizontal axis of the framework the four perspectives of the Balance Scorecard as originally published by Kaplan & Norton (1992) are plotted, while on the vertical axis of the framework the three phases of EA from its development to its implementation and use of the results are shown. These perspectives and phases are discussed in more detail in an earlier paper (Plessius et al., 2012) in which the phases are coupled to [[The_Open_Group_Architecture_Framework (TOGAF)\|TOGAF]] (2011) as well1. With the mutually independent dimensions of time and goal perspective we have created a framework in which it should be possible to position every EA benefit reported. <ref>What is Enterprise Architecture Value Framework (EAVF)? [http://aisel.aisnet.org/mcis2014/23/ Aisel]</ref>
		+
		+
		+	'''The Categories, Phases and Dimensions of Enterprise Architecture Value Framework (EAVF) (See Figure 1.)'''<ref>The Categories, Phases and Dimensions of Enterprise Architecture Value Framework (EAVF) [https://link.springer.com/chapter/10.1007%2F978-3-642-34163-2_5 Henk Plessius, Raymond Slot and Leo Pruijt]</ref><br />
		+	To be able to measure value, an operational definition of value is adopted: “value is the contribution to the goals of the organization”. By this definition value can be a contribution to the profit of the organization, but also a growth in customer satisfaction or in agility of the organization. It may even be a decrease in productivity (which, when the goal is to increase productivity, is an example where value is negative). There are only four categories or perspectives and to decision makers in organizations. Hence, the value
		+	measurements will be carried out in respect to the following four perspectives:
		+	*Financial: the financial perspective can be characterized as the shareholders view on the organization. The keywords here costs), risk and compliance.
		+	*Customer: the customer perspective is the organization. Customer satisfaction and market share are generally important questions here.
		+	*Internal: the internal perspective is its managers and employees. The focus is normally on internal efficiency and productivity, but work satisfaction account as well.
		+	*Learning & growth view. The central question is the continuity of the organization in the long term. Typical keywords here are innovation and change.
		+	So, apart from being related to the goals of the organization, value evolves in time. This can take place during the development and implementation of EA in the operations (step 1) as well as after the operational changes are implemented (step 2). For the first step – towards the implementation of the EA – two logical phases can be discerned: the architecture development process, resulting in the target architecture, and the realization process aimed at implementing this target architecture. In the second step, when (parts of) the target architecture are implemented in operational processes and systems, we differentiate, based on reported benefits, between the value resulting from plain use of the results and the re-use of these results, as stimulated by the EA, in different environments. These considerations have resulted in four phases in the model, which below are summarized and related to the familiar phases in the [[Architecture_Development_Method_(ADM)\|Architecture Development Method (ADM)]] of [[The_Open_Group_Architecture_Framework (TOGAF)\|TOGAF9]] as well:
		+	*Development: in the development phase, the EA is developed and maintained. This phase corresponds with the ADM phases Architecture Vision, Business Architecture, Information Systems Architectures and Technology Architecture.
		+	*Realization: the realization phase is where programs are defined and projects are carried out to implement the changes defined in the EA. This phase corresponds with the ADM phases Opportunities and Solutions, Migration Planning and Implementation Governance.
		+	*Use: After the implementation, changes have been implemented in the organization and the time to collect the promised benefits has come. Monitoring the new architecture (Architecture Change Management in ADM) is a continuing activity in this phase.
		+	*Re-use: the Re-use phase is a seamless continuation of the Use phase and as such part of the phase Architecture Change management in ADM. However, after implementing parts of a new architecture, re-use of these parts may have a big influence on the next parts and thus yield value.
		+	While the second axis of our model is defined by time, it is loosely coupled with organizational responsibilities as well. In general, the architecture function in an organization is responsible for the development phase while for the realization phase the change function (program and project leaders, portfolio managers, etc.) has the responsibility. In the use phase, the operational function takes over the responsibility and for the re-use phase the architecture and change function should both be responsible.
		+	Since in the model the two dimensions (perspectives and phases) are mutually independent, they can be combined a framework: the Enterprise Architecture Value Framework (EAVF) as shown in figure 1.
		+
		+
		+	.
		+	'''The Enterprise Architecture Value Framework with horizontal the four perspectives of the Balanced Scorecard and vertical the four phases where value may be created.'''<br />
		+	[[File:EAVF.png\|300px\|Phases and Dimensions of Enterprise Architecture Value Framework (EAVF)]]<br />
		+	'''Figure 1. '''source: [https://www.hu.nl/~/media/sharepoint/Lectoraat%20Architectuur%20voor%20Digitale%20Informatiesystemen/2012/The%20EA%20value%20framework.pdf Hogeschool Utrecht, University of Applied Sciences]
		+
		+
		+	The primary strength of a complete framework is that it subdivides the value universe. For example, in the framework each cell is focused on a specific aspect and timeframe which makes it easier to identify where benefits and costs may originate and who are the stakeholders. The difficult question remains however if the changes in value are (at least partly) the result of the EA.
		+
		+
		+	===See Also===
		+	[[Enterprise_Architecture\|Enterprise Architecture]]<br />
		+	[[Enterprise_Architecture_Framework\|Enterprise Architecture Framework]]<br />
		+	[[Enterprise_Architecture_Management_(EAM)\|Enterprise Architecture Management (EAM)]]<br />
		+	[[Federal_Enterprise_Architecture_Framework_(FEA)\|Federal Enterprise Architecture Framework (FEA)]]<br />
		+	[[Department_of_Defense_Architecture_Framework_(DoDAF)\|Department of Defense Architecture Framework (DoDAF)]]<br />
		+	[[The_Open_Group_Architecture_Framework (TOGAF)\|The Open Group Architecture Framework (TOGAF)]]<br />
		+	[[Adaptive_Enterprise_Framework_(AEF)\|Adaptive Enterprise Framework (AEF)]]
		+	[[Technical_Architecture_Framework_for_Information_Management_(TAFIM)\|Technical Architecture Framework for Information Management (TAFIM)]]<br />
		+	[[Zachman_Framework\|Zachman Framework]]
		+
		+
		+
		+	===References===
		+	<references/>
		+
		+
		+	===Further Reading===
		+	*Perceived Benefits from Enterprise Architecture [http://www.dya.info/sites/dya.info/files/attachments/mcis2014_submission_benefits%20of%20EA.pdf Plessius, Henk. Steenbergen, Marlies van. Slot, Raymond.]
		+	*On the Categorization and Measurability of Enterprise Architecture Benefits with the Enterprise Architecture Value Framework [https://link.springer.com/chapter/10.1007%2F978-3-642-34163-2_5 H Plessius]
		+	*Two IT gurus face off on value of enterprise architecture frameworks [https://searchcio.techtarget.com/blog/TotalCIO/Two-IT-gurus-face-off-on-value-of-enterprise-architecture-frameworks Techtarget]