Preliminary Phase
Prepare the organization for enterprise architecture project
Goals:
Preliminary
• Define and scope the enterprise
You need to know which parts of an organization will be affected in the architecture to be developed, and how much they will be affected.
A
• Define the Architecture Principles
Define the architecture principles, which are the general rules and guidelines that govern the conduction of architecture work.
H
• Setup Architecture Repository Throughout the ADM you will keep producing different kinds of documents, as a result of performing the steps in the phases. These documents can be stored and organized in an architecture repository. We will talk more about this later on in this video.
B
Requirements Management
G
C
D
F E
© Copyright 2017 Visual Paradigm | All Rights Reserved 1
Develop Organization Model for Enterprise Architecture
2
Impact of the Stakeholders on EA
• Costly and hugely impact the project negatively if stakeholder’s expectations ignored i.e. delay in deliveries. • Manage the influence of all the stakeholders in relation to the project requirements to ensure a required • Take care of the interests of the stakeholders balancing the requirements of the project.
3
Scope the Enterprise
Basically there are four levels of impact.
Core - units those who are most affected and achieve most value
from the work.
Soft - Those who will see change to their
capability and work with core units but are otherwise not directly affected.
Extended - Those units outside the
scoped enterprise who will be affected in their own enterprise architecture.
Communities - Those stakeholders who will be affected and who are in groups of communities. Typically the customers of an organization fall into this level of impact.
Level of impact:
Stakeholders’ concern may be impacted by the project
Core Soft Extended Community
• A company is going to establish an enterprise architecture for anticipating requirement changes and business transformation. • We need to understand which company units are going to be impacted. • Besides, we have to indicate the level of impact. 4
Identify Participants in Architecture Development Besides identifying the impacted units, you also need to identify the participants who will take part in architecture development. • Ideally identify the stakeholders at the initial stages • It will cost hugely if you missed out any key stakeholders during that period
Group CIO
Legal Advisor
Chief Architect
Architecture Board
Architects
Program Maintenance Office
Service Management
5
RACI Chart Once these units are identified, identify the key tasks throughout the development of architecture. And state the responsibilities of the units with respect to the tasks. Usually we describe all these by mean of a RACI chart.
There are four main responsibilities: Responsible - Denoted by the letter ‘R’, responsible means the person who will complete the task. And is responsible for the actions and implementation.
Accountable - Denoted by ‘A’, accountable means the person hold the power to authorize actions or implementation. Evidently answerable for the correct and detailed completion of the deliverable task. Consulted - Advice and opinion can be obtain from this person. Usually, subject matter experts take the role. Informed - Person who will be kept up to date mainly upon completion of the task or deliverable. Informed - Person who will be kept up to date mainly upon completion of the task or deliverable.
Group CIO
Legal Advisor
Chief Architect
Task 1
Task 2
Task 3
R
R
R
R AC R
Architecture Board
A
Architects
C
Program Maintenance Office
Service Management
RA
AI 6
Enterprise Maturity Assessment Before embarking the development of architecture, perform a maturity assessment to analyze your organization’s competency in particular area in turn assist you identify opportunities for improvement.
We can use a popular maturity assessment tool for the analysis. Say, we have defined 8 assessment factors. Each factor define a particular area of organization’s competency. Goals
• We can make use of the chart to represent the level of maturity in different stages. • Obviously the red ring indicate the current maturity • The green ring indicate the level of maturity we want to achieve in medium term • The blue ring indicate the long term goal.
IT
Strategy
Documentation
Methods
Communication
Organization Competences
Current Medium-term goal Long-term goal
In this example, the factor is about the maturity level of the IT function within the enterprise, whether IT system is in-placed, well documented, etc.
7
Develop Architecture Principles
8
Architecture Principles
• Business Principles processes have to comply with all relevant laws, policies, and regulations. And this is a kind of business principle. • Data Principles is protected from unauthorized use and disclosure. Obviously this is a kind of data principles. output. • Application Principles, is an example of application principle. This principle state that the underlying technology has to be transparent to users, so they can be concentrated without distraction. • Technology Principles changes to the enterprise information environment have to be implemented in a timely manner. 9
Architecture - Examples
One-stop-shop solution for your team
Business Principles
Data Principles
Application Principles
Technology Principles
Processes comply with all relevant laws
Data is protected from unauthorized use
Ease of use
Able to support changes
Principles are general rules and guidelines, intended to be enduring and seldom amended, which inform and support the way in which an organization sets about fulfilling its mission. Generally speaking, there are four categories of principles: • Business Principles • Data Principles • Application Principles • Technology Principles
10
Five Criteria for a Good Set of Principles Improve Competitiveness
ROBUST
UNDERSTANDABLE
Clear and unambiguous, so that violations, whether intentional or not, are minimized.
Definitive and precise to support consistent decision-making in complex, potentially controversial situations.
COMPLETE
Cover every situation perceived.
STABLE
Principles should be enduring, yet able to accommodate changes.
CONSISTENT
Carefully chosen to allow consistent yet flexible interpretation.
11
Principle Template
Name
Compliance with Law
Statement
Enterprise information management processes comply with all relevant laws, policies, and regulations.
Rationale
Enterprise policy is to abide by laws, policies, and regulations. This will not preclude business process improvements that lead to changes in policies and regulations.
Implications
• The enterprise must be mindful to comply with laws, regulations, and external policies regarding the collection, retention, and management of data. • Education and access to the rules. Efficiency, need, and common sense are not the only drivers. Changes in the law and changes in regulations may drive changes in our processes or applications.
Mandatory
Mandatory
Review Reason
N/A
Review Date
08/08/2016 12
Develop Business Principles, Goals, Drivers
13
Context for Architecture Work
Business Principles
Business Goals
Business Drivers
Business principles, business goals, and business drivers provide context for architecture work
Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise.
14
Context for Architecture Work In the previous activity you’ve identified the business principles already. So now, we will focus on identifying the business goals and drivers.
!
Primacy of Principles Maximize Benefit to the Enterprise
!
!
Information Management
Business Goals A business goal is a high-level statement of intent, direction, or desired end result for business transformation.
Business Drivers
Business drivers motivate the development of business goals.
15
Define Business Goals Reference ID
Title
Business Goal
R-01
ArchiSurance
• Become top ten insurance institute in Europe • Enhance the popularity of the brand name for the institute
Reference ID
Title
Business Goal
R-01
ArchiSurance
• Unify the three existing platforms into a one-stop-shop service oriented insurance platform • Eliminate duplication of IT applications and better utilize of IT support and align with business initiatives.
16
Develop Architecture Repository
17
Concept of Deliverable Deliverables
Throughout the ADM cycle you will keep producing some documents in each phase. These documents are known as deliverables.
Preliminary
The deliverables are produced for approval, and for subsequent referencing in other phases.
H
A
B 18
Concept of Deliverable Deliverables
Deliverables had developed in on phase as output, will automatic serve as inputs for the subsequently development phases
Preliminary
H
A
B 19
Architecture Repository Architecture Metamodel Architecture Method
Content Metamodel
Architecture Landscape Strategic Architectures Segment Architectures Capability Architectures
Reference Library Foundation Architectures
Industry Architectures
Common Systems Architectures
Organization-Specific Architectures
Standards Information Base Business Standards
Data Standards
Application Standards
Technology Standards
Decision Log
Compliance Assessments
Capability Assessments
Calendar
Project Portfolio
Performance Measurement
Architecture Capability Organization Structure
Catalogs Matrics Diagrams
Governance Log
Skills Repository
Deliverables along with the artifacts have to be managed in a way that allows future retrieval with ease. And Architecture Repository is to serve this purpose.
Architecture Charter
The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties. 21
Deliverable contains Artifacts
Each deliverable is formed by several kinds of content, known as artifacts.
Catalogs Architecture Principles
Matrics Diagrams
There are three types of artifacts: 1. Catalogs Which are lists of building blocks. Building blocks are simply things. Anything included in the TOGAF metamodel, such as a principle, a business service, an organization unit, etc.
2. Matrices They show the relationships between building blocks of specific types.
3. Diagrams Present building blocks plus their relationships and interconnections in a graphical way.
20
Develop Request for Architecture Work
22
Start Architecture Development Trigger the start of architecture development cycle
Request for Architecture Work
Sponsoring Organization
Architecture Organization
The request for architecture work is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. In this phase you have complete this document in order to start subsequent architecture development activities.
23
e s a h P y r a n i f Prelim
o t l u s Re
24
Results Production of Deliverables: Print Organization Model for Enterprise Architecture
Business Principles Goal Drivers
Architecture Repository
Architecture Principles
Both the sponsoring organization and architecture development team are involved and committed to architecture development.
Request for Architecture Work
25