# OBASHI® Methodology study guide mind map

OBASHI® - a methodology from UK (containing both framework and method) for mapping and visualizing business to IT relationships. OBASHI® consists of: 5 Core Principles, 5 Laws of Digital Dynamics, 9 Laws, 1 Process (with 5 steps, iterative, incremental or sequential - based on requirements), 2 Diagram types, 6 Layers types, 6 Element types, 3 types of contextual information, 10 Relationships Rules, 6 Relationships Types, 1 Colour standards. Everything is defined in "The OBASHI Methodology" -...

または 登録 あなたのEメールアドレスで登録
その他
2085
ビジネス
2292
デザイン
322
OBASHI® Methodology study guide mind map

## 3. Laws of Digital Dynamics™ (5)

### 3.1. Digital Dynamics™ is the study of the transmission and flow of data between people, process and technology.

3.1.1. Therefore Digital Dynamics™ is the study of Digital Flow.

### 3.3. 1. For flow to exist, the flow of data must have taken place.

3.3.1. If data has not been passed from one element to another, then there is no flow of data.

### 3.4. 2. Digital flow has two or more nodes.

3.4.1. If there is only one node, there is nowhere for data to flow to or from. Therefore, there must be a minimum of two nodes.

3.4.2. Supporting image

### 3.5. 3. Digital flow can consist of one or more digital flows.

3.5.1. When studying the flow of data between people, processes and technology, it is possible to combine digital flows to create the bigger picture.

3.5.1.1. Many of the smaller digital flows may need to interact with other digital flows. This creates s combined flow.

3.5.2. Supporting image

### 3.6. 4. An interruption in the transmission or flow of data causes an effect.

3.6.1. If a break in the transmission of data between the nodes will not effect the digital flow, then a digital flow does not exist.

3.6.1.1. There must be some form of dependency or connection.

3.6.2. Supporting image

### 3.7. 5. A measured value pertaining to a digital flow must be aggregated from the values of each node comprising that digital flow.

3.7.1. Financial values (or other context) are placed against every measured flow to monitor costs and maximize profits.

3.7.2. Supporting image

## 4. OBASHI® Core Principles (5)

### 4.2. OBASHI® has 5 principles called - OBASHI® Core Principles.

4.2.1. OBASHI’s Core Principles outline the principles on which the OBASHI® methodology is based.

### 4.3. The OBASHI® 5 Core Principles have their origins in work undertaken in the UK oil and gas industry during the late 1990s.

4.3.1. 1770s:

4.3.1.1. mechanization, factories, and canals

4.3.1.2. flow of water

4.3.2. 1830s:

4.3.2.1. steam engines, coal, and iron railways

4.3.2.2. flow of steam

4.3.3. 1870s:

4.3.3.1. steel and heavy engineering, telegraphy, refrigeration

4.3.3.2. flow of electricity

4.3.4. 1910s:

4.3.4.1. oil, mass production, and the automobile

4.3.4.2. flow of oil, petrol

4.3.5. now:

4.3.5.1. IT

4.3.5.2. flow of data / information

### 4.4. 1. The understanding of the flow of data is fundamental to an organization’s financial well-being.

4.4.1. Understanding which data flows support the various business processes in an organisation, gives us an insight as to how the business works, and puts the roles of the assets that support and carry the flows in a business context.

4.4.2. How does the infrastructure support the flow of data / information around an organisation?

4.4.3. Who uses / depends on that data / information throughout the execution of a business process?

4.4.4. How valuable is the data / information?

4.4.5. What would be the total business impact if that data / information flow were interrupted?

### 4.5. 2. Business resources (including people) and IT assets are either providers or consumers of data, or are the conduit through which data flows.

4.5.1. Data / information is passed between individuals, departments, processes.

4.5.2. The IT infrastructure enables the flow of data.

### 4.6. 3. Information Technology exists for one reason, namely, to enable the flow of data between business assets.

4.6.1. Data in, data out.

4.6.2. Simplify a process.

4.6.3. Streamline a process.

4.6.4. Enable a process to happen.

4.6.5. Not the beginning or end of a process.

### 4.7. 4. Business risk cannot be fully assessed qualitatively or quantitatively unless the cause and effects of interruptions to a flow of data, or changes to any data contained in that flow, have been evaluated.

4.7.1. Where are we at risk of failure in terms of business at risk?

4.7.2. How great would the impact be on business objectives?

### 4.8. 5. A data security model cannot be fully assessed unless the cause and effects of interruptions to a flow of data, or changes to any data, have been evaluated.

4.8.1. How does the infrastructure support the Confidentiality, Integrity and Availability (CIA) of our information?

## 6. OBASHI® Elements (6)

### 6.1. Elements characteristics

6.1.1. Each element represents an asset (logical or physical) or a resource.

6.1.2. Illustrated as a rectangle or square.

6.1.3. Elements size depends on relationships.

6.1.4. Elements positioning depends on relationships.

6.1.5. Same elements are used on B&IT and DAV diagrams.

6.1.6. Each element has it’s standard color.

6.1.7. No one element type can be connected to every other type.

6.1.8. No element can connect outside of its adjacent layer.

6.1.9. Elements of the same type can be connected together – create hierarchical structures.

### 6.3. Elements should be given a name when positioned on a B&IT or DAV diagrams.

6.3.1. It is good practice to develop a naming convention for all types of elements before an OBASHI® project begins.

### 6.4. Ownership elements

6.4.1. What is it?

6.4.1.1.1. e.g. Project Manager, Business Analyst, Sales, Marketing department, London, Warsaw ...

6.4.2. 3 Categories of Owner

6.4.2.1. Personnel

6.4.2.2. Location

6.4.2.3. Organizational Unit

6.4.3. Can be mapped directly to:

6.4.3.1. in UML language ...

6.4.3.1.1. UML Actor (with custom stereotype)

6.4.3.2. in Archimate language ...

6.5.1. What is it?

6.5.1.1. Processes or functions used by the owner(s)

6.5.1.1.1. e.g. Order processing, Payment approval ...

6.5.2. Can be mapped directly to:

6.5.2.1. in UML language ...

6.5.2.1.1. entire UML Activity diagram

6.5.2.1.2. entire UML Sequence diagram

6.5.2.1.3. entire UML Interaction Occurrence diagram

6.5.2.1.4. entire UML Communication diagram

6.5.2.2. in BPMN language ...

6.5.2.2.1. entire BPMN diagram

6.5.2.3. in Archimate language ...

### 6.6. Application elements

6.6.1. What is it?

6.6.1.1. Application, or a collection / suite of applications

6.6.1.1.1. e.g. Oracla DB, IBM DB2, Liferay Portal, JBoss Portal, MS Sharepoint, MS Office 2013, MS Outlook, Adobe Reader, WinRAR ...

6.6.2. Can be mapped directly to:

6.6.2.1. in UML language ...

6.6.2.1.1. UML Component (with custom stereotype)

6.6.2.1.2. UML Node with Execution Environment stereotype

6.6.2.2. in Archimate language ...

6.6.2.2.1. Archimate Application Component

6.6.2.2.2. Application Collaboration Component

### 6.7. System elements

6.7.1. What is it?

6.7.1.1. Operating systems (classic / bare metal or virtualized)

6.7.1.1.1. e.g. IBM AIX, IBM z/OS, IBM PowerVM, Oracle Solaris, RedHat Linux, VMware ESXi, Windows Server, Windows 8 ...

6.7.2. Can be mapped directly to:

6.7.2.1. in UML language ...

6.7.2.1.1. UML Component (with custom stereotype)

6.7.2.1.2. UML Node with Execution Environment stereotype

6.7.2.2. in Archimate language ...

6.7.2.2.1. Archimate System Software

### 6.8. Hardware elements

6.8.1. What is it?

6.8.1.1. Computer hardware

6.8.1.1.1. e.g. Sun Blade 6000, SunFire X2200, IBM x3560, Dell Workstation ...

6.8.2. Can be mapped directly to:

6.8.2.1. in UML language ...

6.8.2.1.1. UML Node with Execution Environment stereotype

6.8.2.1.2. UML Node (with custom stereotype)

6.8.2.2. in Archimate language ...

6.8.2.2.1. Archimate Node

6.8.2.2.2. Archimate Device

### 6.9. Infrastructure elements

6.9.1. What is it?

6.9.1.1. Computer network hardware and logical network configurations

6.9.1.1.1. e.g. Switches, Routers, Multiplexers, Bridges, Hubs, VPN, DMZ ...

6.9.2. Can be mapped directly to:

6.9.2.1. in UML language ...

6.9.2.1.1. UML Node (with custom stereotype)

6.9.2.1.2. UML Component (with custom stereotype)

6.9.2.2. in Archimate language ...

6.9.2.2.1. Archimate Node

6.9.2.2.2. Archimate Device

## 7. OBASHI® Layers (6) (a.k.a. OBASHI® framework)

### 7.2. The layers provide a framework (aka. the OBASHI® framework) for organising individual elements that represent individual Business or IT assets and resources.

7.2.1. Elements can only reside in their own OBASHI layer.

7.2.1.1. Once an element has been created and positioned in a particular layer it becomes implicitly associated with that layer.

### 7.5. Ownership Layer

7.5.1. The Ownership Layer contains elements representing the person(s) or group(s) that ‘owns’, or is responsible for, business processes portrayed in the Business Layer.

7.5.1.1. Ownership elements can be positioned beneath other ownership elements to create a hierarchy of owners.

7.5.2. Example elements could be:

7.5.2.1. Accountancy

7.5.2.2. Planning Manager

7.5.2.3. Logistics

7.5.2.4. New York

7.5.2.6. Environmental Health

7.5.2.7. ...

7.6.1. The Business Layer contains elements representing the business processes or functions that are being used by the ‘Owner(s)’.

7.6.1.1. These elements are positioned under their appropriate ‘Owner’.

7.6.2. Example elements could be:

7.6.2.1. Monthly Balance

7.6.2.2. Sales Transactions

7.6.2.3. Tank Stock Management

7.6.2.4. Production Data

7.6.2.5. Capture Budgeting

7.6.2.6. ..

### 7.7. Application Layer

7.7.1. The Application Layer contains elements representing software applications.

7.7.1.1. These are positioned beneath the business processes that utilise them.

7.7.2. Example elements could be:

7.7.2.1. Excel

7.7.2.2. Oracle

7.7.2.3. Sage

7.7.2.4. SAP

7.7.2.5. PeopleSoft

7.7.2.6. ...

### 7.8. System Layer

7.8.1. The System Layer contains elements representing the operating systems on which the applications run.

7.8.1.1. These elements are positioned beneath the appropriate applications.

7.8.2. Example elements could be:

7.8.2.1. Windows XP

7.8.2.2. Windows 8.1

7.8.2.3. Unix

7.8.2.4. Solaris

7.8.2.5. Linux

7.8.2.6. ...

### 7.9. Hardware Layer

7.9.1. The Hardware Layer contains elements representing the computer hardware on which the operating systems run.

7.9.1.1. These elements are positioned beneath the appropriate operating systems.

7.9.2. Example elements could be:

7.9.2.1. Workstations

7.9.2.2. Servers

7.9.2.3. Laptops

7.9.2.4. Tablet PCs

7.9.2.5. Mainframes

7.9.2.6. ...

### 7.10. Infrastructure Layer

7.10.1. The Infrastructure Layer contains elements representing the network infrastructure into which the hardware is connected.

7.10.1.1. Infrastructure elements can be positioned beneath other infrastructure elements to create a hierarchy that supports the business.

7.10.2. Example elements could be:

7.10.2.1. Switches

7.10.2.2. Routers

7.10.2.3. Multiplexers

7.10.2.4. Bridges

7.10.2.5. Hubs

7.10.2.6. ...

## 8. OBASHI® Diagrams (2)

### 8.1. Diagrams characteristics

8.1.1. Each diagram uses the same 6 types of elements.

8.1.2. Often DAV diagrams have exactly the same layers and elements only to show contextual information not displayed on B&IT diagrams.

### 8.2. OBASHI® has 2 types of diagrams

8.2.1. Business & IT Diagram (B&IT)

8.2.1.1. What is it?

8.2.1.1.1. A B&IT diagram is a diagrammatic representation of the logical and physical relationships (connectivity) between an organisation’s IT assets and resources and the business operations which they support.

8.2.1.1.2. 6 layered model, showing how the people, processes and technology of a business interact

8.2.1.1.3. Layers logically divided on 2 groups:

8.2.1.2. Layers are used to create B&IT diagrams.

8.2.1.3. Easy for understanding for non technical people.

8.2.2. Dataflow Analysis View (DAV)

8.2.2.1. What is it?

8.2.2.1.1. OBASHI® Dataflow Analysis View (DAV) is a graphical and statistical document that illustrates a subset of elements, in a pre-defined sequence, from one or more B&IT diagrams.”

8.2.2.1.2. 6 layered model, illustrates how IT systems support the flow of data / information within and between business processes.

8.2.2.1.3. Model, analyse, value and report on all the data flows that underpin your business, across multiple B&IT diagrams.

8.2.2.1.4. Facilitates same layers from B&IT diagrams.

8.2.2.1.5. Provides clear visualization of data / information Suppliers and Providers.

8.2.2.2. In comparison to B&IT diagrams, DAVs adds so called: Additional contextual information:

8.2.2.2.1. 3 types

8.2.2.2.2. Contextual information can be placed:

8.2.2.2.3. Contextual information is optional.

8.2.2.3. Same OBASHI® Layers are used to create DAV diagrams as in B&IT.

8.2.2.4. Same as B&IT diagram, easy for understanding for non technical people.

8.2.2.5. DAVs allows you to extract full value from the data appended to your elements in your B&IT diagrams. (requires software - Control Centre).

8.2.2.6. DAVs enables cost / value statistics to be generated to understand the contribution IT assets make to the business. (requires software for automation).

8.2.2.7. Analysis of the DAV can highlight vulnerabilities, mis-alignment and areas for consolidation.

## 10. OBASHI® Relationship Types (6)

### 10.2. Relationships characteristics

10.2.1. Relationship Persistence

10.2.1.1. Relationships on one B&IT hold true across all B&IT diagrams whether shown or not.

10.2.2. Impact Rules

10.2.2.1. Impact rules determine how impact would cascade through the OBASHI®model.

10.2.3. Dependencies v Connections

### 10.3. Connection

10.3.1. Bi-directional.

10.3.2. BLACK LINE - standard color.

10.3.3. Explicitly connected to show a bi-directional coupling.

10.3.4. Signify ONLY data paths.

10.3.4.1. Does NOT necessarily signify that data is exchanged bi-directionally between the elements.

10.3.5. Straight lines, horizontal and / or vertical or right angled connections.

10.3.6. No limit on number of connections.

10.3.6.1. Multiple connections between two elements.

10.3.7. An element can be connected to any number of other elements - in accordance with the OBASHI® relationship rules.

10.3.7.1. Can be used for showing eg. resilent networks.

10.3.7.2. Can be used for identifying SPOFs - Single Point of Failure.

### 10.4. Dependency

10.4.1. Uni-directional.

10.4.2. Not restricted by layer.

10.4.2.1. Line may follow any path.

10.4.3. RED ARROW - standard color.

10.4.4. Explicitly connected uni-directionally to show how one element is dependent on another.

10.4.5. An element can have one or more dependencies / dependent(s).

10.4.6. No limit on number of dependencies.

### 10.5. Layer

10.5.1. An implicit relationship which exists between all elements within a particular layer.

10.5.2. Two or more elements within the same layer have an implicit relationship (see Relationship Rule 2), know as a Layer relationship

### 10.6. Set

10.6.1. A set is a grouping of elements according to a specified relationship.

10.6.1.1. Just logical grouping (without regard for their position on one or more B&IT diagrams, thus creating sets of related elements), as simple as that.

10.6.2. Two or more elements within the same set have an explicit relationship, known as a set relationship.

10.6.3. Explicit logical groups of elements, that exist without regard to their position on a B&IT diagram.

10.6.4. Any element can be assigned to a Set.

10.6.4.1. No restriction on the number of Sets to which an element can be assigned.

10.6.5. There are no formal rules governing Sets

10.6.5.1. Any element can be placed within sets.

10.6.5.2. Any element can exists in multiple sets.

### 10.7. Sequential

10.7.1. An explicit relationship denoted by a list of elements in which adjoining elements in the list have a connection relationship or dependency relationship - i.e. a string of connected elements.

10.7.2. Sequential relationships are used within OBASHI® to model data flows.

10.7.3. A list of elements, the order of which forms a sequence.

10.7.4. Sequences therefore consist of chains of connected or dependent elements or sequences.

### 10.8. Spatial

10.8.1. An implicit relationship which is formed between elements which are placed above or below each other.

10.8.2. Geographical positioning relative one to another.

10.8.3. if an element is placed directly above or below another element there is an implied relationship between them.

10.8.4. There are many classifications of Spatial relationships which are derived from how an element is positioned in relation to another on a B&IT diagram.

10.8.5. Spatial Rules

10.8.5.1. There are many classifications of Spatial relationships which are derived from how an element is positioned in relation to another on a B&IT diagram.

## 11. OBASHI® Project Lifecycle with Phases (5) (based on PRINCE2® process model)

### 11.4. OBASHI® project lifecycle has 5 phases

11.4.1. 1. Scope

11.4.1.1. Objectives

11.4.1.1.1. Establish the project.

11.4.1.1.2. Create a set of management products to enable the project to be set up and approved.

11.4.1.2. Steps

11.4.1.2.1. not defined

11.4.1.3. Associated documentation:

11.4.1.3.1. Daily Log

11.4.1.3.2. Lessons Log

11.4.1.3.5. Project Brief

11.4.1.3.6. Project Plan

11.4.1.3.7. Strategies

11.4.1.3.8. Registers

11.4.1.3.9. Establishment Document

11.4.2. 2. Capture

11.4.2.1. Objectives

11.4.2.1.1. Gather and analyse information used to create OBASHI® model.

11.4.2.1.2. Source and validate the information that represents the people, process and technology in each of the OBASHI® layers.

11.4.2.2. Steps

11.4.2.2.1. Step 1 - Identify Information Sources.

11.4.2.2.2. Step 2 - Evaluate Scope Against the Information Sources.

11.4.2.2.3. Step 3 - Plan Workshops.

11.4.2.2.4. Step 4 - Prepare Questionnaires.

11.4.2.2.5. Step 5 - Manage Communications.

11.4.2.2.6. Step 6 - Ensure Security Clearance.

11.4.2.2.7. Step 7 - Perform Interviews.

11.4.2.2.8. Step 8 - Hold Workshops.

11.4.2.2.9. Step 9 - Extract Information.

11.4.2.2.10. Step 10 - Link to Data Sources.

11.4.3. 3. Design

11.4.3.1. Objectives

11.4.3.1.1. Analyze and model the information gathered during the Capture phase.

11.4.3.2. Steps

11.4.3.2.1. Step 1 - Create a B&IT diagram.

11.4.3.2.2. Step 2 - Add Elements (by manual drawing or using a software tool / application).

11.4.3.2.3. Step 3 - Review Element Positioning.

11.4.3.2.4. Step 4 - Connect Elements.

11.4.3.2.5. Step 5 - Relate Dependent Elements.

11.4.3.2.6. Step 6 - Add Holds and Notes for Information that is Outstanding.

11.4.3.2.7. Step 7 - Create Dataflow Analysis Views (DAVs).

11.4.4. 4. Refine

11.4.4.1. Objectives

11.4.4.1.1. Prepare the OBASHI® model, and all the B&IT diagrams and DAVs associated with the project, for approval and sign-off.

11.4.4.2. Steps

11.4.4.2.1. Step 1 - Review B&ITs.

11.4.4.2.2. Step 2 - Review DAVs.

11.4.4.2.3. Step 3 - Update B&ITs.

11.4.4.2.4. Step 4 - Review Registers (with authorized personnel only).

11.4.4.2.5. Step 5 - Approve Sign-off on Revision No. 1 and Issue for Comment.

11.4.5. 5. Handover

11.4.5.1. Objectives

11.4.5.1.1. Ensure the deliverables created during the project are passed into the operational business environment.

11.4.5.1.2. Close out the OBASHI® project and transfer the OBASHI® knowledge and documentation over to operational environment.

11.4.5.1.3. Master documents should slot into the existing critical document processes to be controlled and managed in a similar way to other business critical documents.

11.4.5.2. Steps

11.4.5.2.1. Step 1 - Prepare Planned Closure.

### 11.5. Yet originally OBASHI® project lifecycle is based on PRINCE2® model, it is very generic and can be replaced with any other project management practice (e.g. PRINCE2®, PMBOK® Guide, DSDM®, AgilePM® etc.).

11.5.1. see DSDM® AgilePF (v6, 2014) mind map

11.5.2. see AgilePM® mind map

11.5.3. see PMBOK®5 mind map

### 11.6. OBASHI® project lifecycle as most of the project lifecycles can be incorporated within programme mamagement practice (e.g. MSP®, AgilePgM™ etc.).

11.6.1. see AgilePgM™ mind map

11.6.2. see MSP® mind map

## 12. OBASHI® Color Standard (1)

### 12.4. Where different colors or visual guidelines are used in the creation of B&IT diagrams, a legend should be attached as an explanation.

12.4.1. Visual effects can be placed on the elements such as beveling, patterning or gradients to give an enhanced appearance, but they should not vary too far from the standard color unless a legend is included indicating what the non-standard appearance signifies.

12.4.2. If any color other than black is used to represent connections a legend must be supplied on the diagram to show the meaning of the colored connections.

12.4.3. If any color other than red is used to represent dependencies a legend must be supplied on the diagram to show the meaning of the colored dependencies.

### 12.5. Ownership

12.5.1. #d5b7e1

12.5.2. R: 213 G: 183 B: 225

12.6.1. #e8d6e3

12.6.2. R: 232 G: 214 B: 227

### 12.7. Application

12.7.1. #ffb0b7

12.7.2. R: 255 G:176 B: 183

### 12.8. System

12.8.1. #c4d8e5

12.8.2. R: 196 G: 216 B: 229

### 12.9. Hardware

12.9.1. Hardware

12.9.1.1. #eeea9d

12.9.1.2. R: 238 G: 234 B: 157

12.9.2. Hardware - Server

12.9.2.1. #ffc82e

12.9.2.2. R: 255 G: 216 B: 229

### 12.10. Infrastructure

12.10.1. #abdebe

12.10.2. R: 171 G: 222 B: 190

## 13. OBASHI® Official publications

### 13.1. The OBASHI® Methodology

13.1.1. ISBN: 978-0117068575

13.1.2. Pages: 216

13.1.4. The most important, key position on OBASHI® preparing for Foundation exam.

## 14. OBASHI® Official resources

### 14.1. OBASHI® sample exams, available online

14.1.1. Foundation

14.1.1.1. http://online.apmg-exams.com/index.aspx?masterid=19&subid=76

14.1.2. Practitioner

14.1.2.1. ... under development, currently not available

### 14.2. OBASHI® White Papers

14.2.1. OBASHI® Explained

14.2.1.1. http://www.apmg-international.com/nmsruntime/saveasdialog.aspx?lID=3369&sID=7765

### 14.3. OBASHI® website

14.3.1. http://www.obashi.co.uk/

### 14.4. OBASHI® shop

14.4.1. http://www.obashi.co.uk/shop/default.aspx

### 14.5. OBASHI® forum "Think"

14.5.1. http://think.obashi.co.uk/

## 15. What is OBASHI®?

### 15.1. A methodology for creating a visual map of a business relationships with IT assets, which shows:

15.1.1. “big picture” of how the business works.

15.1.2. How a business is supported by IT assets.

15.1.3. The assets that make it work.

15.1.4. The interdependencies between the assets.

15.1.5. How data / information flows around the business.

15.1.6. How critical IT is for business.

15.1.7. How failure of IT asset can bring down service delivery.

### 15.2. Simple, easy to adopt methodology.

15.2.1. A ‘Common Language’ for technical and non-technical people.

### 15.3. Applies to all types, sizes and sectors of organisations.

15.3.1. OBASHI® is a generic methodology, yet not "one size fits all".

### 15.5. OBASHI® is both methodology and technology.

15.5.1. methodology ...

15.5.1.1. way of thinking and working

15.5.2. technology ...

15.5.2.1. software

### 15.6. OBASHI® 'family' has 4 components:

15.6.1. "OBASHI® - Methodology, standard, notation and technology in one."

15.6.2. Methodology

15.6.3. Framework

15.6.4. Diagrams

15.6.5. Technology (Control Centre / software)

### 15.7. Why OBASHI® is important? / OBASHI® benefits.

15.7.1. OBASHI® slogan: “with clarity and vision, you can develop and improve.”

15.7.2. Clarity

15.7.2.1. Clarity - Freedom from ambiguity.

15.7.2.2. The OBASHI® Methodology creates easy-to-read diagrams which help remove ambiguity from business decision-making.

15.7.2.2.1. OBASHI® does not requires any specialist skills (either technical or analytical) to interpret a B&IT and DAV diagrams.

15.7.2.2.2. OBASHI® can be used for providing common understanding among professionals from all areas of the business.

15.7.2.2.3. OBASHI® can be used for providing communication tools for brainstorms and workshop sessions.

15.7.3. Vision

15.7.3.1. Vision - The Power of anticipation.

15.7.3.2. The OBASHI® Methodology allows you to anticipate issues and challenges which can prevent a business achieving its goals.

15.7.3.2.1. OBASHI® can be used for identifying gaps in the current operating environment that could impact on the achievement of future strategic goals.

15.7.3.2.2. OBASHI® can be used to visualize AS-IS, transitional and TO-BE relationship between business and IT, before and after a project / programme.

15.7.3.2.3. OBASHI® can be used for defining the programme of activities required to transform the organization to its future state.

15.7.4. Develop

15.7.4.1. Develop - The Enhance the capabilities.

15.7.4.2. The OBASHI® Methodology can enhance business capability through successful programme and project implementation.

15.7.4.2.1. The clarity and common understanding provided by B&IT and DAV diagrams support change programmes by facilitating:

15.7.5. Improve

15.7.5.1. Improve - To become a better business.

15.7.5.2. The OBASHI® Methodology can enhance business performance through better operational management.

15.7.5.2.1. OBASHI® B&IT diagrams can be used for providing a mechanism to support the effective communication and audit processes.

15.7.5.2.2. OBASHI® diagrams with contextual information, can provide static view on assets e.g.

## 18. This freeware, non-commercial mind map (aligned with the newest version of OBASHI®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the OBASHI® methodology and as a learning tool for candidates wanting to gain OBASHI® qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

### 18.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com

18.1.3. https://play.spotify.com/user/miroslawdabrowski/

18.1.4. http://www.miroslawdabrowski.com

18.1.6. miroslaw_dabrowski