2. TOGAF is an architecture framework that provides
the methods and tools for assisting in the
acceptance, production, use, and maintenance of an
enterprise architecture. It is based on an iterative
process model supported by best practices and a
reusable set of existing architecture assets.
3. The Business Architecture defines the business
strategy, governance, organization, and key
business processes.
The Application Architecture provides a blueprint
for the individual applications to be deployed, their
interactions and their relationships to the core
business processes of the organization.
4. The Data Architecture describes the structure of
an organization’s logical and physical data assets
and data management resources.
The Technology Architecture describes the logical
software and hardware capabilities that are required
to support the deployment of business, data, and
application services. This includes IT infrastructure,
middleware, networks, communications, processing,
standards, etc.
5.
6. Preliminary Phase
describes the preparation
and initiation activities required
to create an Architecture
Capability including
customization of TOGAF and
definition of Architecture
Principles.
Preliminary
7. Architecture Vision
describes the initial phase
of an architecture development
cycle. It includes information
about defining the scope of
the architecture development
initiative, identifying the
stakeholders, creating the
Architecture Vision, and
obtaining approval to proceed
with the architecture
development.
Architecture
Vision
11. Opportunities & Solutions
conducts initial
implementation planning and
the identification of delivery
vehicles for the architecture
defined in the previous
phases.
Opportunities
And
Solutions
12. Migration Planning
addresses how to move
from the Baseline to the
Target Architectures by
finalizing a detailed
Implementation and Migration
Plan. Migration
Planning
16. Deliverables a contractually specified work product.
Artifacts a more granular architectural work product
describing an architecture from a specific viewpoint.
Building blocks representing a (potentially reusable)
component of business, IT, or architectural capability.
Architecture Building Blocks (ABBs) describe required
capability.
Solution Building Blocks (SBBs) represent components
that will be used to implement the required capability.
17.
18.
19.
20. According to TOGAF, architecture principles define
“the underlying general rules and guidelines for the use
and deployment of all IT resources and assets across the
enterprise”
(TOGAF http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html)
21. Principles governing the architecture process, affecting:
development
maintenance
use
of enterprise architecture
Principles governing the implementation of the architecture,
establishing:
first tenets
related guidance
for designing and developing information systems
22. Name: Should both represent the essence of the rule as well as be
easy to remember.
Statement: Should succinctly and unambiguously communicate the
fundamental rule.
„Rationale: Should highlight the business benefits of adhering to the
principle, using business terminology.
Implications: Should highlight the requirements, both for the business
and IT, for carrying out the principle - in terms of resources, costs,
and activities/tasks.
Name
Statement
Rationale
Implications
Schema:
23. Don’t mention specific technology platforms in the Name
or Statement of a principle.
Avoid ambiguous words in the Name and in the
Statement such as: "support", "open", "consider", and
for lack of good measure the word "avoid", itself.
Be careful with "manage(ment)”.
Look for and avoid unnecessary adjectives and adverbs
(fluff).
24. Point to similarity of information and technology principles.
Point to principles governing business operations.
Describe relationship to other principles and the intentions
regarding a balanced interpretation.
Describe situations where one principle would be given
precedence or carry more weight than another for making
a decision.
25. Name Interoperability
Statement All the software in university (already existed and new developed)
should conform the same standards either in technologies or
interface.
Rationale Keeping existed software standards let spend minimum time and
costs for development.
Hardware and data standards prevent reiterative appeals or
applications for explaining usage or operations.
In the general will improve satisfaction of users and clients.
Implications Interoperability standards will be followed unless client (university)
would like completely change an inner software or hardware
environment. All the hardware should exist in minimum variety of
kinds. Investigate data formats, as the transcribed data should
arouse minimal amount of problems by opening in any kind of
software environment.
27. Propose at least six architecture principles, concerning
example from the previous exercise.
Reminder: Your organization requests you to conceptualize and
implement a new social system oriented both on academicians and
students, their parents for a National Ministry of Science and
Education. End-consumer is your home university.
30. Defining "where, what, why, who, and how to do
architecture"
Main aspects
o Defining the enterprise
o Identifying key drivers and elements
o Defining the requirements for architecture work
o Defining the architecture principles
o Defining the framework to be used
o Defining the relationships between management
frameworks
o Evaluating the enterprise architecture maturity
31. Defining "where, what, why, who, and how to do
architecture"
Main aspects
o Defining the enterprise
o Identifying key drivers and elements
o Defining the requirements for architecture work
o Defining the architecture principles
o Defining the framework to be used
o Defining the relationships between management
frameworks
o Evaluating the enterprise architecture maturity
32. Overview about the client’s organisation / enterprise
Identify stakeholders
o Actors like university management bodies, department
operators, university platform, student services
Identify scope and elements of the organization
o Departments, faculties, etc.
o Student domains
o Educational, academic processes
o Key information in the context
o Responsibilities, Liabilities, Legal conditions, Cultures
o Technical features
33. Define a framework and detailed methodology
o TOGAF and the Architecture Development Method
Confirm a support framework that will provide detailed
notations and/or languages to develop models
o ADONIS, Visio
Define architecture principles
Examples
Interoperability
Full electronic support
Cross-organizational
Management interactions
Legal compliance
Usability
Convenience
Simplification
Harmonisation
34. Preliminary and also Architecture Vision phase are used to
gather as much information about the enterprise and the
enterprise’s domain
Research methods offer different ways to collect data from
stakeholder
o Desk research
o Questionnaires
o Interviews
o Observation
o Think-alouds
o Workshop & participation
techniques
o Scenario technique
o Mock-ups
o Soft Systems Method
Preliminary phase is used to prepare the usage of Enterprise
Architecture
35. Gather knowledge about:
o TOGAF
o Other frameworks if
required
o Board and Business
strategy
o Business goals
o Business drivers
o Budget for scoping project
o Partnership for scoping
project
o IT strategy
Pre-existing organisation models, architecture frameworks
and principles
Pre-existing architecture repository
36. Organisational Model covering:
o Scope of organisations impacted
o Maturity assessment, gaps, and resolution approach
o Roles and responsibilities for architecture team
o Constraints on architecture work
o Re-use/Budget requirements
o Request for changes
o Governance and support strategy
37. Customised Architecture Framework containing
o Tailored architecture method and content
o Architecture principles
o Chosen tools
Initial Architecture Repository
Information on business principles, goals and drivers
Request for architecture work
38. Scope the Enterprise Organizations impacted
Define and establish Enterprise Architecture Team and
Organization
Identify and establish Architecture Principles
Select and tailor Architecture Frameworks
39. Identify units involved in Architecture Work:
• core enterprise - those units most affected from the
work
o E.g. dean office
• soft enterprise - those units who will see changes but
are otherwise not directly affected
o E.g. student government department
• extended enterprise - those units outside the scoped
enterprise affected in their own enterprise architecture
Identify enterprises involved in Architecture Work:
• communities involved - those stakeholders affected and
organized in groups
• governance involved
40. Determine existing enterprise and business capability
Identify gaps in existing work areas
Allocate key roles and responsibilities for enterprise
architecture
Define requests for change to existing business programs
and projects:
o Inform existing enterprise architecture and IT architecture
work of stakeholder requirements
o Request assessment of impact on their plans and work
o Identify common areas of interest
o Identify any critical differences and conflicts of interest
o Produce requests for change to stakeholder activities
41. Scope new enterprise architecture work
Determine constraints on enterprise architecture work
Review and agree with sponsors and board
Assess budget requirements
42. Identifying of Architecture Principles because:
Architecture principles
• define
o underlying general rules and
o guidelines
for the use and deployment of all IT resources
• Are the background for making future IT decisions
form the basis for all decisions in Architecture Vision,
Business Architecture, Information Systems and Technology
Architecture Phase
43. TOGAF provides an abstract framework that can be
tailored or enhanced for every kind of enterprise
The Open Group pointed out three aspects to tailor:
• Terminology
o Architecture practitioners should use terminology that is
generally understood
• Process
o Provides the opportunity to remove, add and change
tasks of the ADM
• Content
o Allows adoption of third-party content frameworks
o Allows customization of the framework to support
organization-specific requirements
44. Modelling notations for different levels of abstraction and for
specific aspects
Organisational modelling
o Organisational diagram
(MS Visio®)
o Work environment diagram
(ADONIS®)
45. Represent the structure of an organisation, the distribution
of work and hence the responsibilities
Useful for work assignments and for access rights
o Understanding of business domains and organisational
units involved
o Workflow management systems
o Coordinating the assignment and workload to personnel
and the need for respective systems applications for
their work
o Access control at systems level
46. In general they describe the overall structure of an
organization and further on the human actors involved in a
process
Approach: Organisational diagrams describing
• The individual organisational units and the relationship
among different such units
o Including hierarchical relations such as Headquarter
-> Business domain -> Department -> Group -
> Position
o Concept of decomposition
• Smallest unit in organisational diagrams is position
49. Propose a scheme of the Enterprise Architecture Team
and University within the task presented in the previous
exercise (during past lecture).
Reminder: Your organization requests you to conceptualize and
implement a new social system oriented both on academicians and
students, their parents for a National Ministry of Science and
Education. End-consumer is your home university.
54. Initial phase of the Architecture
Design Method Includes information about
o defining the scope
o identifying the stakeholders
o creating the Architecture Vision
o and obtaining approvals
55. Ensure recognition, endorsement and support from
the corporate management of the enterprise.
Define and organize an architecture development
cycle.
Validate the business principles, business goals,
etc.
Define the scope of, and identify and prioritize the
components of the Baseline Architecture effort.
56. Define the relevant stakeholders and their concerns
and objectives.
Define the key business requirements and
constraints.
Articulate an Architecture Vision and formalize the
value proposition.
Create a comprehensive plan that addresses
scheduling, resourcing, financing, communication,
risks, constraints, assumptions, and dependencies.
Secure formal approval to proceed.
57. Develop Architecture Vision (high level)
• Confirm with administration on actual baseline and future
target architecture
o remember scenario introduction current state and target
solution
Identify concerns and requirements
• Using e.g. interviews to gather expectations and needs
of potential users of the new eUniversity platform
o e.g. no media breaks / full online documents circulation
• Using interviews or mind mapping sessions to elaborate
university goals, drivers and constraints
o budgets etc.
Gain rector’s sign off to proceed!
58. Output of Preliminary phase
Request of Architecture Work
Business Principles
Business Goals
Business drivers
59. Approved Statement of Architecture Work
Agreed statements of Business Principles, Business Goals
and Business drivers
Architecture Principles
Architecture Vision, including
• Agreed key high-level stakeholder requirements
• Baseline and high-level Target Business Architecture
• Baseline and high-level Target Technology Architecture
• Baseline and high-level Target Data Architecture
• Baseline and high-level Target Application Architecture
60. Identify stakeholders, concerns and business
requirements
Confirm and elaborate business goals, business
drivers and constraints
Define scope
Confirm and elaborate Architecture and Business
Principles
Develop Architecture Vision
61. Concerns and requirements as basis for
formulating a target Architecture Vision
Concerns and requirements to be summarized
and discussed with the contractor
Background about how architecture is presented
and communicated needs to be defined
62. Major product: stakeholder map showing
• Stakeholders
• How they are involved
• Relevant views and viewpoints
Template for Stakeholder involvement “map”
Stakeholder Involvement
description
Kind of
involvement
Relevant Viewpoints
63. Stakeholder Involvement
description
Kind of
involvement
Relevant Viewpoints
University
administrati
on
Supervise the process of
advancement and
transparency of the
work of academics and
they own, enhancement
of IT architecture. Get
other departments
involved in the project.
KEEP SATISFIED Rich/Goal/Objective/Ser
vice Models, Information
map
Academic
Staff
Express their demands,
test a system (as it’s
ready).
KEEP SATISFIED
/ KEEP
INFORMED /
INVOLVE in
TESTS
Rich/Objective Models,
User interfaces
64. Stakeholder Involvement
description
Kind of
involvement
Relevant Viewpoints
Human
Resources
Control vision of roles
and actors. Re-form or
create a new Processing
office.
KEEP
INFORMED /
INVOLVE in
NEW ACTOR
CREATION
Actor Location,
Competency map
Students Take part in tests of a
new system, get to know
and share information
among themselves about
new possibilities.
KEEP
INFORMED
Interested in timely and
quality materials.
65. Stakeholder Involvement description Kind of
involvement
Relevant
Viewpoints
Human
Resources
(HR) e.g.,
HR
Managers
Key features of the enterprise
architecture are the roles and
Actors that support the
functions, applications, and
technology of the
organization. HR are
important stakeholders in
ensuring that the correct roles
and actors are represented.
KEEP
INFORMED /
INVOLVE in
NEW ACTOR
CREATION
Organization Chart /
Organization/Actor /
Location
Competency map
Customer Peculiar interests to simplify
interaction with supplier;
Interacting directly across
systems.
INVOLVE if
necessary;
ANALYSIS
Concerned that
specific data is not
protected well or is
transmitted via
insecure networks.
66. Identify business goals, business drivers of the organisation
• May be defined elsewhere in the enterprise
o If yes: ensure that the existing definitions are up to
date, and clarify any areas of ambiguity
Define constraints that must be dealt with
• project-specific constraints (time, schedule, resources,
etc.)
• enterprise-wide constraints (by the business and
architecture principles)
Work with originators of the Statement of Architecture Work
and Corporate Management to secure their endorsement.
67. Define what is inside and what is outside the scope of
the Baseline Architecture and Target Architecture efforts
• Often Baseline is described on higher level of
abstraction to save time and capabilities for more
detailed Target description
TOGAF requests to define:
• The breadth of coverage of the enterprise
• The level of detail required
• The partitioning characteristics of the architecture
• The specific architecture domains to be covered
(business, data, application, technology)
• The extent of the time period
• The architectural assets to be leveraged, or considered
for use
68. Review the principles under which the architecture is to be
developed
• normally based on the principles developed as part of
the Preliminary phase
Ensure that the existing definitions are current, and clarify
any areas of ambiguity
Work with responsible for Architecture Governance and
corporate management to secure their endorsement
69. Create a high-level view of the Baseline and Target
Architectures based on:
• Stakeholders concerns
• Business capabilities requirements
• Scope
• Constraints and principles
TOGAF states Business scenarios as useful technique
70. Business scenario is a method for:
• identifying and articulating the business and architecture
requirements
Method may be used iteratively and at different levels of
detail
Business scenario describes
• A business process, application, or set of applications
that can be enabled by the architecture
• The business and technology environment
• The people and computing components (called
"actors") who execute the scenario
• The desired outcome of proper execution
71. Identifying, documenting, and ranking the problem driving
the scenario
Identifying the business and technical environment of the
scenario and documenting it in scenario models
Identifying and documenting desired objectives
• Get "SMART“
72. A good business scenario is "SMART"
Specific, by defining what needs to be done in the
business
Measurable, through clear metrics for success
Actionable, by
• Clearly segmenting the problem
• Providing the basis for determining elements and plans
for the solution
Realistic, in that the problem can be solved within the
bounds of physical reality, time, and cost constraints
Time-bound, in that there is a clear statement of when
the solution opportunity expires
73. Identifying the human actors (participants) and their place
in the business model
Identifying computer actors (computing elements) and their
place in the technology model
Identifying and documenting roles, responsibilities, and
measures of success per actor; documenting the required
scripts per actor, and the results of handling the situation
Checking for "fitness-for-purpose" and refining only if
necessary
75. Digging into details through iterative phases of Gathering, Analyzing
and Reviewing
76. Gathering is the phase where information is collected
• Multiple techniques to solve this phase
o Desk research to investigate Information
o Surveys
o Workshop with carefully selected participants from
high levels in business and technical positions
Enterprise Architect can strengthen the business scenario
by obtaining "real-world examples"
77. Information gathered is processed and documented
Further models are created to represent that information
Maintain linkages between the key elements of the
business scenario
• Creation of matrices that assist in maintaining such
linkages
o Constituencies
o Human Actors
o Computer Actors
o Issues
o Objectives
78. Feedback results to the contractor of the project to ensure
that there is a shared understanding of:
o the full scope of the problem
o and the potential depth of the technical impact.
Interactive workshops are an appropriate way to
communicate the results
Key sensitive feature
o Absence of shared expectations in many cases the
background of latter project failures
82. Build a Data model showing which data is relevant to
solve the task, presented in the previous exercise (during
past lecture).
Reminder: Your organization requests you to conceptualize and
implement a new social system oriented both on academicians and
students, their parents for a National Ministry of Science and
Education. End-consumer is your home university.