Business Architecture Fundamentals

Business Architecture
Essentials
Web Age Solutions Inc.

USA: 1-877-517-6540
Canada: 1-866-206-4644
Web: http://www.webagesolutions.com
The following terms are trademarks of other companies:
Java and all Java-based trademarks and logos are trademarks or registered trademarks of
Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
IBM, WebSphere, DB2 and Tivoli are trademarks of the International Business Machines
Corporation in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of
others.
For customizations of this book or other sales inquiries, please contact us at:
USA: 1-877-517-6540, email: getinfousa@webagesolutions.com
Canada: 1-866-206-4644 toll free, email: getinfo@webagesolutions.com
Copyright © 2014 Web Age Solutions Inc.

This publication is protected by the copyright laws of Canada, United States and any
other country where this book is sold. Unauthorized use of this material, including but not
limited to, reproduction of the whole or part of the content, re-sale or transmission
through fax, photocopy or e-mail is prohibited. To obtain authorization for any such
activities, please write to:
Web Age Solutions Inc.
439 University Ave
Suite 820
Toronto
Ontario, M5G 1Y8
Table of Contents
Chapter 1 - What is Business Architecture?........................................................................6
1.1 Defining Business Architecture................................................................................7
1.2 Layers of the Enterprise Architecture.......................................................................9
1.3 The Business Architecture Domain .......................................................................10
1.4 The Values of Business Architecture......................................................................11
1.5 Relationship with Other Types of Architecture......................................................12
1.6 Other Pillars of Business Architecture ...................................................................14
1.7 Formal Business Architecture.................................................................................15
1.8 Ownership vs Stewardship......................................................................................17
1.9 Business Architecture Frameworks.........................................................................18
1.10 Enterprise Architecture Frameworks....................................................................19
1.11 Business Architect vs Business Analyst - 1/3.......................................................20
1.14 Going Beyond the Process....................................................................................25
1.15 Summary...............................................................................................................27
Chapter 2 - Enterprise Architecture Frameworks Overview ............................................28
2.1 The Importance of a Framework for EA.................................................................29
2.2 EA Framework Family Tree...................................................................................30
2.3 Group Discussion: Architecture Frameworks.........................................................32
2.4 TOGAF...................................................................................................................33
2.5 TOGAF Components..............................................................................................34
2.6 Architecture Development Method (ADM)............................................................36
2.7 Architecture Content Framework ...........................................................................38
2.8 Views & Viewpoints...............................................................................................39
2.9 TOGAF Viewpoints................................................................................................41
2.10 Catalogs, Matrices, Diagrams & Viewpoints........................................................44
2.11 Architecture Deliverables......................................................................................46
2.12 ADM Techniques..................................................................................................47
2.13 Enterprise to Solution Architecture.......................................................................53
2.14 Zachman Framework ..........................................................................................55
2.15 Zachman Framework Matrix Overview................................................................57
2.16 The Scope of the Zachman Framework ...............................................................59
2.17 What the Zachman Framework is NOT ...............................................................60
2.18 TOGAF Artifacts Using the Zachman Framework...............................................61
2.19 Leveraging the Zachman Framework ..................................................................63
2.20 Federal Enterprise Architectural Framework (FEAF)..........................................64
2.21 Leveraging FEA....................................................................................................66
2.22 Some Other Frameworks ......................................................................................68
2.23 Which Framework Should I Use?.........................................................................69
2.24 Summary...............................................................................................................71
Chapter 3 - Introduction to BPMN....................................................................................72
3.1 What is BPMN?......................................................................................................73
3.2 What does BPMN include?.....................................................................................74
3.3 The Eye of the Beholder.........................................................................................75
3.4 BPMN and BPEL....................................................................................................76
3.5 Basic Structure of a Process....................................................................................78
3.6 Basic Structure of a Process....................................................................................79
3.7 The Start Event........................................................................................................80
3.8 Normal End Events.................................................................................................82
3.9 Abnormal End Events.............................................................................................84
3.10 Intermediate Events...............................................................................................85
3.11 Gateways...............................................................................................................86
3.12 Exclusive Condition..............................................................................................88
3.13 Exclusive Condition Examples.............................................................................90
3.14 Parallel Execution.................................................................................................92
3.15 Modeling Roles & Responsibilities......................................................................94
3.16 Using Swim Lanes................................................................................................96
3.17 Modeling B2B Interaction.....................................................................................98
3.18 Trading Partner Design Pattern...........................................................................100
3.19 Modeling B2B Interactions.................................................................................101
3.20 B2B Interaction Example....................................................................................103
3.21 Summary.............................................................................................................105
Chapter 4 - Business Architecture Views........................................................................106
4.1 The Importance of Architecture Views.................................................................107
4.2 Describing Architecture through Views................................................................111
4.3 Class Exercise - “Views and Viewpoints - Simple Airport System”....................113
4.4 The 5 Business Architecture Views......................................................................114
4.5 The 5 Business Architecture Views......................................................................116
4.6 The Goals View.....................................................................................................117
4.7 Common Pitfalls when Setting Goals...................................................................118
4.8 Goal Prioritization.................................................................................................119
4.9 TOGAF's Goals View ..........................................................................................120
4.10 OMG's Goals View ............................................................................................122
4.11 OMG Business Motivation Model Details..........................................................123
4.12 SMART Goals.....................................................................................................125
4.13 Facades View......................................................................................................126
4.14 Facade's View - UML.........................................................................................127
4.15 Business Use Case Model .................................................................................128
4.16 More Complex Use Cases...................................................................................130
4.17 Facade's View – Functional Model ....................................................................131
4.18 TOGAF Functional / Facade Models..................................................................133
4.19 Additional Functional / Facade Models..............................................................135
4.20 The Communications View ................................................................................137
4.21 UML Communication Diagrams.........................................................................140
4.22 Processes View ...................................................................................................142
4.23 UML Activity Diagram ......................................................................................143
4.24 Business Process Model and Notation (BPMN) Process Models......................146
4.25 Business Entities View .......................................................................................148
4.26 Domain Modeling as a Business Entity View.....................................................149
4.27 Data Modeling as a Business Entity View .........................................................151
4.28 Summary.............................................................................................................152
Chapter 1 - What is Business Architecture?
Objectives
Key objectives of this chapter
 Business Architecture Definitions
 Business Architecture Frameworks' Common
Requirements
 Differences between a Business Architect and
Business Analyst
1.1 Defining Business Architecture

 A Business Architecture (BA) is an essential function of the Business that describes what it
does and how it does it to support organizational goals and objectives
 BA is a composite of business capabilities and business processes expressed in the form
of formalized artifacts
 It is a part of the Enterprise Architecture
7
1.2 Layers of the Enterprise Architecture

 Enterprise Architecture regards the Organization as a large and complex system of
interconnected sub-systems
 One way of reducing system complexities is to separate them into layers with their own
problem (architecture) domains
Source: Wikipedia.org
9
1.3 The Business Architecture Domain

 Within the Business Architecture Domain fall the following core components and activities
which reflect and help with the realization of the Organization's strategy and vision:
◊ Business Process design and modeling
◊ Business Requirements
◊ Business Rules
◊ Critical success factors
◊ Organization structure
10
1.4 The Values of Business Architecture

 The Value of Insight
◊ If you found 10% more funds to invest, where would be the optimum place to invest?
◊ If you needed to trim 5% from your operating costs, where would you look first?
◊ Without a model for how business gets done and an understanding of how your
business is structured (which are all artifacts of Business Architecture), these types of
decisions are very challenging
 The Value of Managed Change
◊ Process changes, organization changes, requirements changes, and comprehensive
strategy changes are a fact of business
◊ Business Architecture provides a baseline model to support and enable enterprise
changes without the usual chaos and confusion that is typically associated with
significant change
11
1.5 Relationship with Other Types of Architecture

 There are four domains of architecture recognized by most prominent architecture
frameworks
 Business Architecture is positioned at the top of the enterprise architecture stack driving
project activities downstream in support of the strategic and tactical business decision
 Business Architecture project activities must occur early in the life cycle of enterprise
projects in other architecture domains
 Other types of architecture must align with the Business Architecture
 Underlying Architectures provide upstream feedback helping fine-tuning standards,
business models and requirements
12
1.6 Other Pillars of Business Architecture

 In addition to the Technology supporting pillar, Business Architecture also depends on the
Human Resources and Business Processes of the Organization
 Company's Human Capital and Business Processes are accounted for in Business
Architecture and must be coherently aligned for realizing Enterprise Strategy and Vision
14
1.7 Formal Business Architecture

Common Problems Business Architecture Characteristics
 Difficult to interpret artifacts  No ambiguity
 Formal relationships
 Difficult to retrieve related artifacts
 Easy to make changes
 Difficult to maintain artifact consistency  Easy to find
 Part relationships not maintained
Source: Theodore Kahn's 2011 presentation to the OMG - “Formal Business Architecture”
15
1.8 Ownership vs Stewardship

 Business Architecture (BA) should be OWNED by the Business, even if it is actively
managed, or STEWARDED, by the technology team
◊ IT often serve as stewards (executors, servers) of business rules engines, process
modeling tools, databases, etc. which gives the illusion of ownership, while, ultimately,
those are paid for, created in support of and owned by the Business
◊ It may help to view BA as a joint effort between Business (owners) and IT (stewards)
17
1.9 Business Architecture Frameworks

 Business Architecture must be documented in and realized through some sort of an
Enterprise Framework which must:
◊ Capture the "essence" of the Business
◊ Be suitable for identifying technology needs
◊ Establish consistent vocabulary and notation
◊ Be product and technology agnostic
◊ Reflect multiple views of the enterprise
◊ Be comprehensive
◊ Provide for agile and cost-effective change
18
1.10 Enterprise Architecture Frameworks

 Enterprise Architecture (EA) Frameworks help deal with complexity and change
 We will review two popular EA frameworks as they apply to Business Architecture:
◊ Zachman
◊ The Open Group Architecture Framework (TOGAF)
19
1.11 Business Architect vs Business Analyst - 1/3

 To help further define Business Architecture, it may be useful to review the differences in
roles of a Business Architect and Business Analyst
 Noted Enterprise Architect Nick Malik (Enterprise Architect with Microsoft), provides the
following comparison between Business Architects and Business Analysts
Business Architect Business Analyst
Why To uncover the gaps between strategic needs of a To develop and document the detailed knowledge of a
business unit, and their abilities to meet those needs, business problem that an initiative has been chartered
and to charter initiatives to fill those gaps. to address.
How Analysis of future-looking strategies, capturing of Interviews with existing business stakeholders and
capabilities, and modeling of inter- and intra- business SMEs to elicit business rules, understand processes,
relationships needed to discover the key capability gaps information, and systems in use, and detailing the
that a business must be prepared to face, along with consequences (intentional or not) of making a
the development of cross-functional roadmaps to business change to address a specific issue. The
address them. System requirements are NOT captured. primary result of this activity is the document of
System Requirements.
20

When On-going process that is triggered by periodic strategy As-needed activity that is triggered AFTER a problem
cycles within a business has been identified and requirements for a solution are
needed.
Who Business or IT Generalists with a strong understanding Business or IT Generalists with a strong understanding
of business functional issues, interdependencies, and of information and application interdependencies,
business structural concerns. Must be excellent at requirements analysis, and system development
capability analysis. Must leverage modeling and methodologies. Must be excellent at IT requirements
rigorous analysis skills. elicitation. Must leverage modeling and rigorous
analysis skills.
What Business motivational models, Value Streams, Business Requirements, Business Rules, Use Cases,
Scenarios, Capability models, Heat Maps, Funding and Detailed Business Process descriptions
Maps, Risk maps
22

Scope Enterprise continuum / cross-domain Project / process
Focus Strategy / tactical / solution-neutral / holistic Solution and/or operation specific
Skills / Architecture methodologies / human relation Applied process engineering / task-oriented

Personality
24
1.14 Going Beyond the Process

 It is quite common to confuse Business Architecture with Business Process Modeling
(BPM) or business process management. The important thing to realize is that Business
Architecture will typically INCLUDE and even direct process improvement activities and
high-level end-to-end business process modeling, but will typically refrain from detailed
process modeling and management activities
 For many organizations, BPM is considered a subset of Business Architecture
 No formally recognized architecture framework or architecture discipline treats Business
Architecture and BPM as being synonymous
25
1.15 Summary
 There is a lot of confusion surrounding the role of Business Architecture
 A few universal aspects are broadly agreed upon with respect to business architecture
◊ It is essential
◊ It is a joint effort between Business and IT
◊ It occurs early in the architecture life cycle and drives and informs other downstream
architecture activities
◊ Business Architecture is not the same as Business Analysis
27
Chapter 2 - Enterprise Architecture Frameworks Overview
Objectives
The objectives of this chapter are:
 Review some of the popular Enterprise Architecture (EA)
frameworks
 Understand the role of an architecture framework
 Illustrate ways to combine elements of various frameworks
2.1 The Importance of a Framework for EA
Framework: A conceptual structure used to develop, implement, &

sustain EA.
 Frameworks provide structure
◊ Captures what others have found to work in real life
◊ Identifies essential & recommended elements
◊ Provides a meta-model for describing and organizing content
◊ Contains a set of resources for reuse
 Frameworks provide consistency
◊ Consistent terminology
◊ Consistent components
◊ Consistent processes / workflows
29
2.2 EA Framework Family Tree
MODAF 1.0 MODAF 1.2 TRAK

2005 2008 2010
DoD TRM DODAF 1.0 DODAF 1.5

1996 2003 2007
TAFIM TOGAF TOGAF 7 TOGAF 8 TOGAF 9

1991 1995 2001 2002 2009
Zachman Zachman Zachman Zachman

1987 2001 2003 2008
EAP FEAF FEAF

1992 1999 2003
EA Frameworks have matured over the past 26 years.
30
2.3 Group Discussion: Architecture Frameworks
 Have you adopted an architecture

framework?
 What solution development
methodologies do you use?
 Any other methodology frameworks in use
(e.g. ITIL, PMBOK)?
32
2.4 TOGAF
 The Open Group Architectural Framework (TOGAF™) is one of the most broadly accepted
and employed EA frameworks
 The Open Group is a global organization that aims to provide a vendor-neutral,
technology-neutral consortia focused upon standards and best practices
 TOGAF is a generic framework for developing architectures to meet different business
needs
 TOGAF has a comprehensive process framework
 TOGAF is meant to be customized for your environment to integrate with your existing
processes and capabilities
33
2.5 TOGAF Components

Modular Structure
Content Framework
Extended Guidance
TOGAF Capability Framework Architectural Styles
Additional ADM detail
Informs the Sets targets, KPIs,

capability Architecture Capability budgets for
Framework (Part VII) architecture roles
Ensures Realization
Drives need for
of Business Vision Architecture Capability
maturity
Business needs Architecture Development Delivers new

feed into method Method (Part II) business solutions
Business ADM Guidelines &

Refines Business
Vision and Techniques (Part III)
Understanding Capabilities
Drivers
TOGAF ADM &
Architecture Content Content Framework
Framework (Part IV)
Enterprise Continuum &

Tools (Part V)
Informs the Business Operational changes
TOGAF Reference cause updates
of the current state
Models (Part VI)
TOGAF Enterprise
Continuum & Tools
Slide 44 of 67
Source: [TOGAF9]
34
2.6 Architecture Development Method (ADM)

 An iterative methodology
 Systematically defines the baseline
(as-is) and target (to-be) states of the
enterprise
 Produces a roadmap that facilitates
the transformation toward the desired
future state
 Each iteration = new decisions:
 Enterprise coverage
 Level of detail
 Time horizon
 Architecture asset re-use:
 previous ADM iterations
 other frameworks, system
models, industry models,…
 Every phase is validated against and
validates the current requirements
Source: [TOGAF9
36
2.7 Architecture Content Framework

Architecture Content Framework can be viewed as a virtual repository for storing the output of
the Architecture Development Method (ADM). The key Architecture Content Framework
concepts are:
 A deliverable is a work product that is contractually specified and in turn formally
reviewed, agreed, and signed off by the stakeholders.
 An artifact is an architectural work product that describes an aspect of the architecture.
Artifacts are generally classified as:
 Catalogs (lists of things)
 Matrices (showing relationships between things)
 Diagrams (pictures of things)
 A building block represents a (potentially re-usable) component of business, IT, or
architectural capability that can be combined with other building blocks to deliver
architectures and solutions.
Building blocks can be defined at various levels of detail, depending on what stage of
architecture development has been reached.
38
2.8 Views & Viewpoints

Views are representations of the overall architecture in terms meaningful to
stakeholders. They enable the architecture to be communicated to and
understood by the stakeholders, so they can verify that the system will address
their concerns.
39
2.9 TOGAF Viewpoints
Source: [TOGAF9]
41
2.10 Catalogs, Matrices, Diagrams & Viewpoints
Viewpoint
Based on/ instance of
Deliverable Contains 1 to many Views Satisfies Stakeholder Needs
Based on
Catalogs Matrices Diagrams
44
2.11 Architecture Deliverables

TOGAF defines architectural deliverables and provides templates for many of these
deliverables:
 Architecture Contract  Communications Plan
 Architecture Definition Document  Compliance Assessment
 Architecture Principles  Implementation & Migration Plan
 Architecture Requirements Specification  Implementation Governance Model
 Architecture Roadmap  Organizational Model for EA
 Architecture Vision  Request for Architecture Work
 Capability Assessment  Statement of Architecture Work
 Change Request  Requirements Impact Assessment
 Compliance Assessment
46
2.12 ADM Techniques

The techniques support specific tasks within the ADM:
 Architecture Principles
 Stakeholder Management
 Architecture Patterns
 Business Scenarios & Business Goals
 Gap Analysis
 Migration Planning
 Business Transformation Readiness Assessment
 Risk Management
47
2.13 Enterprise to Solution Architecture
Source: [FEAF]
Note: Enterprise Architecture (FEAF) = Strategic Architecture

(TOGAF)
53
2.14 Zachman Framework

 In essence, the Zachman Framework is a schema of an intersection between two
classifications, typically depicted as a bounded 6 X 6 matrix
 Columns asks the questions:
 What column = Data
 How column = Function
 When column = Time
 Who column = People
 Where column = Network / Location
 Why column = Motivation
 Rows represent the transformation of an abstract idea into an instantiation:

 Planner row = Identification
 Owner row = Definition
 Designer row = Representation
 Builder row = Specification
 Sub-contractor row = Configuration
 Functioning enterprise row = Instantiation
 Each cell is a different view or model identified and targeted for a different audience
55
2.15 Zachman Framework Matrix Overview
Zachman Framework – 2003
57
2.16 The Scope of the Zachman Framework

 The Zachman Framework is also an ontology
◊ provides consistent terminology
◊ provides a context for concepts and describes their relationships with each other
◊ identifies essential elements and any dependencies that exist with other elements
defined within the framework
 Note: The popular in business 5W-1H (Why, Who, What, Where, When and How) project
scoping technique maps directly into Zachman
◊ A variant of this technique, called 5W-2H (How and How much), takes into account the
variable cost dimension of the project
59
2.17 What the Zachman Framework is NOT

 The Zachman Framework is NOT a methodology, there is
◊ No EA processes for creating, evaluating, governing, or otherwise processing artifacts is
defined
◊ No guidance regarding long-term / short-term trade-offs or other decision-making
support is provided
◊ No roadmapping, strategic planning, or similar transformative mechanisms are defined
60
2.18 TOGAF Artifacts Using the Zachman Framework
Source: [TOGAF]
61
2.19 Leveraging the Zachman Framework

 Zachman provides a context for concepts and their relationships with each other and is
useful as a reference framework to:
 Identify key stakeholder perspectives
 Identify levels of abstractions
 Identify architecture catalogs
 Identify architecture matrices
 Identify architecture diagrams
63
2.20 Federal Enterprise Architectural Framework (FEAF)
Source: [FEAF]
 FEAF provides a common methodology for IT acquisition, use, and disposal in
the U.S. Federal government.
 Enables agencies to define and implement a strategic vision, moving toward a
desired future-state architecture, employing well-defined architectural segments
rather than a big-bang style implementation.
64
2.21 Leveraging FEA
 FEAF uses a concept called a Reference Model that is used to

classify architecture artifacts.
 These reference models have been used by many organizations to
classify their architecture assets, effectively creating Building Blocks.
Source: [FEAF]
66
2.22 Some Other Frameworks

 The Department of Defense Architecture Framework (DoDAF)
◊ Includes a set of operational views which details the customer's operating environment
in which the system will operate.
◊ Is underpinned by a defense-specific meta-model for the representation and exchange
of datasets.
 The British Ministry of Defense Architecture Framework (MoDAF)
◊ Based on DoDAF with a number of important changes:
 Adds three additional viewpoints: acquisition, services, and strategic
 With version 1.1 of MoDAF, human elements were introduced to the Systems views
 TRAK
◊ Based on MoDAF with all domain-specific content of MoDAF removed.
◊ Released under an open source license in February 2010.
68
2.23 Which Framework Should I Use?

 No framework is perfect; they all have drawbacks.
 It is important that each organization decide for themselves which framework makes the
most sense for their enterprise.
 Select your primary framework and supplement it with processes, techniques, views, and
other useful items from other frameworks and methodologies.
 Many organizations adopt TOGAF as the foundation framework since:
 It provides a complete process framework
 It is vendor-neutral
 Information and training is widely available
 Then supplement it with best practices from other frameworks (e.g. Zachman, FEAF),
industry books of knowledge (e.g. EABOK, BABOK, DMBOK) and other industry practices
(e.g. IEEE, SEI, CISR).
69
2.24 Summary
71
Chapter 3 - Introduction to BPMN
Objectives
This chapter will cover the following topics:
 Identify what BPMN is and why it is important
 Examine the relationship between BPEL and BPMN
 How to model a process using BPMN
 Examine various elements defined by BPMN
3.1 What is BPMN?

 Developed and maintained by the Object Management Group (OMG), the Business
Process Modeling Notation (BPMN) is a vendor neutral standard.
◊ The key goal is to standardize the graphical notations (icons) used to describe a
process map.
◊ It is akin to the Activity Diagram from the Unified Modeling Language (UML), also
maintained by OMG.
 BPMN tries to make sure that a wide variety of audiences, from business users to software
developers, can easily understand a process.
◊ In Business Process Management (BPM) a process model is used to comprehend an
otherwise complex process. It is expected that BPMN will help you achieve that goal.
73
3.2 What does BPMN include?

 BPMN also includes various best practices of process mapping. It is expected that by
following BPMN you will inherently follow many of these guidelines.
 BPMN covers process mapping only. It does not discuss any way of capturing attributes
such as roles, responsibilities, skills, duration and cost of activities.
◊ It is expected that a vendor's tool will provide these features.
◊ BPMN does not standardize simulation or KPI metric definition.
74
3.3 The Eye of the Beholder

 Software developers and business analysts look at a process in different ways.
◊ The analyst wishes to describe the process to others so they can understand the
process. The level of details is as much as necessary for communication.
◊ The developer needs to run the process as software and require far more rigorous and
complete definition of the process.
 For example…
◊ The structure of the input and output data and the exact conditional logic for alternate
flows must be defined by developers.
◊ For an analyst it is sufficient to provide a general description of the input and output
information, business rules, as well as plain English descriptions of the conditional logic.
75
3.4 BPMN and BPEL

 While BPMN is well suited for process description, BPEL is meant to model the process fit
for software development. Consequently, a BPMN model must be converted to BPEL.
 This process can be difficult and time consuming. Not because BPEL is poorly designed,
but, because converting general descriptions to software is inherently complicated.
 Every time a BPMN process is altered (due to optimization effort), the conversion to BPEL
has to be repeated.
 To ease the pain, BPMN provides guidance on how a BPMN model should be converted
to BPEL. Various automated tools exist to further simplify the process.
76
3.5 Basic Structure of a Process

 The final deliverable of process mapping is the process definition.
 A process is made up of these components:
◊ Tasks or activities that are performed by people, software or tools.
◊ The flow or sequence of tasks, called connections in BPMN. This defines what happens
after what.
◊ Subprocesses. They are mini processes that are used by the main processes.
◊ Flow control logic, called gateways, such as loops and conditional execution of a
sequence.
◊ The input (data or things) required by the process or a task.
◊ The output (data, service or product) produced by a process or a task.
◊ Events that start a process, cancels it, reports an error condition or fires a timer.
78
3.6 Basic Structure of a Process

 A task is represented by a rounded rectangle. A subprocess is a rounded rectangle with +
sign.
 The start event is a circle. The end event is a thick circle.
 A sequence flow connection is a solid line with an arrow. The direction of the arrow defines
the sequence.
79
3.7 The Start Event

 When a certain event takes place within the business, a new instance of the process is
started. You should always model the start event for a process. This clarifies an important
detail.
 Common reasons for starting a process are:
◊ An external software or business has sent a message. For example, a client company
has sent a new order message.
◊ The process needs to start on a schedule and the scheduled time has arrived. For
example, every night at 10PM check for product inventory and place orders for items
running low.
◊ When a business rule evaluates to true. For example, begin selling stocks when the
price reaches a certain high.
 In a more complex case, a process can start when any one of a number of possible events
take place.
80
3.8 Normal End Events

 A process can end regularly or with an error condition.
 A process with many alternate branches can have many end events.
 You should always clearly model the end event to show where a process can possibly
end.
 When the process ends regularly, a reply message can be sent to the external software or
organization that started the process instance.
 In a complex case, an ending the process can have multiple consequences. For example,
several messages are sent out. generally avoid this construct as it will be difficult to model
this in BPEL.
82
3.9 Abnormal End Events

 If an error condition is detected while a process instance is running, you have two choices:
◊ Deal with the problem and move on.
◊ The problem can not be properly dealt with. In that case clean up the work that is
already done and end the process.
 There are two ways to end the process:
◊ Simply terminate it. This is done using the Terminate end event.
◊ End the process and report error details to the consumer of the process that started it.
This is done using the Error end event.
 Because BPEL allows only one end event per process, you should follow the same in
BPMN. For additional ways to normally end a process use the terminate event.
84
3.10 Intermediate Events

 Certain events can take place within the business after the process has started that can
change the course of the process.
◊ For example, after the process sends an order for a part, it needs to wait for the delivery
before manufacturing can begin.
 These events are modeled as intermediate events.
 Two most common intermediate events are:
◊ Message event – This event occurs when a software or business external to the
process sends the process a message. For example, when a part is received a staff can
record the receipt in a software. The software can then send a notification message to
the process that is waiting for the message.
◊ Timer event – Cause the process to wait for a certain amount of time.
85
3.11 Gateways
 A process can have multiple branches of flow for two primary reasons:
◊ Conditional execution: A sequence of tasks need to be performed only if certain
conditions exist.
◊ Parallel execution: A few activities do not depend on each other and can be performed
in parallel.
 BPMN uses gateways to model multiple branches of execution. Gateways initiate multiple
branches and re-join them in the main flow.
 There are several types of gateways all drawn using a diamond with an icon (see note
below).
86
3.12 Exclusive Condition

 Sometimes a process must choose one of many paths based on the current state of the
business.
◊ Example: the return handling process will need to check if touch up of a product is
necessary before asking an employee to fix up and repackage the item. Similarly, only if
the package was damaged during shipping will an insurance claim be filed with the
shipping company.
 To model the choice of exactly one of many possibilities, use the Exclusive gateway. It is
modeled using a plain diamond or a diamond with X inside.
◊ Two or more branches can come out of this gateway, each with a condition.
 During process execution if the condition of a branch is met, the branch is executed. Only
one branch can be executed. Note: See warning below.
 You can specify a default branch that will be executed when conditions for no other branch
is met.
88
3.13 Exclusive Condition Examples
90
3.14 Parallel Execution

 In some cases the process can be optimized by doing things in parallel. You can do that
only when the activities in parallel branches do not depend on each other.
◊ Also make sure that these activities don't use common resources (such as people,
machine, or vehicle). Otherwise, while an activity is using the resources another activity
in another branch will have to wait. This nullifies the advantage of having parallel
branches.
 You can model parallel branches using the parallel gateway. It is a diamond with a +
inside.
 All branches coming out of a parallel gateway are executed. Essentially, a parallel gateway
is same as an inclusive gateway with every branch condition set to true.
92
3.15 Modeling Roles & Responsibilities

 The tasks in a process can be done by people or software within the organization or by a
separate organization.
◊ For example, when you send a request for price quote to a supplier, the work to prepare
a response is done by the supplier organization.
 BPMN allows us to model the roles using swimming pools and lanes.
◊ There can be one or more pools. Each pool has one or more lanes.
 The idea is that a pool stands for an organization or a division independent enough to
have its own business process. A lane stands for people or department within an
organization.
 Typically a business process is modeled entirely within one pool. If that process works in
conjunction with another company's process, the external processes are modeled in
separate pools.
◊ In this way, multiple pools can be used to very effectively show business to business
(B2B) interaction.
94
3.16 Using Swim Lanes
96
3.17 Modeling B2B Interaction

 In advanced levels of process maturity, the processes of an organization work in
conjunction with the processes of other groups.
◊ The activities within these processes proceed in a well choreographed sequence.
Processes become interlinked and are no longer independent.
 A common interaction pattern goes as follows:
◊ A process from business A asks business B to do something and waits for a completion
notification. Business B starts off a process to get the job done and replies back to the
first process. The first process then proceeds.
 A few things to note about a B2B interaction:
◊ One of the processes initiate an interaction. It is called the initiator. The other process is
called the participant. The initiator sends a request to the participant. At a later time, the
participant sends a reply back to the initiator. The initiator needs to wait for this reply.
◊ The first request from the initiator typical launches the participant process.
◊ The inner workings of the participant process is completely hidden from the initiator and
vice versa. They can only send each other messages.
◊ There can be many interactions between two processes. In a complex situation the role
of the initiator and participant can switch.
98
3.18 Trading Partner Design Pattern
100
3.19 Modeling B2B Interactions

 In BPMN, each process (initiator and participant) is drawn inside a separate swimming
pool.
 A process interacts with another by sending it a message. A message connection is drawn
using a dashed line with a circle at the source end and an arrow at the target end.
◊ You never use a normal sequence flow connection (solid line with arrow) between two
processes. This type of connection is meant to connect two tasks in a single process.
 The initiator process uses a regular task to send a request message to the participant. It
should use a intermediate message event to wait for the reply.
 The participant uses a message event to wait for a request message. In most cases, the
first request starts the participant. In that case, make sure that you use a start message
event. The participant uses a regular task to send the reply back.
 An example is shown next…
101
3.20 B2B Interaction Example
103
3.21 Summary
 BPMN provides a standardized notation for visual process models
 BPEL defines the runtime execution of a business process (and may have originally been
derived from a BPMN model)
 BPMN defines a variety of process constructs in a vendor-neutral and platform-neutral
fashion
◊ Tasks or activities that are performed by people, software or tools.
◊ The flow or sequence of tasks, called connections in BPMN.
◊ Gateways such as loops and conditional execution of a sequence.
◊ The input (data or things) required by the process or a task.
◊ The output (data, service or product) produced by a process or a task.
◊ Events that start a process, cancel it, report an error condition or fire a timer.
105
Chapter 4 - Business Architecture Views
Objectives
Key objectives of this chapter
 The 5 Business Architecture Views
 The Goals View
 The Facades View
 The Communications View
 The Processes View
 The Business Entities View
4.1 The Importance of Architecture Views

 What is an Architecture View?
◊ The concept of a 'view' is an important aspect of every architecture discipline, although
the precise composition of views differs from one approach to another.
◊ A view gives you a slice of the overall system in order to focus upon a subset of system
concerns that are relevant to a particular stakeholder or stakeholder group.
 TOGAF defines the following terms:
◊ Concern – key interests that are crucially important to stakeholders, and determine the
acceptability of the system
◊ View - a representation of a system from the perspective of a related set of concerns
◊ Viewpoint - defines the perspective from which a view is taken
107
4.2 Describing Architecture through Views
111
4.3 Class Exercise - “Views and Viewpoints - Simple Airport System”

 The pilot has one view of the system, the air traffic controller has another.
 Neither view represents the whole system.
 The perspective of each stakeholder constrains how they see the overall system.
 Questions:
◊ Name some elements in the pilot’s view not viewed by the controller
◊ Name some elements in the controller’s view not viewed by the pilot
◊ Name some shared elements
◊ Describe 2 viewpoints for this system
◊ Why is using viewpoints helpful?
113
4.4 The 5 Business Architecture Views

 We are going to explore the domain of Business Architecture through 5 sets of views:
◊ The Goals View (targets that the business is aiming to achieve)
◊ The Facades View (highlights who interacts with the business and what business
functionality is available to them)
◊ The Communications View (ensure that the right information gets to the right people
or organizations in a timely fashion)
◊ The Processes View (identify the activities to be performed and ensure they are
performed in the right order and at the right time)
◊ The Business Entities View (articulate the key nouns and their relationships to one
another)
114
4.5 The 5 Business Architecture Views
116
4.6 The Goals View

 The Goals View establishes a clear and concise target for the
business to achieve.
 All other decision-making within the architecture activity hinges upon
alignment with goals that have been established.
 A mission statement helps with establishing the Goals View of the
Company.
 As you diagram the goals, you may find that they are best organized
into a hierarchy. There are a variety of viable goal hierarchies
◊ Enterprise / department / business unit / team
◊ Strategic / tactical / operational
◊ Drivers / goals / objectives
117
4.7 Common Pitfalls when Setting Goals

 Lack of communication - Goals must be effectively, consistently, and comprehensively
communicated to the organization.
 Conflicting goals – If the business team sets competing goals or a subset of the
organization has goals which conflict with the broader enterprise, then you get inefficiency
in the best case scenario and produce a toxic work environment in the most extreme of
cases.
 Goal proliferation – If you try to accomplish too many things all at the same time, you run
the risk of not doing any of them especially well. Goal prioritization is essential in order to
achieve significant progress.
118
4.8 Goal Prioritization

 If there are more than a few main goals that the business wants to pursue, it will need to
prioritize them and determine which ones are most worthy of immediate pursuit.
 Typically, stakeholders claim that “everything is a priority”, but this is unrealistic and is a
recipe for failure.
 Think of it this way, let's assume we will NOT design a system that is:
◊ Insecure
◊ Performs badly
◊ Hard to identify and resolve errors
◊ Expensive to maintain
◊ Complicated to modify
◊ Hard to integrate with
 Assuming that all of the basic requirements are met to a minimal level of quality, then what
is the priority…?
119
4.9 TOGAF's Goals View

 One Goals View is defined by TOGAF in the form of a Business Motivation Model
consisting of Goals, Drivers, and Objectives.
◊ Drivers (internal / external motivating condition)
◊ Goals (high-level statement of intent or direction)
◊ Objectives (time-bounded milestone to demonstrate progress toward a goal)
120
4.10 OMG's Goals View

 OMG Defines a Business Motivation Model (BMM)
◊ Initially developed by the The Business Rules Group (BRG) in 2008
◊ BMM Version 1.1 was published in May 2010
 The BMM provides an organized approach for developing, communicating, and managing
business plans in a structured manner.
◊ Ends – WHAT the business wants to achieve.
◊ Means – HOW the business intends to achieve its ends.
◊ Directives – CONSTRAINTS to guide the governance of the means by way of rules
and policies.
◊ Influencers – CHANGES that affect the organization's ability to carry out its means and
achieve its ends (influencers are neutral).
◊ Assessment – JUDGEMENT of some Influencer that affects the organization's ability to
employ its Means or achieve its Ends. It expresses a logical linkage between which
Influencers are relevant to which Ends and/or Means.
122
4.11 OMG Business Motivation Model Details
123
4.12 SMART Goals

 Regardless of the model you choose for the Goals View, it is recommended that any goals
you define are S.M.A.R.T.
 Specific - defines what needs to be done to done in the business
 Measurable - has clear metrics for success
 Actionable - clearly segments the problem, and provides the basis for finding a solution
 Realistic - defines the bounds of technology capability and cost constraints
 Time-bound - gives a clear understanding of when a solution expires
125
4.13 Facades View

 The Facades View defines the various abstractions that will need to
be defined to represent different interfaces or touch-points for the
system.
 Multiple faces or facets are presented to various clients and
connections, representing the set of functionality that they are able to
access.
 In the Facades View, you want to ensure that your business
functionality aligns with your stated goals from Goals View.
126
4.14 Facade's View - UML

 One of the most readily recognizable representations of the Facades view is in the form of
Unified Modeling Language (UML) diagrams.
◊ Business Use Case – A textual description of a complete end-to-end set of activities
that constitute recognizable value for a customer or end user (typically a one-to-one
mapping with a business process boundary).
◊ Use Case Diagram – Graphically elaborates system behavior, the interaction between
actors and the system, and the relationships between inter-related sets of functionality
and system actors.
◊ Actor Catalog – As you are capturing business use cases with corresponding
diagrams, it is helpful to also collect a record of all primary and secondary actors within
the system context.
 By creating one or more UML use-case diagrams with business use cases and business
actors, you can build up a representation of each facade of the business.
127
4.15 Business Use Case Model
 The collection of actors and the use cases represent the Use-Case model.
128
4.16 More Complex Use Cases

 UML supports complex forms of Use Case relationships where use cases can:
◊ Include other use case(s)
◊ Extend other use case(s)
◊ Use other use case(s)
 The relationship is depicted by a dashed arrow between the use cases with a label (called
a stereotype) surrounded by double angle brackets
◊ Example: That's how you can express the fact that Use Case A includes Use Case B
◊ The "Extended" relationship arrow points in the direction of the use case(s) being
extended
130
4.17 Facade's View – Functional Model

 At the heart of the Facade View is the desire to express business functionality and the
internal and external interaction points for this functionality set.
 There are three primary types:
◊ Capability models support business functionality threads that run through multiple lines
of business
◊ Service models drive toward reuse, composite solutions, and promote contract-driven
interfaces
◊ Function models promote a componentized view of the enterprise and support
modularity
131
4.18 TOGAF Functional / Facade Models

 Business Footprint Diagram - Describes the links between business goals,
organizational units, business functions, and services, and maps these functions to the
technical components delivering the required capability. A Business Footprint diagram
provides a clear traceability between a technical component and the business goal that it
satisfies, while also demonstrating ownership of the services identified.
 TOGAF’s Business Service / Function Catalog – Identifies organizational capabilities
and demonstrates the relationship between business services and technology functions.
Furthermore, it can be mapped against organizational units to demonstrate ownership of
business services.
 TOGAF’s Functional Decomposition Diagram – Provides a graphical depiction of the
information captured in the Business Service / Function Catalog (see above). Also
provides a very natural mechanism for eliciting the technical capabilities necessary to fulfill
business needs. One unique facet of this diagram is that it can easily illustrate shared
components (which are more challenging to represent with a catalog artifact).
133
4.19 Additional Functional / Facade Models

 OMG’s Business Capabilities View – Describes business activities, aligned against the
organization that delivers that function (much like the other capability mechanisms). One
unique element of this view is the categorization and depiction of functions as customer-
facing, supplier-facing, management-focused, and execution-centric.
 MODAF’s Strategic Views – Define a whole range of capability artifacts. Typically
MODAF is a better fit for highly technical engineering environments with heavy system
integration requirements. Additionally, a non-defense meta model would have to be
crafted to retrofit this for non-defense organizations that chose to use MODAF. The
extensive set of integrated capability artifacts is still worth exploring either for direct usage
or to inspire a custom solution for the enterprise.
135
4.20 The Communications View

 The Communications View focuses upon all internal and
external parties that are affected by and are interested in the
system and ensure that they are duly informed of any and all
relevant information.
 Two primary targets of communication
◊ Internal – communication regarding goals as well as policies
and constraints
137
◊ Contextual – communication extending beyond an

organization's internal departments and involving contextually
relevant systems (both internal and external), partners,
suppliers, and customers
138
4.21 UML Communication Diagrams
140
4.22 Processes View

 The Processes View represent repeatable tasks along with
sequencing and conditional execution paths.
 Processes are probably the most well-understood elements of
Business Architecture.
 On the other-hand, processes are also one of the most broken
areas of business architecture within an organization.
 In elaborating the Processes view, you want to ensure that your
processes are aligned with the interactions you have in your
facades (which in turn support your goals).
142
4.23 UML Activity Diagram
143
Source: Chris Reynolds, Introduction to Business Architecture (2010)
144
4.24 Business Process Model and Notation (BPMN) Process Models
146
4.25 Business Entities View
 The Business Entities View rounds things out with a look at the
information model which is so critical to the operation of the
organization and its processes in particular.
 As businesses become more focused on using information, it
becomes more important to understand what information they will be
manipulating.
 Business entities are the information “things” that get manipulated,
stored, and acted upon by the business.
148
4.26 Domain Modeling as a Business Entity View

 Domain models capture the main business entities and the relationships between them.
149
4.27 Data Modeling as a Business Entity View
151
4.28 Summary
 Views are an important part of describing architecture. A view gives you a slice of the
overall system in order to focus upon a subset of concerns that are relevant to a particular
stakeholder or stakeholder group.
 There are 5 Business Architecture views, as illustrated in this diagram:
152

Business Architecture Fundamentals

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Architecture Fundamentals

Uploaded by

Copyright:

Available Formats

Business Architecture

Web Age Solutions Inc.

Copyright © 2014 Web Age Solutions Inc.

1.1 Defining Business Architecture

1.2 Layers of the Enterprise Architecture

1.3 The Business Architecture Domain

1.4 The Values of Business Architecture

1.5 Relationship with Other Types of Architecture

1.6 Other Pillars of Business Architecture

1.7 Formal Business Architecture

1.8 Ownership vs Stewardship

1.9 Business Architecture Frameworks

1.10 Enterprise Architecture Frameworks

1.11 Business Architect vs Business Analyst - 1/3

1.12 Business Architect vs Business Analyst - 2/3

1.13 Business Architect vs Business Analyst - 3/3

Focus Strategy / tactical / solution-neutral / holistic Solution and/or operation specific

Skills / Architecture methodologies / human relation Applied process engineering / task-oriented

1.14 Going Beyond the Process

2.1 The Importance of a Framework for EA

Framework: A conceptual structure used to develop, implement, &

2.2 EA Framework Family Tree

MODAF 1.0 MODAF 1.2 TRAK

DoD TRM DODAF 1.0 DODAF 1.5

TAFIM TOGAF TOGAF 7 TOGAF 8 TOGAF 9

Zachman Zachman Zachman Zachman

EAP FEAF FEAF

EA Frameworks have matured over the past 26 years.

2.3 Group Discussion: Architecture Frameworks

 Have you adopted an architecture

2.5 TOGAF Components

Informs the Sets targets, KPIs,

Business needs Architecture Development Delivers new

Business ADM Guidelines &

Enterprise Continuum &

2.6 Architecture Development Method (ADM)

2.7 Architecture Content Framework

2.8 Views & Viewpoints

2.9 TOGAF Viewpoints

2.10 Catalogs, Matrices, Diagrams & Viewpoints

Based on/ instance of

Deliverable Contains 1 to many Views Satisfies Stakeholder Needs

Catalogs Matrices Diagrams

2.11 Architecture Deliverables

2.12 ADM Techniques

2.13 Enterprise to Solution Architecture

Note: Enterprise Architecture (FEAF) = Strategic Architecture

2.14 Zachman Framework

 Rows represent the transformation of an abstract idea into an instantiation:

2.15 Zachman Framework Matrix Overview

Zachman Framework – 2003

2.16 The Scope of the Zachman Framework

2.17 What the Zachman Framework is NOT

2.18 TOGAF Artifacts Using the Zachman Framework

2.19 Leveraging the Zachman Framework

2.20 Federal Enterprise Architectural Framework (FEAF)

2.21 Leveraging FEA

 FEAF uses a concept called a Reference Model that is used to

2.22 Some Other Frameworks

2.23 Which Framework Should I Use?

3.1 What is BPMN?

3.2 What does BPMN include?

3.3 The Eye of the Beholder