A classification of skills based on the enterprise reality

1
A classification of skills based on the
enterprise reality
 Theory without practice is useless practice
without theory is blind.  Immanuel Kant

• The Interdisciplinary Ensemble of Disciplines
  (TIED)

2
Presentation objective

• Objective
• Topics
• Enterprise Architecture, Business Architecture
• Enterprise transformation
• Methodology

Specify and link together the disciplines
involved in the enterprise transformation
Duration 30 min
Document protection
3
Content

1. The available definitions of the disciplines
2. A comprehensive approach to the enterprise
3. Inference of the disciplines and their relations

4
The available definitions
1

• Definitions that come from various sources
• TOGAF
• BABoK
• ISO

5
TOGAF Definitions

• Architecture
• A formal description of a system, or a detailed
  plan of the system at component level, to guide
  its implementation
• (source ISO/IEC 420102007).
• The structure of components, their
  inter-relationships, and the principles and
  guidelines governing their design and evolution
  over time.
• Business Architecture
• The business strategy, governance, organization,
  and key business processes and information, as
  well as the interaction between these concepts.

6
Enterprise Architecture in TOGAF

• What Kind of Architecture Does TOGAF Deal With?
• There are four architecture domains that are
  commonly accepted as subsets of an overall
  enterprise architecture, all of which TOGAF is
  designed to support
• The Business Architecture defines the business
  strategy, governance, organization, and key
  business processes.
• The Data Architecture describes the structure of
  an organization's logical and physical data
  assets and data management resources.
• The Application Architecture provides a blueprint
  for the individual application systems to be
  deployed, their interactions, and their
  relationships to the core business processes of
  the organization.
• The Technology Architecture describes the logical
  software and hardware capabilities that are
  required to support the deployment of business,
  data, and application services. This includes IT
  infrastructure, middleware, networks,
  communications, processing, standards, etc.
• Extract from TOGAF v. 9

7
BABoK Definitions

• Business Analysis
• Business analysis is the set of tasks and
  techniques used to work as a liaison among
  stakeholders in order to understand the
  structure, policies and operations of an
  organization, and recommend solutions that enable
  the organization to achieve its goals.
• Business Architecture
• A subset of the enterprise architecture that
  defines an organizations current and future
  state, including its strategy, its goals and
  objectives, the internal environment through a
  process or functional view, the external
  environment in which the business operates, and
  the stakeholders affected by the organizations
  activities.
• Enterprise Architecture
• Enterprise architecture is a description of an
  organizations business processes, IT software
  and hardware, people, operations and projects,
  and the relationships between them.

8
Discussion

• Flaws of the definitions
• No attempt to link the concepts together
• The meaning of a term stems from its position
  inside a semantic network
• Mainly definition by content
• A set of
• Typical of a bottom-up approach
• Consequences of insufficient definitions
• Confusion
• Lack of coordination between disciplines
• Criteria
• Aspects of the Enterprise
• Business (knowledge, activity) versus support
  (logistics, IT)
• Reach of the endeavor
• Local (application, service, department,
  function) vs overall (entire system)
• Time frame
• Short-, medium-, long terms

9
A comprehensive approach to the enterprise
2

• If enterprises are deemed complex systems, how
  should we address them?
• What should be represented?
• How should we deal with the amount of information
  to be collected and the decisions to be made?
• Notion and value of a methodological framework
• Separation of concerns principle
• Mindset related to every framework

10
Business the right description
Semantic aspect

• Approach by activities
• Classical approach
• Flawed with local variation
• Functional hierarchical breakdown structure
• Semantic modeling
• Additional approach
• Move to genericity
• New solution to cope with complexity

Objects
Business objects, real objects (InformationTransf
ormationAction)
Refers to
Pragmatic aspect
Activities
Actors organizational entitiesProcess
use-cases
11
Software the optimal structure
Semantic aspect
Logical aspect

• Determine the software structure from the
  business description
• Applying MDA standard
• Independently from technical choices
• Technical Target free
• Long term

Objects
Logical services aggregates (logical machines)
Derives
Business objects, real objects (InformationTransf
ormationAction)
Pragmatic aspect
Activities
Derives
Actors organizational entitiesProcess
use-cases
SOA
12
Logical architecture the change
Caricature of an architecturebased upon
functional approach
Outlined logical architectureaccording to
Praxeme method
FD
FD
FD
FD
OD
OD
OD
BO
OD
OD
BO
FD
FD
FD
FD
Logical blocks take charge of functional
domains which structure the pragmatic
model. Important dependencies or redundancies
stem from this, as the same business objects are
usedinside many functional domains.

• Several logical blocks match with the object
  domainsfrom the semantic model.
• Dependencies obey topological constraints
• Between strata (Business Core, Organization,
  Interaction)
• Coupling reduced,
• No dependency between FD, unless special cases,
• etc.

FD functional domain BO business object OD
object domain
13
The Enterprise System Topology
Political aspect
14
Dependencies between aspects
translates
derives from
Software
Logical Aspect
Semantic Aspect
0..1
0..
0..1
0..
kernel source
specification
implementation
0..1
0..1
0..
knowledge
result
configuration
0..1
refers to
derives from
applies
activity
0..
Technical Aspect
Pragmatic Aspect
0..1
guideline
periphery source
hosts
possibility
0..1
0..1
organization
distributes
considers
constrains
location
determination
0..
projection
0..1
0..1
equips
Geographic Aspect
Hardware
Physical Aspect
fills
0..1
0..1
0..1
0..1
geography
logistics
space
content
15
Inference of the disciplines
3

• Given the content framework
• Which guides our approach to the enterprise
• how can we define the disciplines needed?
• In accordance with the natural structure of the
  Enterprise System

16
Architecture

• A metaphoric use of the term
• Business Architecture, Enterprise Architecture,
  IT Architecture, etc.
• Usual meaning
• The art and study of designing buildings
• The design or style of a building or buildings
• Source Oxford Dictionary
• In our context
• A discipline that deals with the enterprise or an
  aspect of the enterprise as a whole and
  establishes the high-level decisions needed
• Architecture is about the main decisions that
  structure and transform the system
• Preliminary questions
• Which aspects?

17
xxx Architecture

• Enterprise Architecture
• The discipline of architecting the enterprise
• This definition applies to the object of the
  enterprise
• Business Architecture
• Part of the Enterprise Architecture that focuses
  on the business aspects
• According to the Enterprise System Topology,
  there are three business aspects that must be
  isolated for a proper description semantic (core
  business knowledge), pragmatic (action),
  geographic (location)
• See slide 21
• IT Architecture

18
Another approach to the concept

• The Enterprise Transformation Manifesto
• The golden principles for improving
  enterpriseswhile respecting society's
  fundamental values and interests
• Meant for decision-makers
• www.enterprisetransformationmanifesto.org

19
Overview 7 chapters
20
Enterprise transformation

• Disciplines involved

Transformation
Strategy elaboration
Management
Operation
21
Clarifying responsibilities
IT view
Business view
Logical Architect
Business Architect
Business Analyst
Organization designer
Technical Architect
Strategist
22
Roles related to business description

• Business Architect
• The one who makes the overall decision and is the
  guardian of the long-term vision
• Business Analyst
• Involved in operations (projects), brings the
  details
• Business Designer
• The mandate for creating new business practices
  must be explicit
• Need to distinguish both roles? (analysis versus
  design)
• Business Expert
• They have the knowledge, not necessarily the
  skills for expressing it in the right way
• Modeler
• They master the techniques of representation, not
  necessarily the content (the knowledge)
• Can be specialized (by aspects)

23
Business Architecture Analysis

• As a result, Praxeme situates the disciplines of
  BAs against the Enterprise System Topology

Exclusiveresponsibility ownership
Contribution
Possible negotiation
24
Recap

• Business Architecture
• Overall view
• Decision making at the system level
• Business Analysis
• Detailed view
• Expressing the business knowledge, describing the
  business practices
• Business Design
• Praxeme encourages design in matters of business
• Organizational innovation
• Innovation in terms of business concepts

25
Responsibilities of business architecture/analysis
/modeling

• Take into account the general directives
  (strategy)
• Understand the business practices, needs,
  opportunities
• Anticipate the changes
• Describe the business in such a way that
• The business knowledge is captured and protected
• The description can be easily enacted by other
  actors (e.g., IT designers)

26
Relation between BA BA

• Business Architecture
• Establish the frame
• In line with the corporate strategy
• Administrate the repositories
• Promote the best practices
• Select and link the investments in accordance
  with priorities

• Business Analysis
• Assess the overall decisions
• Coping with constraints at grassroots level
• Fill the frame and repositories
• Project after project
• Benefit from synchronization between investments

27
Two levels of action
Strategic analysis
Visioning
Projects
Monitoring
Solution
Need
Overalldesign
Consolidation
28
Conclusion
The Interdisciplinary Ensemble of Disciplines ?

• Towards the right definitions of disciplines
• The Enterprise System is the only valid starting
  point
• Better than the current practices
• Need for a comprehensive methodology
• Enterprise Architecture ought to live up to its
  more ambitious definition
• The indispensable link between strategy and
  transformation
• To stay informed
• The Praxeme Institute web site
• www.praxeme.org
• List for major announcements
• http//groups.google.com/group/Praxeme-Annonces