Enterprise architecture as a business strategy
Lecture 1
Strategic alignment model
About the alignment between strategy and processes. The link between enterprise
architecture and information management.
• External domain: the business area in which the firm competes
• Internal domain: the organization itself
The Hevner et al. article describes design research. They distinguish between two types of
research. They use the strategic alignment model to
determine that the IM discipline is not only about
aligning IT and business, but also about designing
organizational processes and infrastructure given a
strategy. If you have a business strategy, for instance if
you want to sell services to people for a good price,
then you have to find out which organizational
structure fits that strategy.
What is enterprise architecture?
Architecture is making things clear. Enterprise architecture is about describing and specifying
coherence between models. We assume that everybody within a company can create/is
concerned with the architecture. Enterprise architecture is everything concerned with
managing the complexity of all the applications within an organization.
Key components of enterprise architecture
• As-is: describes how processes/organizations/data/etc. look now. The current state
assessment of the organization.
• To-be: what it should look like. The future state and, generally, the main focus of an
enterprise architecture assignment.
• Migration plan: route from as-is to to-be. Without a viable route from as-is to to-be
the architecture has already failed.
1
, • Principles: guidelines for users of the architecture. For instance, do we buy or build
our systems?
• Decision log: what decisions do you take on principles, migration plan, as-is and to-be
when starting to create an enterprise architecture. Started during the development
of the enterprise architecture but a key part of the ‘living’ architecture.
Generic framework dimensions
This actually is the strategic alignment model.
• Strategy layer: provides the context. “Why?”
• Architecture layer: define the business models, which data is crucial, which systems
and applications provide the information and which technology do we need to have
to run the application portfolio. Provides the conceptual and logical solution to
deliver the strategy. “What?”
• Design layer: how does the organizational structure and processes actually look like,
how do the databases, software and infrastructure look like. Provides the physical
solution. “How?”
• Operations: run the processes, use the data, use the applications and deploy the
infrastructure services
Only if you can translate strategy into physical operation, then you become successful.
Definitions of enterprise architecture
• As a discipline: enterprise architecture is a discipline for systematic understanding,
planning, aligning and enabling relationships among strategy, business capabilities,
information and technology.
• As a set of deliverables: enterprise architecture document directions and standards
on how the organization should be designed and transformed to achieve a desired
outcome. These deliverables are then used to govern enterprise transformation.
• As a depiction: enterprise architecture is a set of integrated models at appropriate
levels of abstractions that represent the current and/or future functioning of the
organization.
• As a management practice: making decision that fit the to-be situation. EAM
established, maintains and used a coherent set of guidelines, architecture principles
and governance regimes that provide direction for and practical help with the design
and the development of an enterprise’s architecture in order to achieve its vision and
strategy.
Why enterprise architecture?
In the figure below: There is a problem, the requirements are specified and that results in a
project proposal. If the proposal is okay, then it becomes part of the IT project portfolio and
then you have an IS application portfolio.
2
,What value can enterprise architecture bring?
• Clarifying the relationship between business and IT
• Cost avoidance and reduction by leveraging existing investment and reducing
duplication and waste
• Shortened development and deployment time reducing time to market
• Reduced support and maintenance costs, including learning and support staff
• Some intangible things – such as common principles between business and IT; open
discussion of issues; common language; technology inventory
Design debt
Technical debt (also known as design debt or code debt) is "a concept in programming that
reflects the extra development work that arises when code that is easy to implement in the
short run is used instead of applying the best overall solution".
The architectural debt that is accumulated by applying a quick fix without proper refactoring.
The theory being that a system’s complexity increases non linearly each time a quick fix is
applied.
Zachman Framework
This total framework can be used to describe the enterprise architecture. There is not only
one right answer for the framework. In all the different cells you put a definition and the
definitions become more detailed when other actors become involved. It addresses the
enterprise as a whole, distinguishing ‘enterprise management’ and ‘development of
enterprise systems’. You have to combine several aspects in order to be able specify the
architecture.
In Appendix C a summary of the article can be found!
The original framework describes:
• What the architecture is in terms of data. What material is it made of?
• How the organization/process works
• Where it operates. Where the components are with respect to each other.
• Who work with it. Who does what.
• When do things happen
• And why are choices made
… for five roles in the design process.
3
, Rules of the Zachman framework
Roger Session took another look at the framework in 2008.
• Columns have no order
• Each column has a simple, basic model
• The basic model of a column must be unique
• Each row represents a distinct unique perspective
• Each cell is unique
• The total of all cells in one row is a complete model for that actor
• The framework logic can be used to describe any creation/building
Limitations of the Zachman framework
• Each artifact ‘lives’ in one cell
• A complete architecture requires every cell to be populated
• Cells in columns & rows should be associated
From Zachman to Archimate
An illustration of how ‘vague’ it is. Archimate is a modeling technique. It remains the
business, application and technology layers and the what, how and who columns.
Lecture 2
Picture approach
4
Lecture 1
Strategic alignment model
About the alignment between strategy and processes. The link between enterprise
architecture and information management.
• External domain: the business area in which the firm competes
• Internal domain: the organization itself
The Hevner et al. article describes design research. They distinguish between two types of
research. They use the strategic alignment model to
determine that the IM discipline is not only about
aligning IT and business, but also about designing
organizational processes and infrastructure given a
strategy. If you have a business strategy, for instance if
you want to sell services to people for a good price,
then you have to find out which organizational
structure fits that strategy.
What is enterprise architecture?
Architecture is making things clear. Enterprise architecture is about describing and specifying
coherence between models. We assume that everybody within a company can create/is
concerned with the architecture. Enterprise architecture is everything concerned with
managing the complexity of all the applications within an organization.
Key components of enterprise architecture
• As-is: describes how processes/organizations/data/etc. look now. The current state
assessment of the organization.
• To-be: what it should look like. The future state and, generally, the main focus of an
enterprise architecture assignment.
• Migration plan: route from as-is to to-be. Without a viable route from as-is to to-be
the architecture has already failed.
1
, • Principles: guidelines for users of the architecture. For instance, do we buy or build
our systems?
• Decision log: what decisions do you take on principles, migration plan, as-is and to-be
when starting to create an enterprise architecture. Started during the development
of the enterprise architecture but a key part of the ‘living’ architecture.
Generic framework dimensions
This actually is the strategic alignment model.
• Strategy layer: provides the context. “Why?”
• Architecture layer: define the business models, which data is crucial, which systems
and applications provide the information and which technology do we need to have
to run the application portfolio. Provides the conceptual and logical solution to
deliver the strategy. “What?”
• Design layer: how does the organizational structure and processes actually look like,
how do the databases, software and infrastructure look like. Provides the physical
solution. “How?”
• Operations: run the processes, use the data, use the applications and deploy the
infrastructure services
Only if you can translate strategy into physical operation, then you become successful.
Definitions of enterprise architecture
• As a discipline: enterprise architecture is a discipline for systematic understanding,
planning, aligning and enabling relationships among strategy, business capabilities,
information and technology.
• As a set of deliverables: enterprise architecture document directions and standards
on how the organization should be designed and transformed to achieve a desired
outcome. These deliverables are then used to govern enterprise transformation.
• As a depiction: enterprise architecture is a set of integrated models at appropriate
levels of abstractions that represent the current and/or future functioning of the
organization.
• As a management practice: making decision that fit the to-be situation. EAM
established, maintains and used a coherent set of guidelines, architecture principles
and governance regimes that provide direction for and practical help with the design
and the development of an enterprise’s architecture in order to achieve its vision and
strategy.
Why enterprise architecture?
In the figure below: There is a problem, the requirements are specified and that results in a
project proposal. If the proposal is okay, then it becomes part of the IT project portfolio and
then you have an IS application portfolio.
2
,What value can enterprise architecture bring?
• Clarifying the relationship between business and IT
• Cost avoidance and reduction by leveraging existing investment and reducing
duplication and waste
• Shortened development and deployment time reducing time to market
• Reduced support and maintenance costs, including learning and support staff
• Some intangible things – such as common principles between business and IT; open
discussion of issues; common language; technology inventory
Design debt
Technical debt (also known as design debt or code debt) is "a concept in programming that
reflects the extra development work that arises when code that is easy to implement in the
short run is used instead of applying the best overall solution".
The architectural debt that is accumulated by applying a quick fix without proper refactoring.
The theory being that a system’s complexity increases non linearly each time a quick fix is
applied.
Zachman Framework
This total framework can be used to describe the enterprise architecture. There is not only
one right answer for the framework. In all the different cells you put a definition and the
definitions become more detailed when other actors become involved. It addresses the
enterprise as a whole, distinguishing ‘enterprise management’ and ‘development of
enterprise systems’. You have to combine several aspects in order to be able specify the
architecture.
In Appendix C a summary of the article can be found!
The original framework describes:
• What the architecture is in terms of data. What material is it made of?
• How the organization/process works
• Where it operates. Where the components are with respect to each other.
• Who work with it. Who does what.
• When do things happen
• And why are choices made
… for five roles in the design process.
3
, Rules of the Zachman framework
Roger Session took another look at the framework in 2008.
• Columns have no order
• Each column has a simple, basic model
• The basic model of a column must be unique
• Each row represents a distinct unique perspective
• Each cell is unique
• The total of all cells in one row is a complete model for that actor
• The framework logic can be used to describe any creation/building
Limitations of the Zachman framework
• Each artifact ‘lives’ in one cell
• A complete architecture requires every cell to be populated
• Cells in columns & rows should be associated
From Zachman to Archimate
An illustration of how ‘vague’ it is. Archimate is a modeling technique. It remains the
business, application and technology layers and the what, how and who columns.
Lecture 2
Picture approach
4
