Erp 03

by Dr. Vsevolod S. Chernyshenko

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.

 The Business Architecture deﬁnes 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.

 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.

Preliminary Phase
describes the preparation
and initiation activities required
to create an Architecture
Capability including
customization of TOGAF and
deﬁnition of Architecture
Principles.
Preliminary

Architecture Vision
describes the initial phase
of an architecture development
cycle. It includes information
about deﬁning 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

Business Architecture
describes the development
of a Business Architecture to
support the agreed
Architecture Vision.
Business
Architecture

Information Systems
Architectures
of Information Systems
Architectures to support the
agreed Architecture Vision.
Information
Systems
Architecture

Technology Architecture
of the Technology Architecture
to support the agreed
Architecture Vision.
Technology
Architecture

Opportunities & Solutions
conducts initial
implementation planning and
the identiﬁcation of delivery
vehicles for the architecture
deﬁned in the previous
phases.
Opportunities
And
Solutions

Migration Planning
addresses how to move
from the Baseline to the
Target Architectures by
ﬁnalizing a detailed
Implementation and Migration
Plan. Migration
Planning

Implementation Governance
provides an architectural
oversight of the
implementation.
Implementation
Governance

Architecture Change
Management
establishes procedures for
managing change to the new
architecture.
Architecture
Change
Management

Requirements Management
examines the process of
managing architecture
requirements throughout the
ADM.
Requirements
Management

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.

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)

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

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:

 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).

 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.

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.

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.

 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

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

 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

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

 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

 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

 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

 Scope the Enterprise Organizations impacted
 Define and establish Enterprise Architecture Team and
Organization
 Identify and establish Architecture Principles
 Select and tailor Architecture Frameworks

 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

 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

 Scope new enterprise architecture work
 Determine constraints on enterprise architecture work
 Review and agree with sponsors and board
 Assess budget requirements

 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

 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

Modelling notations for different levels of abstraction and for
specific aspects
 Organisational modelling
o Organisational diagram
(MS Visio®)
o Work environment diagram
(ADONIS®)

 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

 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

Propose a scheme of the Enterprise Architecture Team
and University within the task presented in the previous
exercise (during past lecture).

 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

 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.

 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.

 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!

 Output of Preliminary phase
 Request of Architecture Work
 Business Principles
 Business Goals
 Business drivers

 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

 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

 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

 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

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

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.

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.

 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.

 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

 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

 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

 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

 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“

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

 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

1. • Problem
2. • Environment
3. • Objectives
4. • Human Actors
5. • Computer Actors
6. • Roles & Responsibilities
7. • Refine

Digging into details through iterative phases of Gathering, Analyzing
and Reviewing

 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"

 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

 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

Aggregation
Composition
Association / has interfaceGeneralisation
Is constraint
Has note
Dependency
Has association class

Build a Data model showing which data is relevant to
solve the task, presented in the previous exercise (during
past lecture).

Erp 03

More Related Content

What's hot (19)

Similar to Erp 03 (20)

Recently uploaded (20)

Erp 03