Download - Profil Narasumber - APTIKOM
IBM Software Group
Business Architecture
Profil Narasumber
Muhaemin, S.Kom, SH, MM, M.Kom
▪ Master Asesor BNSP. MET.000.005399.2015
▪ Sertifikasi Kompetensi BNSP (ICT PM, Enterprise
Architect)
▪ COBIT 5.0 Foundation
▪ Kontak 08128663807
▪ Email: [email protected]
• Dosen Universitas Muhammadiyah Jakarta
• Pengembang Aplikasi : CAT Badan Kepegawaian
Negara (test masuk CPNS), Manajemen Kualitas Data –
BIG, SIMYANFAR – Kemenkes RI, Assesment Center
Dirjen Bina Marga PUPR.
• Konsultan ICT Blue Print (Mahkamah Agung RI,
Perpusnas, Setkab RI, BKN, Angkasa Pura I, SIMKIM –
Imigrasi)
• Konsultan Tata Kelola TI (Kemnaker, BIG, Kemen
PUPR, Kemen PPPA)
• Tim Penyusun Naskah Akademik Pedoman Audit
Keamanan Informasi, BSSN
• Tim Perumus SKKNI Bidang Software Development
Kominfo
• Tim Perumus Peta Okupasi TIK Nasional
• Asesor Kompetensi BNSP
IBM Software Group
Business Architecture
Unit KompetensiMembangun Business Architecture
MODUL #1
Muhaemin
J.620200.001.01 Menentukan Metode Pemodelan Arsitektur Bisnis dan Business
Building Block yang Diperlukan
Business Architecture
Unit Kompetensi Arsitektur Bisnis
Kode Unit Judul Unit
J.620200.001.01 Menentukan Metode Pemodelan Arsitektur Bisnis dan Business
Building Block yang Diperlukan
J.620200.002.01 Menetapkan Matriks, Diagram, dan Jenis Kebutuhan (Requirements)
yang Diperlukan pada Arsitektur Bisnis
J.620200.003.01 Menetapkan Baseline dan Target Arsitektur Bisnis, serta Kesenjangan
antara Baseline dan Target Arsitektur Bisnis
J.620200.004.01 Menyusun Roadmap Arsitektur Bisnis
J.620200.005.01 Mengevaluasi Artefak Arsitektur dalam Architecture Landscape yang
Terkait dengan Arsitektur Bisnis
J.620200.006.01 Memfinalisasikan Arsitektur Bisnis
Kode Unit : J.620200.001.01
Judul Unit : Menentukan Metode Pemodelan Arsitektur Bisnis dan
Business Building Block yang Diperlukan
Business Architecture
Creating a Mission Statement, Setting Goals and Developing Strategies
▪ A mission statement is a guiding light for a business and the individuals who run the
business. It is usually made up of three parts
▪ Vision - big picture idea of what you want to achieve.
▪ Mission - general statement of how you will achieve your vision.
▪ Core Values - how you will behave during the process.
▪ Once you have developed your mission statement, the next step is to create the following
items
▪ Goals - general statements of mileposts you need to meet to achieve your vision.
▪ Objectives - specific, time-sensitive statements for achieving your goals
▪ Strategies/Action Plans - specific implementation plans of how you will achieve your
objectives and goals.
KUK 1.1. Hubungan antara visi, misi, sasaran, dan tujuan organisasi sesuai domain organisasinya
Business Architecture
The Role of Goals and Objectives▪ Once you have developed your vision, mission and core values, you can then develop
the goals and objectives needed to achieve your vision
▪ Goals - Goals are general statements of what you want to achieve. So they need to be
integrated with your vision. They also need to be integrated with your mission of how you are
going to achieve your vision. Examples of company goals are:
▪ To earn at least a 20 percent after-tax rate of return on our net investment during the
next fiscal year
▪ To increase market share by 10 percent over the next three years.
▪ To lower operating costs by 15 percent over the next two years by improving the
efficiency of the manufacturing process.
▪ To reduce the call-back time of customers inquiries and questions to no more than four
hours.
▪ A goal should meet the following criteria:
▪ Suitable: Does it fit with the vision and mission?
▪ Acceptable: Does it fit with the values of the company and the employees?
▪ Understandable: Is it stated simply and easy to understand?
▪ Flexible: Can it be adapted and changed as needed?
Business Architecture
The Role of Goals and Objectives▪ Objectives - Objectives are specific, quantifiable, time-sensitive statements of what is going
to be achieved and when it will be achieved. They are milestones along the path of achieving
your goals. Examples of company objectives are:
▪ To earn at least a 20 percent after-tax rate of return on our net investment during the
next fiscal year
▪ To increase market share by 10 percent over the next three years.
▪ To lower operating costs by 15 percent over the next two years by improving the
efficiency of the manufacturing process.
▪ To reduce the call-back time of customers inquiries and questions to no more than four
hours.
▪ Objectives should meet the following criteria:
▪ Measurable: What will happen and when?
▪ Suitable: Does it fit as a measurement for achieving the goal?
▪ Feasible: Is it possible to achieve?
▪ Commitment: Are people committed to achieving the objective?
▪ Ownership: Are the people responsible for achieving the objective included in the
objective-setting process?
Business Architecture
Examples Categories Goals, Objectives in TOGAF 9.1
Goal: Improve Business Process Performance
Business process improvements can be realized through the following objectives:
■ Increased process throughput
■ Consistent output quality
■ Predictable process costs
■ Increased re-use of existing processes
■ Reduced time of sending business infor mation from one process to another process
Goal: Decrease Costs
Cost improvements can be realized through the following objectives:
■ Lower lev els of redundancy and duplication in assets throughout the enterpr ise
■ Decreased reliance on exter nal IT service providers for integration and customization
■ Lower costs of maintenance
Goal: Improve Business Operations
Business operations improvements can be realized through the following objectives:
■ Increased budget available to new business features
■ Decreased costs of running the business
■ Decreased time-to-market for products or services
■ Increased quality of services to customers
■ Improved quality of business infor mation
Goal: Improve Management Efficacy
Management efficacy improvements can be realized through the following objectives:
■ Increased flexibility of business
■ Shor ter time to make decisions
■ Higher quality decisions
Business Architecture
Business Architecture
Example Goals and Objectives
Business Architecture
The Role of Strategies and Action Plans
▪ Strategies are statements of how you are going to achieve something.
In a sense, a strategy is how you will use your mission to achieve your
vision.
▪ A strategy is a series of actions or activities designed to achieve the
goal.
▪ Goals and objectives provide milestones for measuring the success of
the strategy in achieving the vision.
▪ Action plans (tactics) are statements of specific actions or activities used
to achieve an objective. You need to identify specific individuals who have
the responsibility for implementing the action plans.
Business Architecture
Latihan KUK 1.1. Hubungan antara visi, misi, sasaran, dan tujuan organisasi
sesuai domain organisasinya
Buatlah / Review Visi, Misi, Strategies, Goals, Objectives and Action
Plans di Perusahaan / Organisasi Anda !
VIsi Misi Goals Objectives Action Plan
Menjadi lembaga
pendidikan tinggi
teknologi terbaik di
indonesia khususnya di
bidang TELEMATIKA
(Telekomunikasi, Media
dan Informatika)
dengan ukuran
jumlah dan kualitas
sumbangan tenaga ahli
maupun pemikiran yang
dihasilkannya
untuk dunia indonesia.
• Menyelenggarakan
pendidikan tinggi untuk
memberikan kesempatan
pendidikan seluas-luasnya
kepada masyarakat
indonesia, khususnya
dibidang teknologi.
• Melakukan penelitian dan
kerjasama dengan industri,
perguruan tinggi maupun
lembaga-lembaga lainnya
untuk menciptakan
sumbangan pemikiran-
pemikiran dan tenaga ahli
yang sesuai dengan
kebutuhan industri,
khususnya industri
Telematika
• Mendukung pengembangan
Telematika diwilayah lokal,
regional dan nasional
sebagai bagian pengabdian
kepada masyarakat
1. Peningkatan kualitas
akademik
2. Peningkatan kualitas
layanan administrasi
3. Peningkatan bidang
kemahasiswaan
4. Peningkatan
dukungan layanan
unit teknis
1.1 Menghasilkan
lulusan dengan IPK
Minimal 2,75 secara
konsisten
1.2 Menghasilkan
Lulusan yang
bersertifikat kompetensi
sesuai bidang
peminatan minimal 50%
dari total lulusan
2.1 Meningkatkan re-use
proses saat ini
2.2 Mengurangi waktu
pengiriman informasi
bisnis dari satu proses
ke proses lainnya
Action Plan:
1. Merekrut dosen
yang memili
sertifiikasi
kompetensi sesuai
bidang peminatan
dan
berpengalaman
sebagai praktisi TI
minimal 5 tahun
2. Menyesuaian
kurikulum sesuai
dengan kebutuhan
industry
3. Menerapkan
system informasi
akademik secara
terintegrasi dari
seluruh proses
layanan akademik
4. Upgrade kapabilitas
layanan Lab
Business Architecture
Kode Unit : J.620200.001.01Judul Unit : Menentukan Metode Pemodelan Arsitektur Bisnis dan Business Building Block yang Diperlukan
Business Architecture
Architecture Repository
Purpose
The Architecture Repository
acts as a holding area for all
architecture-related projects
within the enter prise. The
repository allows projects to
manage their deliverables,
locate re-usable assets, and
publish outputs to
stakeholders and other
interested parties.
Business Architecture
Architecture Repository
▪ The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
▪ The Architecture Capability defines the parameters, structures, and processes that support
governance of the Architecture Repository.
▪ The Architecture Landscape shows an architectural view of the building blocks that are in
use within the organization today (e.g., a list of the live applications). The landscape is likely
to exist at multiple levels of abstraction to suit different architecture objectives.
▪ The Standards Information Base (SIB) captures the standards with which new architectures
must comply, which may include industry standards, selected products and services from
suppliers, or shared services already deployed within the organization.
▪ The Reference Library provides guidelines, templates, patterns, and other forms of
reference material that can be leveraged in order to accelerate the creation of new
architectures for the enterprise.
▪ The Governance Log provides a record of governance activity across the enterprise
Business Architecture
Architecture Landscape Three Level of Granularity
1. Strategic Architectures , show a long-ter m summary view of the entire enterprise.
provide an organizing framework for operational and change activity and allow for direction
setting at an executive lev el.
2. Segment Architectures provide more detailed operating models for areas within an
enterprise. Segment Architectures can be used at the program or portfolio level to organize
and operationally align more detailed change activity.
3. Capability Architectures show in a more detailed fashion how the enterpr ise can
support a par ticular unit of capability. Capability Architectures are used to provide an
overview of current capability, target capability, and capability increments and allow for
individual wor k packages and projects to be grouped within managed por tfolios and
programs.
Business Architecture
Reference Library▪ The Reference Library provides a repository to hold reference materials that
should be used to develop architectures.
▪ Reference materials held may be obtained from a variety of sources, including:
■ Standards bodies
■ Product and service vendors
■ Industry communities or forums
■ Standard templates
■ Enter prise best practice The Reference Librar y should contain:
■ Reference Architectures
■ Reference Models
■ Viewpoint Library
■ Templates
Business Architecture
Standards Information Base
The Standards Infor mation Base provides a repository area to hold a set of specifications, to
which architectures must conform.
Establishment of a Standards Infor mation Base provides an unambiguous basis for
architectural governance because:
▪ The standards are easily accessible to projects and therefore the obligations of the project
can be understood and planned for
▪ Standards are stated in a clear and unambiguous manner, so that compliance can be
objectively assessed
Business Architecture
Standards Information Base Types and Lifecycle Process
▪Type of Standars
Legal and Regulatory Obligations
Industry Standars
Organizational Standars
▪ Standards Lifecycle Process:
Trial Standard
Active Standard
Depreciate Standard
Obsolute Standard
■ Proposed Standard: A potential standard has been identified for the organization, but has not yet been
evaluated for adoption.
■ Provisional Standard (also known as a Trial Standard): A Provisional Standard has been
identified as a potential standard for the organization, but has not been tried and tested to a lev el where its value is
fully understood. Projects wishing to adopt Provisional Standards may do so, but under specific pilot conditions, so
that the viability of the standard can be examined in more detail.
■ Standard (also known as an Active Standard): A Standard defines a mainstream solution
that should generally be used as the approach of choice.
■ Phasing-Out Standard (also known as a Deprecated Standard): A Phasing-Out
Standard is approaching the end of its useful lifecycle. Projects that are re-using existing components can generally
continue to make use of Phasing-Out Standards. Deployment of new instances of the Phasing-Out Standard are
generally discouraged.
■ Retired Standard (also known as an Obsolete Standard): An Retired Standard is no
longer accepted as valid within the landscape. In most cases, remedial action should be taken to remove the Retired
Standard from the landscape. Change activity on a Retired Standard should only be accepted as a part of an overall
decommissioning plan.
Business Architecture
Standards Information Base Clasification
▪Business Standards
Standard shared business functions
Standard role and actor definitions
Security and governance standards for business
activity
▪ Applications Standards :
Standard/shared applications supporting
specific business functions
Standards for application communication and
interoperation
Standards for access, presentation, and style
▪ Data Standards
Standard coding and values for data
Standard structures and for mats for data
Standards for origin and ownership of data
Restrictions on replication and access
▪ Technology Standards :
Standard hardware products
Standard software products
Standards for software development
Business Architecture
Governance Log
▪The Governance Log provides a repository area to hold
shared infor mation relating to the ongoing governance of
projects. Maintaining a shared repository of governance infor
mation is important, because:
Decisions made during projects (such as standards deviations or the rationale
for a par ticular architectural approach) are important to retain and access on
an ongoing basis. For example, if a system is to be replaced, having sight of
the key architectural decisions that shaped the initial implementation is highly
valuable, as it will highlight constraints that may otherwise be obscured.
Many stakeholders are interested in the outcome of project governance (e.g.,
other projects, customers of the project, the Architecture Board, etc.).
Business Architecture
Governance Log Contents
▪ Decission Log, log of all architecturally
significant decisions that have been
made in the organization. This would
typically include:
Product selections
Justification for major architectural features of
projects
Standards deviations
Standards lifecycle changes
Change request evaluations and approvals
Re-use assessments
▪ Compliance Assessments: At key
checkpoint milestones in the progress of
a project, a formal architecture review
will be carried out. This review will
measure the compliance of the project
to the defined architecture standards.
For each project, this log should include
Project overview
Progress overview (timeline, status, issues,
risks, dependencies, etc.)
Completed architecture checklists
Standards compliance assessment
Recommended actions
Business Architecture
Governance Log Contents
▪ Capability Assessments: Depending on
their objectives, some projects will carry out
assessments of business, IT, or Architecture
Capability. These assessments should be per
iodically carr ied out and tracked to ensure
that appropriate progress is being made.
This log should include:
— Templates and reference models for executing
Capability Assessments
— Business Capability Assessments
— IT capability, matur ity, and impact assessments
— Architecture maturity assessments
▪ Project Portfolio: The Project Por tfolio should hold
summary infor mation about all in-flight projects that
fall under architectural governance, including:
The name and description of the project
Architectural scope of the project
Architectural roles and responsibilities associated
with the project
▪ Performance Measurement: Based on a charter for
the architecture function, a number of perfor mance
cr iter ia will typically be defined. The Perfor mance
Measurement log should capture metrics relating to
project governance and any other perfor mance metr
ics relating to the architecture charter so that perfor
mance can be measured and evaluated on an
ongoing basis.
Business Architecture
TOGAF Architecture Capability
Business Architecture
Latihan KUK 1.2. Metode pemodelan yang diambil dari architecture repository
dipilih dengan tepat sesuai dengan visi, misi, sasaran dan tujuan organisasi
Pertanyaan:
1. Governance Log Apa yang perlu di ambil dari Arsitektur Repository jika PT tersebut ingin
mengetahui status proyek sebelumnya?
2. PT tersebut ingin membut tugas dan tanggung jawab tim dalam merealisasikan action plan ,
standar apa yang dapat di manfaat kan dan diambil dari Arcihtecture Repository?
VIsi Misi Strategy Goals Objectives Action Plan
A vibrant
rural
economy
driven by
value-
added
agriculture.
To create and facilitate
the development of
value-added e-
agricultural
businesses
Use local
researchers
with
Knowledge
Management
development
skills to
develop the e-
agricultural
businesses.
Goal (2): improve the
quantity and quality of
data and information e-
agriculture
Objective (2.1): Developing a
Knowledge Information System to
gather knowledge from the source
database 7 campus and external
data research MCA completed in
October 2016
Action Plan: Create a Project
from the farmers , reseacher
and ICT Consultant to build to
Knowledge Management
Information System about
Prairie Ethanol, Peterson
Organics and Valley Bio-
Diesel
Objective (2.1):
Building a community of academics
and businessmen to improve the
synergy of ecosystem research and
investment in agriculture 15%
within 3 Years
Action Plan:
create exhibitions and
advertising synergy projects
ecosystems GKMIS attended
10 leading industrial and five
major universities, two foreign
and three domesticl
Business Architecture
Kode Unit : J.620200.001.01Judul Unit : Menentukan Metode Pemodelan Arsitektur Bisnis dan Business Building Block yang Diperlukan
Business Architecture
What is Requirement? (Babok 3.0)▪ A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
▪ A condition or capability that must be met or possessed by a solution or solution component
to satisfy a contract, standard, specification, or other formally imposed documents.
Requirement
Business
Solutions
Functional
Non Functional
Transitition
KUK : 1.3 Kebutuhan bisnis (business requirements) diidentifikasikan
sesuai dengan sasaran dan tujuan organisasi.
Business Architecture
Clasification Requirement (Source BABOK® Guide, Version 3.0)
Business Requirements
are higher-level statements of the goals, objectives, or needs of the enterprise. They
describe the reasons why a project has been initiated, the objectives that the project will
achieve, and the metrics that will be used to measure its success. Business requirements
describe needs of the organization as a whole, and not groups or stakeholders within it.
They are developed and defined through enterprise analysis.
Solution Requirements▶▶ describe the characteristics of a solution that meet
business requirements and stakeholder requirements. They are developed and defined
through requirements analysis. They are frequently divided into sub-categories,
particularly when the requirements describe a software solution:
• Functional Requirements▷▷ describe the behavior and information that the solution
will manage. They describe capabilities the system will be able to perform in terms of
behaviors or operations—specific information technology application actions or
responses.
• Non-functional Requirements▷▷ capture conditions that do not directly relate to the
behavior or functionality of the solution, but rather describe environmental conditions
under which the solution must remain effective or qualities that the systems must have.
They are also known as quality or supplementary requirements. These can include
requirements related to capacity, speed, security, availability and the information
architecture and presentation of the user interface.
Business Architecture
Clasification Requirement?
Transition Requirements
describe capabilities that the solution must have in order to facilitate transition
from the current state of the enterprise to a desired future state, but that will not be
needed once that transition is complete. They are differentiated from other requirements
types because they are always temporary in nature and because they cannot be
developed until both an existing and new solution are defined. They typically cover data
conversion from existing systems, skill gaps that must be addressed, and other related
changes to reach the desired future state. They are developed and defined through
solution assessment and validation.
Business Architecture
Contoh RequirementBusiness Requirement Solutiion Requirement Transition Requirement
Meningkatkan kuantitas dan
kualitas data hasil penelitian
dengan mengembangkan
Green Knowledge
Management Information
System.
Untuk memenuhi
Goals
improve the quantity and
quality of data and information
e-agriculture
Objecives
Building a community of
academics and businessmen to
improve the synergy of
ecosystem research and
investment in agriculture 15%
within 3 Years
Functional
1. Sistem mampu menyimpan data-data peniltian baik
yang terstruktur maupun non tersrutkur (dokumen pdf,
word, grafik, dll)
2. Sistem mampu melakukan pencarian, dengan berbagai
kriteria minimal dari judul, peneliti, tahun peneltian
3. Sistem mampu melakukan crawler kepada data
penelitian dari berbagai sumber internet
4. Sistem mampu secara periodik me-retrive data-data
dari database PMIS (MCA)
5. Sistem memiliki fitur e-learning seperti webminar
dengan acuan www.futurelearning.com
Non Functional
• Sistem bekerja selama 24 jam dalam 7 hari
• Sistem mampu mengupload data penelitian maksimal
10 MB
• Sistem dapat diakses oleh 100 orang penelitian secara
simultan
• Sistem mampu diakses oleh maksimal 1000 user publik
• Sistem memiliki tampilan yang mudah digunakan, tidak
terlalu banyak navigasi , menghasilkan tingkat
kenyamanan user point 4 dalam skala 1 sd 5
Data conversion from existing systems
1. Data Jurnal penelitian 3 tahun
sebelumnya
2. Data peneliti dari 7 universitas
Memenui skill gaps:
• Peneliti : harus mampu menggunakan word
processing, menggunakan internet basic
seperti email system, upload dokumen,
approval hasil riset
• Staf TI : mampu install dan konfigurasi
Sistem, Backup Sistem, problem solving
standar
.
Business Architecture
Latihan
KUK : 1.3 Kebutuhan bisnis (business requirements) diidentifikasikan
sesuai dengan sasaran dan tujuan organisasi.
Test Demonstrasi (Task Skill)
1. Buatlah pernyataan Kebutuhan bisnis (business requirements) , Solution Requirements dan
Transition Requirements sesuai dengan Goals dan Objective organisasi.
Test Demonstrasi (Task Management Skill)
1. Perbaiki pernyataan Kebutuhan bisnis (business requirements) , Solution Requirements dan
Transition Requirements sesuai dengan Goals dan Objective organisasi Berikut ini
Business Architecture
Latihan
KUK : 1.3 Kebutuhan bisnis (business requirements) diidentifikasikan
sesuai dengan sasaran dan tujuan organisasi.
Test Demonstrasi (Task Management Skill)
1. Perbaiki pernyataan Kebutuhan bisnis (business requirements) , Solution Requirements , Goals dan Objective organisasi
Berikut ini
Visi Misi Business Requirement Solutiion Requirement
1. Membangun SDM
Dosen
2. Meningkatkan
kerjasama bidang
peneltian
Menjadi Perguruan Tinggi
bidang komputer terbaik
tahun 2020 dikawasan
jawa timur
Meningkatkan kuantitas
dan kualitas data hasil
pembelajaran dengan
mengembangkan
Academic Information
System.
Untuk memenuhi
Goals
improve the quantity and
quality of data and
information academic,
reseach and services
Objecives
Building a community of
academics and Senior
High School , Student
Familly to improve
customer loyalcty scala 5
within 2 Years
Functional
1. Sistem mampu menyimpan data-data Akademik
2. Sistem mampu melakukan pencarian, dengan berbagai
kriteria minimal dari judul, peneliti, tahun peneltian
3. Sistem memiliki fitur e-learning seperti webminar dengan
acuan www.futurelearning.com
4. Sistem mampu diakses oleh maksimal 1000 user publik
5. Sistem memiliki tampilan yang mudah digunakan, tidak
terlalu banyak navigasi , menghasilkan tingkat kenyamanan
user point 4 dalam skala 1 sd 5
Non Functional
1. Sistem bekerja selama 24 jam dalam 7 hari
2. Sistem mampu mengupload data penelitian maksimal 10 MB
3. Sistem dapat diakses oleh 100 orang penelitian secara
simultan
Kode Unit : J.620200.001.01
Judul Unit : Menentukan Metode Pemodelan Arsitektur Bisnis dan
Business Building Block yang Diperlukan
Memahami Building Block
Menyasar:
Elemen Kompetensi 2
KUK : 2.1, 3.1,3.3
Building blocks have generic characteristics
▪ A building block is a package of functionality defined to meet the business needs across an organization.
▪ A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business
service, application, or data entity)
▪ A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain experts.
▪ A building block may interoperate with other, inter-dependent, building blocks.
A Good Building blocks
▪ It considers implementation and usage, and evolves to exploit technology and standards.
▪ It may be assembled from other building blocks.
▪ It may be a subassembly of other building blocks.
▪ Ideally a building block is re-usable and replaceable, and well specified.
Building blocks
● A good choice of building blocks can lead to improvements in legacy system integration, interoperability, and
flexibility in the creation of new systems and applications.
● Systems are built up from collections of building blocks, so most building blocks have to interoperate with
other building blocks. Wherever that is true, it is impor tant that the interfaces to a building block are published
and reasonably stable.
● Building blocks can be defined at various levels of detail, depending on what stage of architecture
development has been reached. For instance, at an ear ly stage, a building block can simply consist of a
name or an outline descr iption. Later on, a building block may be decomposed into multiple supporting
building blocks and may be accompanied by a full specification.
● The level of detail to which a building block should be specified is dependent on the objectives of the
architecture and, in some cases, less detail may be of greater value (for example, when presenting the
capabilities of an enterpr ise, a single clear and concise picture has more value than a dense 100-page
specification).
Architecture Building Blocks
● Characteristics :
Capture architecture requirements; e.g., business, data, application, and technology
requirements
Direct and guide the development of SBBs
● ABB Spesification
Fundamental functionality and attributes: semantic, unambiguous, including security
capability and manageability
Interfaces: chosen set, supplied
Interoperability and relationship with other building blocks
Dependent building blocks with required functionality and named user interfaces
Map to business/organizational entities and policies
Solution Building Blocks
● Solution Building Blocks (SBBs) relate to the Solutions Continuum
● They can either procured or developed.
● Characteristics :
Define what products and components will implement the functionality
Define the implementation
Fulfil business requirements
Are product or vendor-awareABB Spesification
● Spesification
Specific functionality and attributes
Interfaces; the implemented set
Required SBBs used with required functionality and names of the interfaces used
Mapping from the SBBs to the IT topology and operational policies
Specifications of attributes shared across the environment (not to be confused with
functionality) such as security, manageability, localizability, scalability
Perfor mance, configurability
Design drivers and constraints, including the physical architecture
Relationships between SBBs and ABBs
Concepts and Definitions
The A ‘‘system’’ is a collection of components organized to accomplish a specific function or set of
functions.
The ‘‘architecture’’ of a system is the system’s fundamental organization, embodied in its
components, their relationships to each other and to the environment, and the principles guiding
its design and evolution.
An ‘‘architecture description’’ is a collection of artifacts that document an architecture. In TOGAF,
architecture views are the key artifacts in an architecture description.
‘‘Stakeholders’’ are people who have key roles in, or concerns about, the system; for example, as
users, dev elopers, or managers. Different stakeholders with different roles in the system will
have different concerns. Stakeholders can be individuals, teams, or organizations (or classes
thereof).
‘‘Concerns’’ are the key interests that are crucially important to the stakeholders in the system,
and determine the acceptability of the system. Concerns may per tain to any aspect of the
system’s functioning, development, or operation, including considerations such as perfor mance,
reliability, secur ity, distr ibution, and evolvability
Memahami Konsep dan Definisi Stakeholder, View
dan Viewpoint
Mensasar:
Elemen Kompetensi 2
KUK : 2.1, 3.1,3.3
Basic Arhitecture Concepts
Concepts and Definitions
The A ‘‘system’’ is a collection of components organized to accomplish a specific function or set of
functions.
The ‘‘architecture’’ of a system is the system’s fundamental organization, embodied in its
components, their relationships to each other and to the environment, and the principles guiding
its design and evolution.
An ‘‘architecture description’’ is a collection of artifacts that document an architecture. In TOGAF,
architecture views are the key artifacts in an architecture description.
‘‘Stakeholders’’ are people who have key roles in, or concerns about, the system; for example, as
users, dev elopers, or managers. Different stakeholders with different roles in the system will
have different concerns. Stakeholders can be individuals, teams, or organizations (or classes
thereof).
‘‘Concerns’’ are the key interests that are crucially important to the stakeholders in the system,
and determine the acceptability of the system. Concerns may per tain to any aspect of the
system’s functioning, development, or operation, including considerations such as perfor mance,
reliability, secur ity, distr ibution, and evolvability
Concepts and Definitions
A ‘‘view’’ is a representation of a whole system from the perspective of a related set of concerns.
In capturing or representing the design of a system architecture, the architect will typically create
one or more architecture models, possibly using different tools. A view will comprise selected
par ts of one or more models, chosen so as to demonstrate to a particular stakeholder or group
of stakeholders that their concerns are being adequately addressed in the design of the system
architecture.
A ‘‘viewpoint’’ defines the perspective from which a view is taken. More specifically, a viewpoint
defines: how to construct and use a view (by means of an appropriate schema or template); the
infor mation that should appear in the view; the modeling techniques for expressing and
analyzing the information; and a rationale for these choices (e.g., by describing the purpose and
intended audience of the view).
Simple Example of a Viewpoint and View
Simple Example of a Viewpoint and View
Example of a Viewpoint and View
TOGAF 9.1 Artifact
TOGAF Includes an
example set of
recommended artifacs than
can be adopted, enhanced
and combined to produce
arhitecture views
Three Classes of artifacts
are defined:
• Catalog (are specific
foundational viewpoints
(that represent lists of
building blocks)
• Matrices (are specific
foundational viewpoints
that show the relationship
between building blocks of
specific types
• Diagram (are graphical
viewpoints that present
building blocks in a rich
and visual way, more
suited to stakeholder
communication)
Sample Stakeholders and Categories
Template Stakeholders Map
TOGAF 9.1 Artifact
Business Architecture
Business Architechture :
Catalogs, Metrices and Diagrams
Business Architechture Catalogs
Business Architechture Metrices
Business Architechture Diagrams
Business Foot Print Diagrams
• Describes the links between business goals, organizational units,
business functions, and services, and maps these functions to the
technical components delivering the required capability.
• Demonstrates only the key facts linking organization unit functions
to delivery services and is utilized as a communication platform for
senior-level (CxO) stakeholders
Business Foot Print Diagrams
Goal/Objective/Service Diagrams
Functional Decompositon Diagram
Latihan
KUK : 2.1 Sudut pandang untuk setiap fungsi bisnis diidentifikasikan
sesuai aspek operasional, manajemen, dan finansial.
Test Demonstrasi (Task Skill)
1. Buatlah Contoh Dekomposisi fungsi Bisnis dari Perusahaan Anda untuk aspek operasional,
manajemen dan financial
2. Buatlah Business Footprint Diagram untuk fungsi operasional
Business Scenario
Mensasar:
Elemen Kompetensi 2
KUK : 2.2
Business Scenario
A 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
A good business scenario is representative of a significant business need or problem, and
enables vendors to understand the value to the customer organization of a developed solution.
A good business scenario is also ‘‘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
Creating the Business Scenario1. Identifying, documenting, and ranking the problem
driving the scenario
2. Identifying the business and technical environment
of the scenario and documenting it in scenar io
models
3. Identifying and documenting desired objectives (the
results of handling the problems successfully); get
‘‘SMART’’
4. Identifying the human actors (participants) and their
place in the business model
5. Identifying computer actors (computing elements)
and their place in the technology model
6. Identifying and documenting roles, responsibilities,
and measures of success per actor; documenting
the required scripts per actor, and the results of
handling the situation
7. Checking for ‘‘fitness-for-pur pose’’ and refining only
if necessary
Latihan Studi Kasus Membuat Business Scenario
1. Identifying, documenting, and ranking the problem driving the
scenario
2. Identifying the business and technical environment of the
scenario and documenting it in scenar io models
3. Identifying and documenting desired objectives (the results of
handling the problems successfully); get ‘‘SMART’’
4. Identifying the human actors (participants) and their place in the
business model
5. Identifying computer actors (computing elements) and their place
in the technology model
6. Identifying and documenting roles, responsibilities, and
measures of success per actor; documenting the required
scripts per actor, and the results of handling the situation
7. Checking for ‘‘fitness-for-pur pose’’ and refining only if necessary
Buatlah Dokumen Business Scenario untuk Aplikasi Go-Jek
Teknik-teknik untuk
menjelaskan
definisi arsitektur bisnis
Menyasar:
Elemen Kompetensi 2
KUK : 3.1 , 3.2
Define Architectural Vision● Strategy Map Diagram
Visual representation of the key Business Objectives aligned with balancing perspectives.
Customer
Customer Relationship Experience
PersonnelPersonnel Proficiency and Morale
Internal ProcessesInternal Operations
Financial Maximise Share Price and Dividends
Optimise price,availability,productchoices
Increase Knowledgeof SalesPersonnel
Integrated CRMSystems
Enhance CulturalWorking
Environment
Channel CostReduction
Delivery via Channel
Outsource high costtactical businessfunctions
Increase cross-sellratioImprove Cost Structure
Grow Turnover by17% per Year
Train Personnel
Process Modeling
● Purpose
To understand how work that involves
multiple roles and departments is
performed within an organization.
Scenario & Use Case
● Purpose
Scenarios and use cases are written to
describe how an actor interacts with a
solution to accomplish one or more of
that actor’s goals, or to respond to an
event.
Contoh Menggunakan Teknik-Teknik
Untuk Pemodelan Bisnis
Membuat Pemodelan Bisnis
● Input:
Rencana Strategis Organisasi
Peraturan Perundangan, Kebijakan Prosedur
Struktur Organisasi dan TUSI (Tugas dan Fungsi)
● Proses :
Identifikasi Fungsi utama dan Fungsi Pendukung
Memodelkan Bisnis High Level (Tools Value Chain)
Memodelkan Proses Bisnis secara rinci dengan (Dekomposisi Proses Bisnis)
● Output:
Model Bisnis
Memahami Struktur Proses Bisnis
Contoh Pemodelan Bisnis
Hasil Analisis
• Struktur Organisasi
• Tupoksi
• Pedoman Kerja
Contoh Dekomposisi Fungsi Bisnis dengan Bagan Hirarki Fungsi
Latihan:
Selanjutnya untuk mempertajam
model bisnis dapat dilakukan dengan :
- Activity Diagram
Untuk fungsi registrasi Akademik
Kode Unit : J.620200.001.01
Judul Unit : Menentukan Metode Pemodelan Arsitektur Bisnis dan
Business Building Block yang Diperlukan
Service Granularity Level, Boundaries, and Contracts
● Business services are specific functions that have explicit, defined boundaries that are
explicitly governed.
● A service contract covers the business/functional interface and also the technology/data
interface. Business Architecture will define the service contract at the business/functional
level, which will be expanded on in the Application and Technology Architecture phases.
● The granular ity of business services should be determined according to the business drivers,
goals, objectives, and measures for this area of the business. Finer-grained services permit
closer management and measurement (and can be combined to create coarser-grained ser
vices), but require greater effort to govern.
● A business service operates as a boundary for one or more functions. The granularity of
business services is dependent on the focus and emphasis of the business (as reflected by its
drivers, goals, and objectives). A service in Service Oriented Architecture (SOA) ter minology
(i.e., a deployable unit of application functionality) is actually much closer to an application
service, application component, or technology component, which may implement or support a
business service.
Business service, Business Function and Business Process
● A business service represents the added value that an organization delivers to its environment. One can make a distinction between internal and external services: Internal services represent the added value that is being delivered within the domain that the service belongs to. External services represent the added value that is being delivered to other domains or to the environment (for example customers).
● A business function is an area that the organization wants to pay attention to ( e.g. by putting energy into, structurally committing resources to etc) in order to support its business goals. A business function can therefore be positioned as a grouping of internal behavior based on a certain criteria (for example location (same department), communication, required skills, shared resources and shared knowledge). A business function represents a part of the added value of on organization.
● A business process is a unit of internal behavior or a collection of causal (sequence or dependency) related units of internal behavior, with the goal of producing a predefined collection of products and services. A business process can be constructed from sub processes or activities. A business process is triggered (started) by one or more business events or other business processes.
● A service is realized by one or more business functions or processes that represent concrete internal behavior of the organization. A business function can realize multiple business services.
Relationship Business service, Business Function and Business
Process
Ilustrasi Business service dan Business Function
1. Identifikasi Ada berapa business Service ?
2. Buatlah deskrispi dari Business Service Catalog