af aurelio ravarini 12 år siden
310
Management of Enterprise Architectures 2009
af aurelio ravarini 12 år siden
310
Mere som dette
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
e.g. how the ATM machine works is the "actual" BP, the implementation of a perspective, it is NOT a perspective
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
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
- ...???
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?
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
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
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)
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
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)
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
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?
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
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
fundamental SOA
networked SOA
process-enabled SOA
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)
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
(Anne Thomas Manes)
Business Priorities
Business process improvement
Top 10 Technology priorities
Business intelligence
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
