Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Enterprise Architecture > Week 3: EA as a method > Flashcards

Week 3: EA as a method Flashcards

1
Q

The Open Group Architecture Framework (TOGAF)

A

A method to develop and manage the enterprise architecture. It is composed of multiple techniques and best practices. TOGAF advises to use Archimate as the EA toolset.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Drivers for EA as addressed by the picture approach

A
  • Problem situation:
    + IS portfolio is complex (mostly after merger or acquisition).
    + Decentralized IS budgets
    + Low flexibility of IS & failing IS and business projects.
  • Challenge:
    + How to redesign the IS portfolio
    + How to reduce IS complexity
    + Diversity of IS models
    + Stakeholder are enemies
  • Solution: Picture approach
    + Process: pressure-cooker model, shared meaning.
    + Products: picture, fact sheets
    + Decision: multi-criteria analysis, analytical hierarchy planning.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Picture approach

A
  • Approves, redesigns and combines system complexes (application portfolios).
  • Improves business IT alignment in organizations.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Focus of picture approach

A

The application portfolio (IS architecture) plus relations to:

  • Process architecture
  • Information architecture
  • Organization architecture
  • IT architecture
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Picture

A

A picture is an image of the organizational processes. This image maps out the functions of various IS applications in the processes. The fact sheets specify data and technologies.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Steps of the picture approach

A
  1. Several photo-shoots -> core process applications, documents and actors.
  2. Review of the photos (models) by the management team.
  3. Detailing the photos (models), adding fact sheets that define the following:
    - Sustainability of the current and possible architectures.
    - Functionality per application.
    - Process support -> degree to which systems support the processes.
    - Costs and benefits per application.
    - Risks per application and total risk.
  4. Freezing the photos (models) of the as-is and (some) to-be situations.
  5. Choosing the target EA (the to-be EA) using multi criteria decision analysis (analytical hierarchy planning).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Questions to support making a picture (PwC)

A

Questions regarding:
- Data and information
- Organization and processes
- Application and processes
Two main questions:
1. How many to-be pictures/architectures do you need?
2. How to choose the right to-be architecture?
+ can be done by using the Analytical Hierarchy Planning (AHP)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Tools to reduce EA complexity

A
  1. Mapping applications to business processes.

2. Quality of the applications portfolio

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Mapping applications to business processes

A

Supports analysis of application portfolio:
- Which applications and how many are used per business process?
- Which applications are used by multiple business processes.
- Which business processes use (similar) applications (possible redundancy of applications)
To support management decisions on:
- Which applications may be phased out
- Which applications may be merged
- Prioritization of applications.
This leads to a project portfolio, and in the end changing the application portfolio.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Quality of the applications portfolio

A

Supports the analysis of the application portfolio:
- Technical quality
- Functional quality
- Costs
Then, decisions can be made on (e.g.):
- Which applications to improve technically.
- Which applications to improve functionally.
- Efficiency/Cost measures.
- Which applications to replace.
This leads to a project portfolio, and in the end changing the application portfolio.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

3 EA approaches

A
  • Zachman approach: focus on the right models.
  • Picture approach: focus on the right modelling process.
  • Practical approach: use the two models for IS application portfolio management.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Function point

A

A unit of measurement to express the amount of business functionality of an IS to a user. Used to compute a functional size measurement (FSM) of software.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Rules of thumb function points

A
  • One function point requires on average 100 lines of code.

- 10.000 function points require 1 million lines of programming.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Objective complexity

A

What you can see:

  • # Components (applications)
  • # Interfaces
  • # Functions (function point analysis)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

How to reduce objective complexity?

A
  • Reduce the # components per system and portfolio.
  • Reduce the # interfaces (relationships) between systems
  • Reduce the # functions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Subjective complexity

A

What you perceive as complex.
- The effort that is required to:
+ understand
+ cope with the portfolio

17
Q

How to reduce subjective complexity?

A
  • Reduce the effort to understand the portfolio -> can be done visualizing main parts and relations from managerial + IT perspective.
  • Support decision making using AHP, distinguishing criteria, weights and objectives.
18
Q

Roger Sessions says

A

There is too high complexity in relationships between organizational units and information systems.
- Anybody can create a complex architecture, takes no skill at all.
- Architecture naturally seek the maximum possible level of complexity all on their own .
- It is a complex architecture you want, then you don’t even need architects. You might as well just fire them and let the developers work on their own.
It is simple to make systems complex, it is complex to make systems simple.

19
Q

Internal drivers for enterprise architecture

A
  • Audit
  • Specify management information
  • Manage IT system portfolio
  • Manage (out)sourcing relationships
  • Guide systems development
  • Preparing a merger or acquisition
  • Reducing complexity
    Depending on the drive the value can be determined.
20
Q

Design debt

A

As long as you do projects that are matching the enterprise architecture standard, you’re not adding up to your design debt. Quick fixes to ‘match’ the EA add up to the design debt. Enterprise architecture to reduce design debt.

21
Q

Architectural debt

A

Accumulated by applying a quick fix without proper refactoring.

  • The debt accumulates interest over time - increasing the total cost (effort) requiring to repay the debt.
  • The theory being that a system’s complexity increases non-linearly each time a quick fix is applied.
22
Q

Design debt checklist

A

Tale-tale signs to spot it:
- No visible architectural champion.
- Lack of balance between business and IT department.
- No decommissioning strategy.
- Duplicate systems.
Why is it important?
- Geological time scales requires to make simple business changes.
- Lack of confidence that a change will actually work in production.
- Projects over-burn budget and schedule.
- IT costs to keep the lights on erode business margins.
- Clean slate ‘make or break’ programmes required to stay in business.
- Brand erosion.

23
Q

Five core components of EA

A
  • As-is: the current state of the organization
  • To-be: the future state and generally the main focus of an EA assistant.
  • Migration plan: without a viable route from as-is to to-be, the architecture has already failed.
  • Principles: the guidelines for users of the architecture, such as ‘buy not build’ or ‘adherence to published data standards’.
  • Decision log: started during the development of the EA but a key part of the ‘living’ architecture.
24
Q

Architecture principles

A

Principles are statements of intent or purpose that:
- Support business needs and changing customer desires.
- Guide business and IT decisions and investments.
+ Principles have a rationale: why are we (not) doing this.
+ Principles have an implication: we can no longer..
- Are the foundation for business strategy and architecture.
- Reflect the vision to support the dynamic and rapidly changing marketplace.
- Reflect the vision of improved IT usage.
- Describe preferred practices for new upgraded systems.
Principles are guidelines for the construction of a (business and technical) architecture through to the physical implementation.
- They underpin our investigations when we look at architectural options.
- They are used to justify the decisions we make about the components in the architecture.
- They ensure that the architecture we define is consistent and we do not wander from our path to the goal.

25
Q

Two types of guiding principles.

A
  1. Commandments: principles which are unlikely to disagree with. May simply not be relevant to the situation.
  2. Spectrum: each side of the principle is an opposite belief. Each extreme is a good guiding principle, but not for the same organization.
26
Q

EA Commandments

A
  • Enterprise priorities
  • Strategic systems per domain
  • Domain roadmap
  • Business objectives driven
27
Q

Enterprise priorities

A
  • All projects and investments shall be based upon the organizations priorities.
  • Where a conflict arises, the resolution should be preferential towards the enterprise view as opposed to the local business/project view.
28
Q

Strategic Systems per domain

A
  • The organizations applications are categorized into functional domains that cover areas such as channels, business functionality and analytics.
  • Each domain will be fully supported by a rationalized set of 1 or more strategic systems.
  • Deviation from use of strategic applications within a domain will require a clear business case that accounts for the costs of maintaining expertise in, and connectivity between additional processing environments and service providers.
29
Q

Domain roadmap

A
  • Each domain will have a roadmap maintained that maps the strategic priorities to migration steps.
  • Flexibility to support these business requirements priorities in the domain roadmap shall be considered alongside the specific project requirements during initial scoping of a project.
30
Q

Business objectives driven

A

Ensure IT investments are directly.

Enterprise Architecture (9 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions