Categorieën: Alle - capabilities - integration - standardization - diversification

door aurelio ravarini 12 jaren geleden

318

Management of Enterprise Architectures 2009

Management of Enterprise Architectures 2009

from BPRto BPMo

perspectives on BPs

important issues
as-is vs to-be processes

in an AS-IS BP, one could recognize the implementaion of a primary perspective (e.g the deterministic for the ATM)

to identify aTO-BE BP, it is useful to start from a different perspective

there are anyway BPs that require to be modelled according to more than just one perspective

do not confuse the implementaion of a perspective with the perspective

e.g. how the ATM machine works is the "actual" BP, the implementation of a perspective, it is NOT a perspective

examples of BPsuseful for discussion
granting a loan

typically this BP has a formalized "mechanistic-like" procedures, but includes a strong social variable ("the look in the eye of the customer")

therefore to model this process the pure mechanistic perspective would not be enough (it would miss an aspect, the "look in the eye") that is critical for the success of the process

restaurant

the BP of a 3 michelin stars restaurant probably implement a mechanistic view

the BP of an Italian trattoria probably implement a social contruct view

this does NOT mean that these two are respectively the only "right" perspectives to design the BP.

We should ask whther, in order to improve the perfomances of the restaurant, i.e. of its BPs, a Ritz-Carlton sohuld try to use the social construct perspctive and the Trattoria should try a deterministic perspective

This lead to discussing what are the variables that influence the choice of one prevalent perspective instead of the others:

- the skills of the modeller

- the strategic objectives of the organization

- ...???

ATMmachine

does an ATM necessarily require a mechanistic view of the BP, or (like in the case of the Public administration), it simply implements the perspective of the deterministic machine?

maybe we could improve the output (the service) provided by the ATM if we would look at it from a sociological perspective! e.g. if we take into acconnt the psychological carachteristics of the users of the ATM?

Melao and Pidd 2000'sframework

class discussion

is any perspective goodfor any BP?critical aspects
legal norms on the BP

if the process is normed by the Law, then it can only be seen as a deterministic machine

arguable: maybe the truth is that a procedure in a Public Administration is specified (it implements) a mechanistic perspective.

But this does not mean that by using another perspective (e.g. to the other extrem, the "Social construct") it would not be possible to improve the process. E.g. is the performace of the BP of deliveriing a certain certificate influenced by the

- attitude

- skills

- morality (?)

of an employee, independently on the procedure he/se is ***supposed*** to implement

size of the BP

if the BP is small (not much complex)

then it is ok to model as a deterministic machine

arguable: independently on the size of the process, if you represent it as a deterministic machine you miss several aspects:

- evolution along time

- social aspects

and these aspects may impact critically on the performance of the BP

the value of the process

a certain perspective may allow to make more explicit the value of the business process: to include in the representation aspects that are core for the success of the business process

--> link to KPI of the BP (and in general to the issue of measurment besides the issue of design)

the purpose of the modelling

if the purpose of the modelling is communication, then a driver to the decision of which perspective and technique to be used should be the simplicity of representation (i.e. if the purpose is communication, ER diagrams or UML diagrams may be ok)

do you agree?

Aurelio

ok, but

want to add your comments? go tohttp://www.mindomo.com/edit.htm?m=87f5f2bd510c4deca02abb8198a425c9to edit the map

BPM suites

Gartner's 2009magic quadrant

methodologies at the strategic level

kaplan and nortonbalanced scorecard

course classes

week4class1
EA project by projectNiels Fonstad
week2class3
BPM

BPM: main elements

•Designing and modelling

•Executing and automating

•Monitoring and optimizing

BPM approaches

•Tactical approach

–Addressing specific problems in a single business area

–Still need for integration and flexibility

•Strategic approach

–BPM solution set or portfolio

–Need for full interoperability among its component parts

–Rich capabilities for users, managers, developers

–Broad array of capabilities addressing different process types:

•Collaborative

•Transactional

•Structured

•Content-centric

•Dynamic

–Realtime visibility across processes

–Can not only optimize existing processes, but help define parameters for new processes

•SOA as an enabler for a strategic approach to BPM

--> The strategic value of SOA

A resource-based model (Mata, Fuerst and Barney 1995)

EA and business capabilities

Building dynamic business capabilities with IT infrastructures: 7 hurdles

1.IT Seen Primarily as an Enabler of Operational Capabilities

2.Improvisation Seen as Unacceptable

3.IT Not Woven Into the Enterprise’s Business Fabric

4.Limited Availability of IT Infrastructures

5.Difficulty of Funding Emerging IT Infrastructures

6.Resistance to Loose/Tight Coupling

7.The Temptation to Cut Corners

week2class2
EA governancelifecycle

4. Audit

3. Prioritization

Portfolio management


• Herding cats


• Drivers

– Adjusting the business to new products and service

offerings

– Trends in industry or technology

– Economic shifts, tighter budgets, eliminating

redundancies while maximizing reuse

– Optimizing the enterprise's operating model

– Regulation requirements.

2. Execution

1. EA Engagement

Big Tent

• Portfolio management framework (PPM and

others)

• Project model and project framework (PRINCE2,

PMI and others)

• Process description framework for business and

IT (BPMN and others)

• IT operational framework (ITILv3, MOF and

others)

• Technological frameworks and tools (to some

extent)

Engagement questions

• Are strategy and initiatives in business and IT

aligned?

• Are resources used in the best way possible?

• Does everyone understand how IT objectives

are supporting the business objectives?

• Are risks (business and IT) understood and

managed?

• Are business requirements and quality

expectations met appropriately?

EA projects fail- because- what to do

Lack of an understanding of what EA is/isn’t:

• EA Training, Develop an EA Communication Plan

Unclear leadership:

• Assign an Executive Sponsor and Chief Architect

Insufficient resources:

• Proper planning, sufficient budget/time/staff, use EVM tracking

The architecture scope is too big:

• Divide the EA into segments, sequence development

Lack of perceived value:

• Identify purpose of EA, how value is derived, ROI period

Lack of use when architecture is developed:

• Integrate into governance, recognize as authoritative standard

Competition with other best practices:

• Identify EA as meta-model/context for other practices/methods

skepticalenterprisearchitect

The Skeptical Enterprise Architect

1. Don’t be blinded. Fundamental transformation to the tasks performed in

organizations depend on political and institutional determination.

2. Understand the business. Understand the environment, agency

programs, and potential ‘obstacles’ before launching EA programs.

3. Don’t follow, lead. Perceived ‘best practices’ are not always the right

medicine in a specific context. EA programs must proactively be

customized to a specific context if success is to be achieved.

4. Focus on business and leadership, not technical frameworks. New

EA programs must ensure management backing and focus on business

process management and change management.

5. Only use EA as a toolbox. EA is a meta-discipline that embraces,

supplements, and extends other disciplines. EA programs must change

over time and become part of a continuous business improvement agenda.

6. Create clear governance structures. Unclear distributions of power,

unclear mandates, and a constant struggle for political support will hinder

EA success. A clear governance structure across levels and functions of

government is key for successful EA adoption.

7. Think big and start small. Develop EA programs that can embrace the

need for extra-organizational horizontal and vertical linkages.

EAGov.org Perceived ‘best practices’ are not always the right

medicine in a specific context. EA programs must proactively be

customized to a specific context if success is to be achieved.

EAGov.org

week1class3
SOA maturity stages

fundamental SOA

networked SOA

process-enabled SOA

week1class1
EA vs IT A

EA refers to the high level logics governing both business and IT capabilities

IT architecture involves:

Processes architecture

Data architecture

Technology architecture

Application architecture

… which is almost the same as before but with a technical focus (no customers)

Operating Model

1) How much standardization do you need?

2) How much integration do you need?

2*2

Business Process Integration

vs

Business Process Standardization

H-H

Unification

Centralized operations

Unified decisions about IT and business processes

Integrated customer interface

Seamless supply chain

H-L Coordination

Semi-autonomous specialized organizational units

Different IT and business process needs

Common view of company demanded by market

shared view of customers needed internally

L-H

Replication

Independent business units in a controlled environment

Centralized IT and business decisions

Highly standardized processes

L-L

Diversification

Autonomous organizational units with different market requirements

Independent business process and IT decisions Few standards mandated internally

EA as StrategySystemic Model

intro

SOA is Dead

(Anne Thomas Manes)

(The Acronym) SOA is (Perhaps) Dead (at Some Companies);Long Live Services
SOA obituary
2009 hypes and buzzwords
EDS: Enterprise cloud
Oracle: green enterprise
ATOS: sustainability
IBM: smarter planet
2009 trends in IT
Cutter BenchmarkEA resolutions for 2009
McKinseyIT's unmet potential
GartnerMeeting the Challenge:The 2009 CIO Agenda

Business Priorities

Business process improvement

Top 10 Technology priorities

Business intelligence

McKinseyFive trends that will shapebusiness technology in 2009

IT and corporate finance converge

Tension around IT budgets increases

The “last” IT project?

Regulators demand more from IT

The offshoring and outsourcing landscape shifts