A Practical Look at Architecting an Enterprise for Value Delivery , Presenter

advertisement
A Practical Look at Architecting an
Enterprise for Value Delivery
Lt.Col. Luke Cropsey, Presenter
LAI Web Knowledge Exchange Event
October 20, 2010
We Share A Goal: Enterprise Excellence AMCOM Enterprise Upcoming LAI Web
Knowledge Exchange Events
•  Oct 28, 2010 Standardizing Product Development Processes, Sidharth
Rupani, LAI Alumnus ‘10
• Dec 2, 2010 Organizational Assessment Processes for Enterprise
Transformation, Leyla Abdimomunova, LAI Alumna ‘10
“Observations from the Field”
Designing an Enterprise
for Value Delivery
Lt Col Luke Cropsey 20 Oct 2010 ECJ3 - October 20, 10 -
4
Objectives
•  Provide a couple of useful, “low-tech” tools or
methods to help uncover value
•  Provide a model for thinking about value, context and
the interface between technical systems and their
associated enterprises
•  Provide a few insights and helpful hints comparing
and contrasting the original research effort with
application in practice
ECJ3 - October 20, 10 -
5
Big Ideas
•  Value – Focused Thinking
•  Context
•  Rigor
ECJ3 - October 20, 10 -
6
A Value-Driven Model
Experienced
Value
Use Context
Concept
Need Context
Expected
Value
ECJ3 - October 20, 10 -
7
Outline
•  Case Study #1 – Integrating Unmanned Aircraft
Systems in the National Airspace
•  Case Study #2 – Architecting EUCOM Information
Operations for Value Delivery
•  Observations between Research (Case Study #1) and
Practice (Case Study #2)
•  Conclusions
ECJ3 - October 20, 10 -
8
Outline
•  Case Study #1 – Integrating Unmanned Aircraft
Systems in the National Airspace
•  Case Study #2 – Architecting EUCOM Information
Operations for Value Delivery
•  Observations between Research (Case Study #1) and
Practice (Case Study #2)
•  Conclusions
ECJ3 - October 20, 10 -
9
An Enterprise Architec8ng Framework Policy Process Strategy Product/ Services Organization Knowledge Source: Adapted from Nightingale & Rhodes Slide 10 Enterprise Purpose Context Win War on Terror Recap Force Structure Enable Global Strike (F2T2EA) Ensure Cross-­‐Domain Dominance Operate UAS in the NAS Safely Restore Principle of Maneuver Train and Equip Forces Higher level principle of war required to meet FAA value definition & enable Global Strike for UAS platforms Using the CONOPs Needed for Mission Train and Operate UAS as needed Enterprise Boundary Origin goal Access Required Airspace Safely, Effectively and Efficiently Source: Crawley Slide 11 Enterprise Purpose The purpose of the airspace integration enterprise is to restore the principle of maneuver to operations by integrating UAS into civil airspace using a full spectrum approach of policy, procedures and materiel system equipage while enabling needed UAS training and operational missions and meeting the contextual constraints (political, cultural, organizational, resource, etc) necessary to successfully deliver incrementally meaningful levels of operational flexibility. Source: Crawley Slide 12 Enterprise “As-­‐Is” X-­‐Matrix Enterprise Outcome DoD FAA Enterprise Behavior Source: Adapted from LAI EVSMA Slide 13 Enterprise “ To-­‐Be” X-­‐Matrix Source: Adapted from LAI EVSMA Slide 14 Enterprise Scope & Purpose Enterprise Views Value Attributes Ensure Safety DoD needs capability UAS Platforms Critical Supporting Object Process Effect Link Agent of Link Instrument of Link Decomposes to Specializes to Has attribute of Operational Flexibility Policy Extend Capability Procedure & Standards Process Deliver Useful Increment Collective Data Gathering Organization Provide Implementation Budget & Manpower Knowledge Foster Cooperation Shared PM Responsibility Information Technology Engage Leadership Joint-­‐Led Teams Product Set Activity Scope/Purpose Define Process Enterprise Boundary Capable Equipage Expand Capacity Important Straight Forward Educated Participants Strategy Level 3-­‐5 AF UAS Restore Maneuver Points of Leverage Defined Path Forward Established Criteria Slide 15 Architecture 3 – Hybrid Slide 16 Nightingale & Rhodes Framework DoD Capability-­‐Based Assessment Framework Strategy Doctrine Policy Organization Process Training Organization Materiel Knowledge Leadership & Education Information Technology Personnel Product Facilities Legend -­‐ Direct one-­‐to-­‐one mapping -­‐ Limited or distributed mapping -­‐ No mapping © 2008 Luke Cropsey – Massachusetts Institute of Technology Slide 17 Outline
•  Case Study #1 – Integrating Unmanned Aircraft
Systems in the National Airspace
•  Case Study #2 – Architecting EUCOM Information
Operations for Value Delivery
•  Observations between Theory (Case Study #1) and
Reality (Case Study #2)
•  Conclusions
ECJ3 - October 20, 10 -
18
IO Purpose Statement (JP 3-13)
The purpose of information operations
is to achieve and maintain information
superiority for the U.S. and its Allies by
integrating core, supporting and related
capabilities using a full spectrum
approach to influence, disrupt, corrupt,
or usurp adversarial human and
automated decision making while
protecting our own.
ECJ3 - October 20, 10 -
19
EUCOM Purpose Context
Enhance Transatlantic
Security
Defend the U.S.
Forward
Agile Security
Organization
Enterprise Boundary
To train & operate as needed
EUCOM
The mission of the U.S. European Command is to conduct military operations,
international military partnering, and interagency partnering to enhance
transatlantic security and defend the United States forward.
We do this by establishing an agile security organization able to conduct full
spectrum activities as part of whole of government solutions to secure enduring
stability in Europe and Eurasia.
ECJ3 - October 20, 10 -
20
EUCOM Purpose Context
Enhance Transatlantic
Security
Defend the U.S.
Forward
Agile Security
Organization
Enterprise Boundary
To train & operate as needed
EUCOM
Conduct Military
Operations
International Military
Partnering
Interagency Partnering
ECJ3 - October 20, 10 -
21
EUCOM Purpose Context
Enhance Transatlantic
Security
Defend the U.S.
Forward
Agile Security
Organization
Enterprise Boundary
To train & operate as needed
EUCOM
Conduct Military
Operations
International Military
Partnering
Interagency Partnering
EPOC
J5
J9
ECJ3 - October 20, 10 -
22
EUCOM Purpose Context
Enhance Transatlantic
Security
Defend the U.S.
Forward
Agile Security
Organization
Enterprise Boundary
To train & operate as needed
EUCOM
Conduct Military
Operations
Direct
Synch
EPOC
International Military
Partnering
Plan
Strategy
J5
Policy
Interagency Partnering
Communicate
Synch
J9 Support
ECJ3 - October 20, 10 -
23
IO Purpose Context
Enterprise Boundary
Conduct Military
Operations
Direct
Synch
International Military
Partnering
Plan
Strategy
EPOC
Policy
J5
Information Operations
ECJ3 - October 20, 10 -
24
IO Purpose Context
Enterprise Boundary
Conduct Military
Operations
Direct
Synch
International Military
Partnering
Plan
Strategy
EPOC
Policy
J5
Deliver Information
Superiority
Integrate Employment of
Core IO Functions
Information Operations
Coordinate Supporting
IO Capabilities
ECJ3 - October 20, 10 -
25
IO Purpose Context
Enterprise Boundary
Information Operations
Information operations (IO) are described as the integrated employment of
electronic warfare (EW), computer network operations (CNO), psychological
operations (PSYOP), military deception (MILDEC), and operations security
(OPSEC), in concert with specified supporting and related capabilities, to
influence, disrupt, corrupt, or usurp adversarial human and automated
decision making while protecting our own.
The purpose of this doctrine is to provide joint force commanders (JFCs)
and their staffs guidance to help prepare, plan, execute, and assess IO in
support of joint operations. The principal goal is to achieve and maintain
information superiority for the US and its allies.
ECJ3 - October 20, 10 -
26
IO Purpose Context
Enterprise Boundary
Deliver Information
Superiority
Integrate Employment of
Core IO Functions
Information Operations
Coordinate Supporting
IO Capabilities
ECJ3 - October 20, 10 -
27
IO Purpose Context
Enterprise Boundary
Deliver Information
Superiority
Information Operations
Influence
Disrupt
Integrate Employment of
Core IO Functions
Corrupt
Usurp
Protect
Coordinate Supporting
IO Capabilities
ECJ3 - October 20, 10 -
28
IO Purpose Context
Deliver Information
Superiority
Enterprise Boundary
Information Operations
Influence
Disrupt
Integrate Employment of
Core IO Functions
Core Electronic Warfare Computer Network Op Psychological Ops Military Deception Operations Security Corrupt
Usurp
Protect
Coordinate Supporting
IO Capabilities
Supporting
Related
Info Assurance
Public Affairs
Physical Security
Civil-Mil Ops
Physical Attack
Defense Spt to
Counterintel
Public Diplomacy
Combat Camera
ECJ3 - October 20, 10 -
29
IO at a Combatant Command
Commander, United States Strategic Command’s
(USSTRATCOM’s) specific authority and
responsibility to coordinate IO across area of
responsibility (AOR) and functional boundaries does
not diminish the imperative for other combatant
commanders to employ IO. These efforts may be
directed at achieving national or military objectives
incorporated in theater security cooperation plans,
shaping the operational environment for potential
employment during periods of heightened tensions,
or in support of specific military operations. It is
entirely possible that in a given theater, the combatant
commander will be supported for select IO while
concurrently supporting USSTRATCOM IO activities
across multiple theater boundaries.
ECJ3 - October 20, 10 -
30
Initial Value Identification Interviews
•  Integrate Planning
•  Produce Results
•  Educate Staff and Components
•  Vet Priorities
•  Establish Venue for Vetting Priorities
•  Conduct IO Assessments
•  Evaluate IO Capabilities
•  Identify and Exploit Opportunities
ECJ3 - October 20, 10 -
31
Formalizing DOTMLPF Leadership & Education Organization Doctrine Training Materiel Personnel Source: Adapted from Nightingale & Rhodes Slide 32 Enterprise Analysis Framework
•  Doctrine
•  Organization
•  Training
•  Materiel
•  Leadership & Education
•  Personnel
•  Processes
•  Facilities
ECJ3 - October 20, 10 -
33
EA Framework Analysis
Framework
Enterprise View
Doctrine
Primary
Leverage
Points
0
Organization
9
9
1
Training
1
3
9
1
9
Leadership & Education
1
3
9
3
Personnel
3
3
Processes
9
9
3
3
3
3
3
9
1
9
38
3
3
9
21
3
3
1
46
37
20
Materiel
0
3
3
9
9
Facilities
Total
Total Impact
ID/Exploit Opportunities
Evaluate IO Capabilities
Conduct IO Assessments
Establish Venue
Vet Priorities
Educate Staff & Components
Producd Results
Attribute
Not Considered
(Constraint from Ldrshp)
Integrated Planning
Values
0
23
27
22
13
21
21
13
22
ECJ3 - October 20, 10 -
34
IO Architecture Development
Context
Agile Security Organization HQ EUCOM Staff Achieve Info Superiority Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
Meet CDR’s Intent Purpose
© 2008 Luke Cropsey – Massachusetts Institute of Technology ECJ3 - October 20, 10 -
35
IO Architecture Development
IO Boundary
Context
Agile Security Organization HQ EUCOM Staff Achieve Info Superiority Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
Meet CDR’s Intent Purpose
DOTMLP2F
Desired
Attributes
Supporting
Objects
© 2008 Luke Cropsey – Massachusetts Institute of Technology ECJ3 - October 20, 10 -
36
IO Architecture Development
IO Boundary
Doctrine Context
Agile Security Organization HQ EUCOM Staff Organization Training Materiel Achieve Info Superiority Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
Leadership & Education Meet CDR’s Intent Personnel Purpose
Processes Facilities DOTMLP2F
Desired
Attributes
Supporting
Objects
© 2008 Luke Cropsey – Massachusetts Institute of Technology ECJ3 - October 20, 10 -
37
IO Architecture Development
IO Boundary
Doctrine Integrate Planning Context
Agile Security Organization HQ EUCOM Staff Organization Produce Results Training Educate Staff & Components Materiel Achieve Info Superiority Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
Vet Priorities Leadership & Education Meet CDR’s Intent Personnel Purpose
Processes Establish Venue Conduct IO Assessments Evaluate IO Capabilities Facilities DOTMLP2F
Desired
Attributes
Supporting
Objects
© 2008 Luke Cropsey – Massachusetts Institute of Technology ECJ3 - October 20, 10 -
38
IO Architecture Development
IO Boundary
Mechanism 1 Doctrine Integrate Planning Context
Agile Security Organization HQ EUCOM Staff Organization Produce Results Training Educate Staff & Components Materiel Achieve Info Superiority Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
Vet Priorities Leadership & Education Meet CDR’s Intent Personnel Purpose
Processes Establish Venue Conduct IO Assessments Mechanism 2 Mechanism 3 Mechanism 4 Mechanism 5 Mechanism “n” Evaluate IO Capabilities Facilities DOTMLP2F
Desired
Attributes
Supporting
Objects
© 2008 Luke Cropsey – Massachusetts Institute of Technology ECJ3 - October 20, 10 -
39
Completed Initial Analysis
IO Boundary
Doctrine Integrate Planning Context
Agile Security Organization HQ EUCOM Staff Organization Produce Results Training Educate Staff & Components Materiel Achieve Info Superiority Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
SAS, TCP, RCP CONPLANS Info Ops Plan Annex Capable Components Tasked Components Vet Priorities Leadership & Education Meet CDR’s Intent Personnel Purpose
Processes Establish Venue Conduct IO Assessments Evaluate IO Capabilities Facilities DOTMLP2F
Desired
Attributes
IO Outreach Program Operational Priorities Battle Rhythm Clear Obj & Effects Supporting
Objects
© 2008 Luke Cropsey – Massachusetts Institute of Technology ECJ3 - October 20, 10 -
40
Back Brief Results
•  Disconnects between doctrine, leadership, and action
officers on what info operations really is/means
•  Lack of consensus on attribute definitions
•  Lack of consensus on relative attribute weights
•  Inability of participants to think in value-space
•  Regressed to “processes” and the need to “order”
attributes in a logical sequence
•  Difficulty in thinking in the need space – continued to
devolve to solution space
•  Result: vote of “no-confidence” in the original value
identification
ECJ3 - October 20, 10 -
41
Mid-Course Analysis Observations
•  Rigorous decomposition is important for bringing out
inconsistencies in people’s mental models
•  Different definitions of Info Ops
•  Different perspectives on how activities relate
•  All using the same words to mean different things
•  Getting to real value identification takes time, insight,
and some intuition for the context of the enterprise
•  People have difficulty thinking in the abstract –
especially with something as squishy as “enterprise”
ECJ3 - October 20, 10 -
42
Potential Heuristics
•  Lack of convergence in stakeholder definitions
indicates a failure in proper value identification
•  Value-space is not as large as you think it is. Ask
“Why” questions to winnow symptoms from root
causes.
ECJ3 - October 20, 10 -
43
Value Identification – Round #2
•  Reduce Ambiguity in objectives and effects
•  “Rinse and Repeat” as needed
•  “Planning should be done top down, Refinement bottom
up” – An artillery man’s perspective
•  Open the trade space for Course of Action
development
•  Sum of the Parts ≠ The Whole
•  Ops vs. BPC perspectives
•  Enhance collaboration and team work across the staff
and with external organizations
ECJ3 - October 20, 10 -
44
Framework
Enterprise View
Doctrine
Organization
3
9
3
15
3
3
6
Materiel
0
9
Personnel
Processes
9
3
9
21
3
3
6
3
3
15
Facilities
Total
Primary
Leverage
Points
0
Training
Leadership & Education
Total Impact
Open the Trade Space to IO
Attribute
Not Considered
(Constraint from Ldrshp)
Reduce Ambiguity in Obj/Eff
Values
Enhance Collaboration across Staff/
External Agencies
Architecture Leverage Points
0
21
21
21
ECJ3 - October 20, 10 -
45
The Cognitive Domain
WISDOM = Understanding + Experience
UNDERSTANDING = Knowledge + Insight
KNOWLEDGE = Information + Synthesis across Multiple Contexts
INFORMATION = Data + Context
DATA = Facts and Figures
ECJ3 - October 20, 10 -
46
ECJ3 - October 20, 10 -
47
Cognitive Lines of Effort
Inform – provide facts
Advocate – tell our story
Persuade – change minds
Compel – change actions
ECJ3 - October 20, 10 -
48
Top-Level EUCOM Model
SAS
TCP
ADM
Priorities
RCP
Current
Ops
Crisis
ECJ3 - October 20, 10 -
49
Key Activities & Products
Apply Experience
Create
Focus
Develop
Options
Synchronize
Activity
Identify
Values
Provide
Feedback
ECJ3 - October 20, 10 -
50
Outline
•  Case Study #1 – Integrating Unmanned Aircraft
Systems in the National Airspace
•  Case Study #2 – Architecting EUCOM Information
Operations for Value Delivery
•  Observations between Theory (Case Study #1) and
Practice (Case Study #2)
•  Conclusions
ECJ3 - October 20, 10 -
51
Convergence between Theory & Practice
•  Value-focused thinking works
•  Keep the discussion in “need” vice “solution” space
•  Generating the dialogue produces the insight – ask
“why” at least three more times
•  Drive the discussion to a common model
•  Unarticulated assumptions will kill you – get them out in
the open
•  Words are too ambiguous – use pictures at a minimum
•  Context, Context, Context!
•  You cannot have too much domain experience
•  Get perspectives from everyone in the enterprise
ECJ3 - October 20, 10 -
52
Divergence between Theory and Practice
•  Most people don’t think in the abstract very well
•  EA hurts most people’s head – get concrete fast
•  Avoid the “process and organization” trap
•  “Politics” has to be added to the model
•  Implementation in a bureaucracy may be the hardest
thing you attempt in the entire process
•  Architect for stable intermediate forms based on what is
politically achievable
•  Getting time to “think” is next to impossible
•  Looks a lot like “doing’” nothing
•  The “urgent” displaces the “important”
ECJ3 - October 20, 10 -
53
Outline
•  Case Study #1 – Integrating Unmanned Aircraft
Systems in the National Airspace
•  Case Study #2 – Architecting EUCOM Information
Operations for Value Delivery
•  Observations between Theory (Case Study #1) and
Reality (Case Study #2)
•  Conclusions
ECJ3 - October 20, 10 -
54
Conclusions
•  Rigor counts – don’t take shortcuts
•  Never accept the first answer you get – keep digging
•  A common model is essential – words are necessary
but not sufficient – drive out ambiguity 24/7
•  Context, Context, Context – must have domain savvy
•  Generating stakeholder dialogue may be the most
important thing you do through the entire effort
•  Implementation is as hard as value identification
•  Politics drives the design for stable intermediate forms
of an enterprise architecture – account for it early
ECJ3 - October 20, 10 -
55
Helpful Hints
•  Use someone else to take notes so you can just listen
•  Use analogies to drag important concepts out of the
stakeholder’s framework and into a broader context
•  Value identification takes time – don’t attempt to get
it all in one pass or a single interview
•  There is no substitute for domain experience. Go get
it before attempting an EA effort of any size.
•  Expect conflict to result through the process and
know how to deal with it so it doesn’t derail the effort
•  Get your boss’s perspective early and often or you
won’t get the implementation right
ECJ3 - October 20, 10 -
56
Backup Slides
ECJ3 - October 20, 10 -
57
Enterprise Purpose Framework Layers above the “origin”   The product/system success goal (the “origin”) is just Above origin 1 up one part of the goal structure of the enterprise.   Understanding (by the architect) how the origin goal combines with other enterprise goals is vital. You may have to reconstruct these to have them make sense.   Layers above origin goal merge into enterprise strategy and other functional strategies. System problem statement (SPS) within the “origin” goal Layers below the origin
Enterprise Purpose statement 0 Origin goal   These decompose the origin goal (usually the live or die goals [0.1] and other necessary goals [0.2])   Usually meaningful decomposition of goals is not Below origin 1 down possible until high level concept (form and function) are defined Source: Crawley Slide 58 Concept Fragment Generation
•  Assess each of the desired attributes through the lens
of a particular framework perspective
•  Brainstorm potential mechanisms for creating the
desired attribute from that particular perspective
•  Assess compatibility of individual concept fragments
with leadership direction and compatibility with other
concept fragments
•  Cull out those fragments that are inconsistent with
leadership direction
•  Develop architectures off compatible concept
fragments to populate the full tradespace
ECJ3 - October 20, 10 -
59
Capability-­‐Based Assessment Methodology CBA Boundary
Warfighter needs effect FSA
Attribute 1 Mechanism 1 Attribute 2 Mechanism 2 Attribute 3 Mechanism 3 Attribute 4 Mechanism 4 Doctrine FNA
Organization Joint Operating Concept Program Scope Training Desire Capability Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
Top-­‐Level Characteristics Materiel Mul & Leadership ti-At
Education tribute
Trad
e
Personnel FAA
Mechanism 5 Attribute “n” spa
ce E
xplo
ratio
nM
etho
dolo
gy
Facilities DOTMLPF
Capability
Attributes
Mechanism “n” Supporting
Objects
Slide 60 MATE Methodology Attribute 1 Attribute 2 Behavior Attributes Design Variables Desire Capability Attribute 3 Attribute 4 Attribute “n” Materiel Performance Attributes Model Utility / Cost Utility
Program Scope i = 0,30,60,90
rp = 150, 200…
Cost
Tradespace
Transformed Solution Space
Architectures
Slide 61 Capability-Based Assessment Methodology
CBA Boundary
Warfighter needs effect FNA
Joint Operating Concept Program Scope Desire Capability Object
Process
Effect Link
Agent of Link
Instrument of
Link
Decomposes to
Specializes to
Has attribute of
FSA
Doctrine Attribute 1 Mechanism 1 Organization Attribute 2 Mechanism 2 Training Attribute 3 Mechanism 3 Materiel Attribute 4 Mechanism 4 Leadership & Education Mechanism 5 Attribute “n” Top-­‐Level Characteristics Personnel FAA
Processes Mechanism “n” Facilities DOTMLP2F
Capability
Attributes
Supporting
Objects
ECJ3 - October 20, 10 -
62
Download