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


Unit KompetensiMembangun Business Architecture

MODUL #1

Muhaemin

[email protected]

J.620200.001.01 Menentukan Metode Pemodelan Arsitektur Bisnis dan Business

Building Block yang Diperlukan


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


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


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?


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?


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


Example Goals and Objectives


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.


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


Kode Unit : J.620200.001.01Judul Unit : Menentukan Metode Pemodelan Arsitektur Bisnis dan Business Building Block yang Diperlukan


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.


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


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.


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


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


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.


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


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


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


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.


TOGAF Architecture Capability


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


Kode Unit : J.620200.001.01Judul Unit : Menentukan Metode Pemodelan Arsitektur Bisnis dan Business Building Block yang Diperlukan


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.


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.


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.


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

.


Latihan



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


Latihan



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

http://www.futurelearning.com/

Kode Unit : J.620200.001.01



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


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


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

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



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

Profil Narasumber - APTIKOM

Documents

Transcript of Profil Narasumber - APTIKOM