Managing Enterprise Stakeholders’ Collaboration
a Qualitative and Quantitative Rational Approach
Copyright (c) 2011-2013 P...
Introduction
• Enterprise Architecture is a complex and daunting
discipline (Nightingale D. and Rhodes D., 2004) that
touc...
Introduction
• While the ZF is widely recognized as providing a
clear static depiction of Enterprise Architecture, it
does...
Introduction
• This presentation demonstrates that the influence that
the ZF's Perspectives (Rows) have on each other can ...
The Zachman FrameworkTM for
Enterprise Architecture
• The ZF is a two dimensional matrix that structures an
Enterprise Arc...
Zachman FrameworkTM 's Rows or
Perspectives
• Each row in the framework represents a total View of the enterprise from
the...
Zachman FrameworkTM's Columns or
Architectural Aspects
• Each column in the framework focuses on one of the
following fund...
Zachman FrameworkTM's Cells
• A given cell in the ZF represents a unique model
at the intersection of a Perspective and an...
Zachman FrameworkTM's Cells
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
9
Data Function Network People Time Moti...
A Cell's Influence
• The influence of a Cell can be seen as the level of
constraint that it imposes on itself and on other...
A Cell's Influence
• This presentation aims first at qualifying and
quantifying how the 30 Cells found on the first 5 rows...
Example of Cell's influence
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
12
Motivation
(Why)
Process
(How)
Data
(...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
13
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
14
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
15
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
16
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
17
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
18
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
19
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
20
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1...
Example of Cell's influence
• The Contextual perspective is concerned with goals.
• Cell C1 “Help PC Designers understand ...
Example of Cell's influence
• C2 states “ -Measure, Interpret, and Compare the
Performance of diverse PC I/O products ” it...
Example of Cell's influence
• Furthermore, C1 generates an implicit constraint on C4,
the cell directly below it.
• C4 is ...
Example of Cell's influence
• Let's look at C5. C5 is influenced at the same
Perspective level by C4 and at the Contextual...
Implications of Cell’s influence
• As the content of the Cells are defined one
can easily understand the benefit of having...
Modeling Cells' Influence
• The following two rules are proposed:
– Rule1: Same Perspective Rule (on the same row
in the F...
Modeling Cells' Influence
• In this model, Primary influences capture relationships
between Cells that are explicitly part...
Modeling Cells' Influence
• The relative strength of a Secondary influence (SI) as
compared to a Primary influence (PI) is...
Modeling Cells' Influence
• The value of the ratio SI/PI should be selected
based on each project and/or organization's ow...
Model Results
• The influence of the ZF Cells can then be summarized
by the constraint strength that each Architectural
Pe...
Model Results
• The overall Enterprise Architecture then can
be in a given state that would be described by
the distributi...
Results Interpretation
• Most critical Stakeholder Groups' involvement
steps
– a Stakeholder group's degree of involvement...
Most critical Stakeholder Groups'
involvement steps
• When a Stakeholder's Enterprise Architecture
Perspective holds most ...
Most critical Stakeholder Groups'
involvement steps
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
34
5 Perspective...
Most critical Stakeholder Groups'
involvement steps
• The predominant states occurrence point and
duration indicate when a...
Most critical Stakeholder Groups'
involvement steps
• Having all stakeholder groups simultaneously involved
ultimately pro...
Most critical Stakeholder Groups'
involvement steps
• The last observation becomes notably important
when Agile methodolog...
Most critical Stakeholder Groups'
involvement steps
• Our model clearly shows that Technicians and
Programmers involvement...
Most critical Stakeholder Groups'
involvement steps
• The model insight is twofold:
– first, not all stakeholder groups' i...
Results Interpretation
• Valuable Stakeholder Groups' collaboration
opportunities
– Feedback between Architectural Perspec...
Valuable Stakeholder Groups'
Collaboration Opportunities
• Value comes from focusing efforts on two sets
of artifacts from...
Valuable Stakeholder Groups'
Collaboration Opportunities
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
42
5 Perspe...
Valuable Stakeholder Groups'
Collaboration Opportunities
• In our model most feedback and iterations happen between two
co...
Valuable Stakeholder Groups'
Collaboration Opportunities
• Brooks pointed out in his 1975 book "the mythical Man-Month"
th...
Valuable Stakeholder Groups'
Collaboration Opportunities
• Knowing the degree of involvement that each stakeholder
group s...
Results Interpretation
• Evaluating Risk
– Our model shows at any given point the relative amount of
constraints applied t...
Evaluating Risk
• The following tables rank each Perspective risk
level on a scale of 1 to 5 where 1 represents the
least ...
Evaluating Risk
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
48
5 Perspectives: Contextual, Conceptual, Logical, ...
Evaluating Risk
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
49
5 Perspectives: Contextual, Conceptual, Logical, ...
Evaluating Risk
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
50
5 Perspectives: Contextual, Conceptual, Logical, ...
Evaluating Risk
• It is invaluable to know which Perspective is more or less tightly
specified at any point in the Enterpr...
Conclusion
• We have demonstrated that our model can be
used to rationally prescribe preferred degrees of
involvement that...
Conclusion
• From the Stakeholders' preferred degrees of
involvement, we have highlighted critical steps in
the Enterprise...
Conclusion
• Many Software Engineering and Enterprise Architecture
methodologies and frameworks [Minoli 2008] have been ma...
References
• Amber S. W. (2002), Agile Modeling: Effective practices for eXtreme
Programming and the unified process, Wile...
References
• Evans E. (2004), Domain Driven Design: Tackling complexity in the heart of
software, Addison-Wesley.
• Franke...
References
• Minoli D. (2008), Enterprise Architecture A to Z: Frameworks, Business Process
Modeling, SOA, and Infrastruct...
References
• Royce W. (1998), Software Project Management a Unified Framework, Reading,
MA.
• Sage A. (1991), Decision Sup...
Copyright (c) 2011-2013 Pragmatic
Cohesion Consulting
59
Model Software licenses now available for full access to the mode...
Upcoming SlideShare
Loading in …5
×

Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach

3,554 views

Published on

Qualitative and Quantitative model used to rationally prescribe preferred degrees of involvement that Enterprise Stakeholders should have throughout the implementation of an Enterprise IT project

Published in: Technology, Business
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
3,554
On SlideShare
0
From Embeds
0
Number of Embeds
1,332
Actions
Shares
0
Downloads
18
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach

  1. 1. Managing Enterprise Stakeholders’ Collaboration a Qualitative and Quantitative Rational Approach Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 1 Selected as an ACM TechPack Article on Enterprise Architecture How Enterprise Architecture Aligns Business Architecture and IT Architecture
  2. 2. Introduction • Enterprise Architecture is a complex and daunting discipline (Nightingale D. and Rhodes D., 2004) that touches multiple aspects of an Enterprise as well as people participating in various roles throughout the life cycle of the Enterprise (Rouse, 2005). • The Zachman FrameworkTM (ZF) for Enterprise Architecture (Zachman, 1987; The Zachman FrameworkTM, 2009) offers a formal and highly structured representation of an Enterprise. • The Framework's Perspectives correspond to specific Stakeholder groups that play different roles in the implementation of an Enterprise Architecture. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 2
  3. 3. Introduction • While the ZF is widely recognized as providing a clear static depiction of Enterprise Architecture, it does not explicitly specify possible temporal development sequences of the artifacts it so elegantly captures. • Furthermore, determining the degree of involvement that each one of the first five stakeholder groups should have throughout the development of an Enterprise Architecture has remained outside the scope of the ZF. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 3
  4. 4. Introduction • This presentation demonstrates that the influence that the ZF's Perspectives (Rows) have on each other can be used to derive a rational allocation of stakeholders' skills and time throughout an Enterprise Architecture life cycle. • We also define an approach to tackling and perhaps avoiding all together Brook's Law which states that "Adding people to a late project tends to make it run later" (Brooks, 1975). The paper does so by prescribing upper bounds to Stakeholders' relative degree of involvement based on the level of influence that they exert at any given point in time on Enterprise Architecture artifacts mapped to the ZF. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 4
  5. 5. The Zachman FrameworkTM for Enterprise Architecture • The ZF is a two dimensional matrix that structures an Enterprise Architecture according to different types of Perspectives (Rows) and different Aspects or focuses of Architecture (Columns). The framework's 6 rows represent 6 Perspectives having the following types of concern: Contextual, Conceptual, Logical, Physical, Detailed, and Actual Enterprise. The framework's 6 columns represent 6 aspects of architecture: Data, Function, Network, People, Time, and Motivation. The sixth row is the actual enterprise. This paper focuses on the first 5 rows and all 6 columns of the framework. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 5
  6. 6. Zachman FrameworkTM 's Rows or Perspectives • Each row in the framework represents a total View of the enterprise from the perspective of a given group of stakeholders who share common concerns. – The first row of the framework represents the Contextual Perspective. It aims at defining the broad business Scope of the enterprise as seen from the viewpoint of Planners. Enterprise purpose, cost/profit, and positioning in its global environment reside in this Perspective. – The second row of the framework represents the Conceptual Perspective. This is the Owner's perspective. It contains various Enterprise Business models. – The third row of the framework represents the Logical Perspective. It is the realm of Designers and Architects who capture Information System level Models of the enterprise. – The fourth row represents the Physical Perspective. Here Engineers specify various Technologies, Tools, and Materials that will realize the Information System level models. – The Fifth row represents the Detailed Perspective. In-house and/or contracted Programmers and Technicians create very detailed specifications of physical system Components. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 6
  7. 7. Zachman FrameworkTM's Columns or Architectural Aspects • Each column in the framework focuses on one of the following fundamental questions about the enterprise: What, How, Where, Who, When, and Why. The answers are Architectural aspects or focuses of the enterprise: – The What column represents the Data description of the enterprise – The How column represents the Process or Function description of the enterprise – The Where column represents the Network description of the enterprise – The Who column represents the People description of the enterprise – The When column represents the Time description of the enterprise – The Why column represents the Motivation description of the enterprise Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 7
  8. 8. Zachman FrameworkTM's Cells • A given cell in the ZF represents a unique model at the intersection of a Perspective and an Architectural Aspect. • A Cell serves a unique purpose in relation to any other cell on either one of its two axes. • For example the cell at the crossing of the Logical Perspective and the Data Aspect hosts Data Model diagrams of entities and their relationships without any physical or technology concern. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 8
  9. 9. Zachman FrameworkTM's Cells Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 9 Data Function Network People Time Motivation Contextual Conceptual Logical CELL Physical Detailed
  10. 10. A Cell's Influence • The influence of a Cell can be seen as the level of constraint that it imposes on itself and on other Cells. • When a cell model is created it places: – explicit constraints on itself – implicit constraints on the cells directly below and above it (called Transformation Associations) – implicit constraints on cells residing in the same perspective (called Integration Associations) (Locke, 2008) Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 10
  11. 11. A Cell's Influence • This presentation aims first at qualifying and quantifying how the 30 Cells found on the first 5 rows of the framework influence each other. • The presentation also analyzes how the strength of these influences vary over time when different Frameworks' Perspectives are selected as the initial one. • The presentation stipulates that Enterprise Arcitecture (EA) Stakeholders' relative degree of involvement in an EA life cycle can be determined by the level of influence that the artifacts they own exert at any given point in time on the overall EA. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 11
  12. 12. Example of Cell's influence Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 12 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] System Goals [C2] Scope of System Processes [C3] List of things important to the System Conceptual (Business Model) [C4] System Rules [C5] System Processes [C6] System Entities Logical (System model) Physical (Technology Model)
  13. 13. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 13 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] System Goals : Help PC Designers understand PC I/O performance [C2] Scope of System Processes [C3] List of things important to the System Conceptual (Business Model) [C4] System Rules [C5] System Processes [C6] System Entities Example of Cell's influence
  14. 14. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 14 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] System Goals : Help PC Designers understand PC I/O performance [C2] Scope of System Processes [C3] List of things important to the System Conceptual (Business Model) [C4] System Rules [C5] System Processes [C6] System Entities ? ? ? ? ? Example of Cell's influence
  15. 15. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 15 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] -Help PC Designers understand PC I/O performance [C2] [C3] Conceptual (Business Model) [C4] [C5] [C6] ? ? Example of Cell's influence
  16. 16. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 16 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] -Help PC Designers understand PC I/O performance [C2] [C3] -PC I/O Products -PC I/O performance measurements that are best candidate for a Benchmark are Response Time (also called Latency) and Throughput (also called Bandwidth) Conceptual (Business Model) [C4] -A PC I/O performance varies depending on the characteristics of the I/O workload it processes [C5] [C6] Example of Cell's influence
  17. 17. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 17 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] -Help PC Designers understand PC I/O performance [C2] [C3] -PC I/O Products -PC I/O performance measurements that are best candidate for a Benchmark are Response Time (also called Latency) and Throughput (also called Bandwidth) Conceptual (Business Model) [C4] -A PC I/O performance varies depending on the characteristics of the I/O workload it processes [C5] [C6] ? Example of Cell's influence
  18. 18. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 18 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] -Help PC Designers understand PC I/O performance [C2] -Measure, Interpret, and Compare the Performance of diverse PC I/O products [C3] -PC I/O Products -PC I/O performance measurements that are best candidate for a Benchmark are Response Time (also called Latency) and Throughput (also called Bandwidth) Conceptual (Business Model) [C4] -A PC I/O performance varies depending on the characteristics of the I/O workload it processes [C5] [C6] ? Example of Cell's influence
  19. 19. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 19 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] -Help PC Designers understand PC I/O performance [C2] -Measure, Interpret, and Compare the Performance of diverse PC I/O products [C3] -PC I/O Products -PC I/O performance measurements that are best candidate for a Benchmark are Response Time (also called Latency) and Throughput (also called Bandwidth) Conceptual (Business Model) [C4] -A PC I/O performance varies depending on the characteristics of the I/O workload it processes [C5] -Configure possible I/O Workloads -Measure PC I/O performance under varying workloads -Categorize the measured PC I/O performance of each workload as good, medium, or poor [C6] ? Example of Cell's influence
  20. 20. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 20 Motivation (Why) Process (How) Data (What) Contextual (Scope) [C1] -Help PC Designers understand PC I/O performance [C2] -Measure, Interpret, and Compare the Performance of diverse PC I/O products [C3] -PC I/O Products -PC I/O performance measurements that are best candidate for a Benchmark are Response Time (also called Latency) and Throughput (also called Bandwidth) Conceptual (Business Model) [C4] -A PC I/O performance varies depending on the characteristics of the I/O workload it processes [C5] -Configure possible I/O Workloads -Measure PC I/O Products performance under varying workloads -Categorize the measured PC I/O Products performance of each workload as good, medium, or poor [C6] -(Track) Data about the type of workload parameters -(Track) Data about each workload parameter range of values -(Track) Throughput and Response time measurements for each identified Workload on each PC I/O Product. -(Track) workload parameter values, that yielded: poor, medium, and good performance levels across the PC I/O Products Example of Cell's influence
  21. 21. Example of Cell's influence • The Contextual perspective is concerned with goals. • Cell C1 “Help PC Designers understand PC I/O performance” is the intersection of that perspective with the Purpose focus. The content of Cell C1 is an explicit constraint on itself that states the goal of the system under study. • That explicit constraint generates two implicit constraints at the same perspective level. The first one is on the Process focus C2 and the second one is on the Data focus C3. • When defining the content of C2 and C3 you take into account what C1 states and you consider its implication on what is going to be entered in both C2 and C3. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 21
  22. 22. Example of Cell's influence • C2 states “ -Measure, Interpret, and Compare the Performance of diverse PC I/O products ” it is clear how that statement correlates to C1. C2's statement is an explicit constraint on itself. • Similarly C3's statement “-PC I/O Products -PC I/O performance measurements that are best candidate for a Benchmark are Response Time (also called Latency) and Throughput (also called Bandwidth)” also correlates well to both C1 and C2's statements. C3's statement is an explicit constraint on itself. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 22
  23. 23. Example of Cell's influence • Furthermore, C1 generates an implicit constraint on C4, the cell directly below it. • C4 is also a Motivation cell but it resides in the Conceptual Perspective. C4's content is influenced by C1's statement and it addresses it from a Conceptual viewpoint; • C4 states “-A PC I/O performance varies depending on the characteristics of the I/O workload it processes ”. • This statement is a pertinent rule that places implicit constraints on the other conceptual cells C5(Process) and C6(Data). Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 23
  24. 24. Example of Cell's influence • Let's look at C5. C5 is influenced at the same Perspective level by C4 and at the Contextual level by C2. • C5's statement ”-Configure possible I/O Workloads - Measure PC I/O Products performance under varying workloads -Categorize the measured PC I/O Products performance of each workload as good, medium, or poor ” definitely correlates well to C2 and C4's statements. • An identical observation applies to C6' statement as it relates to statements C4 and C3. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 24
  25. 25. Implications of Cell’s influence • As the content of the Cells are defined one can easily understand the benefit of having the pertinent Stakeholders not only involved but effectively collaborating to promote consistency throughout the framework. • The nature and strength of influences that Cells apply onto one another is valuable for estimating Stakeholders degree of involvement. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 25
  26. 26. Modeling Cells' Influence • The following two rules are proposed: – Rule1: Same Perspective Rule (on the same row in the Framework). A Cell Primarily influences itself and all other Cells that relate to the same Perspective . – Rule 2: Same Architectural Aspect Rule(on the same column in the Framework). A Cell Primarily influences the Cell that is immediately below it. A Cell also influences at a Secondary degree the Cell that is immediately above it. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 26
  27. 27. Modeling Cells' Influence • In this model, Primary influences capture relationships between Cells that are explicitly part of the ZF and are known as Transformation relationships (from a upper row to a lower row) and Integration relationships (between any two cells of the same Perspective). • In addition to Primary influences we propose the definition of Secondary influences that can be considered less constraining than Primary ones. • A Secondary influence is exercised by a ZF Cell on the Cell immediately above it. • The Secondary influence is meant to capture feedback and corrective actions from a ZF lower row Perspective to a higher one. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 27
  28. 28. Modeling Cells' Influence • The relative strength of a Secondary influence (SI) as compared to a Primary influence (PI) is a variable that attempts to quantify the influence of feedback and corrective actions. • Juran and Gryna (1993) suggest the use of fractions to quantify deficiencies. • The fraction values vary from 0 to 1 with 0 indicating no deficiency and 1 the highest deficiency level. • The ratio (Secondary influence strength)/(Primary influence strength) is similar to Juran and Gryna's deficiency ratio where SI/PI varies from 0 to 1. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 28
  29. 29. Modeling Cells' Influence • The value of the ratio SI/PI should be selected based on each project and/or organization's own assessment of the degree of rework that takes place throughout its Enterprise environment. • We have selected to use SI/PI=0.5 to illustrate the use of our model. • SI/PI = 0.5 corresponds to an average amount of feedback and corrective actions and it is obtained by setting a Primary influence to be twice as strong as a Secondary influence. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 29
  30. 30. Model Results • The influence of the ZF Cells can then be summarized by the constraint strength that each Architectural Perspective imposes upon itself and the other ones. • We have modeled the distribution of constraint strengths placed by a Perspective on itself and on all other Perspectives. • Each Perspective predominantly constrains itself then it constrains the Perspectives immediately below and above it. • The constraint strength placed on a Perspective indicates how much specification has been implicitly and explicitly created for that Perspective. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 30
  31. 31. Model Results • The overall Enterprise Architecture then can be in a given state that would be described by the distribution of constraint strengths placed on each Perspective. • So an Enterprise Architecture could be predominantly in a Contextual state, a Conceptual state, a Logical state, a Physical state, or a Detailed state. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 31
  32. 32. Results Interpretation • Most critical Stakeholder Groups' involvement steps – a Stakeholder group's degree of involvement at a given step is determined by the percentage of total constraints induced by the implemented ZF Cells' artifacts on the Perspective that each group owns. – It is not the same as a measurement of the actual efforts needed to create these artifacts. Actual efforts measurement units can be relative or absolute and could, for example, be expressed in function points, man-hours, or story points. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 32
  33. 33. Most critical Stakeholder Groups' involvement steps • When a Stakeholder's Enterprise Architecture Perspective holds most of the constraints we consider the state that it represents to be predominant. The following table shows which Enterprise Architecture Perspective is predominant over the 30 steps based on which state was the initial one. Initial states are in the first column of the table. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 33
  34. 34. Most critical Stakeholder Groups' involvement steps Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 34 5 Perspectives: Contextual, Conceptual, Logical, Physical, Detailed. We respectively symbolize each one as follow: • X:Planners • C:Owners/Business Analysts • L: Architects/Designers • P:Engineers • D:Technicians/Programmers.
  35. 35. Most critical Stakeholder Groups' involvement steps • The predominant states occurrence point and duration indicate when a specific stakeholder group involvement is the most critical. • The model also suggests that all stakeholder groups be simultaneously involved in the Enterprise Architecture life cycle after only a few steps regardless of which group is predominant. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 35
  36. 36. Most critical Stakeholder Groups' involvement steps • Having all stakeholder groups simultaneously involved ultimately promotes Synergy (Lui and Chan, 2008), one of the primary tenets of Agile methods such as SCRUM (Schwaber, 2007). • Many Information Systems development efforts lose sight of this need especially during life cycle phases where one or two stakeholder groups remain the focus of most efforts for an extended time period (Booch, 1998) . • Because the Detailed state usually becomes predominant relatively quickly, we suggest that Technicians and Programmers can benefit most from being aware of valuable opportunities to interact with other stakeholder groups even if most ongoing critical efforts take place within the realm of the Detailed Perspective. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 36
  37. 37. Most critical Stakeholder Groups' involvement steps • The last observation becomes notably important when Agile methodologies are followed throughout the Enterprise Architecture life cycle (Myers, 2010). • Because Agile favors reaching the Detail Perspective as quickly as the team can afford, there is a great temptation to underestimate the influence of stakeholders representing other Perspectives (Rosenberg, Stephens, and Collins- Cope, 2005) . Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 37
  38. 38. Most critical Stakeholder Groups' involvement steps • Our model clearly shows that Technicians and Programmers involvement happen early after at most 4 steps. But the Detailed Perspective becomes predominant only after covering a specific number of steps during which other Perspectives are predominant. • The number of prerequisite steps varies depending upon which Architectural Perspective starts the sequence. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 38
  39. 39. Most critical Stakeholder Groups' involvement steps • The model insight is twofold: – first, not all stakeholder groups' involvement (while recommended) are equally critical throughout the Enterprise Architecture life cycle. – Second, there is a rational way of estimating a preferred degree of involvement of all Stakeholder Groups throughout the life cycle based on which Architecture Perspective is selected as the initial one. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 39
  40. 40. Results Interpretation • Valuable Stakeholder Groups' collaboration opportunities – Feedback between Architectural Perspectives is encouraged by most iterative software and systems engineering development paradigms (Royce, 1998). – The model shows which Perspective or Enterprise Architecture state is predominant throughout the 30 steps. By adding the Perspective which is the second most predominant one can identify valuable opportunities for feedback or iterations between two Architecture Perspectives. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 40
  41. 41. Valuable Stakeholder Groups' Collaboration Opportunities • Value comes from focusing efforts on two sets of artifacts from different perspectives that have, at a given point in time, the most influence on the overall state of the Enterprise Architecture. • The goal is to ensure that strong consistency exists between these two perspectives. • The following table illustrates this point. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 41
  42. 42. Valuable Stakeholder Groups' Collaboration Opportunities Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 42 5 Perspectives: Contextual, Conceptual, Logical, Physical, Detailed. We respectively symbolize each one as follow: • X:Planners • C:Owners/Business Analysts • L: Architects/Designers • P:Engineers • D:Technicians/Programmers.
  43. 43. Valuable Stakeholder Groups' Collaboration Opportunities • In our model most feedback and iterations happen between two contiguous Perspectives. • For perspectives that are contiguous to two other ones, feedback takes two distinct forms. • The Contextual, Logical, and Physical perspectives find themselves candidates for two types of feedback interactions: first with the upper row perspective and second with the lower row perspective. • This means that the stakeholders belonging to these groups must be able to effectively communicate with two other stakeholder groups: – Business owners must be capable of effectively communicating with Planners and Architects. – Architects must be skilled at exchanging information with Business Owners and Engineers. – Engineers must feel comfortable interacting with Architects, Technicians and Programmers. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 43
  44. 44. Valuable Stakeholder Groups' Collaboration Opportunities • Brooks pointed out in his 1975 book "the mythical Man-Month" that adding people to a late project tends to make it run later still. • The underlying principle that justified his comment is that the number of communication paths across a team of N people varies proportionally to N Squared. • This implies that significantly more coordination is required among team members as individuals are added to the team. Further, members who join a project in progress need time to be brought up to speed by the preexisting members of the team - hence requiring additional efforts from them besides the execution of their primary duties. • This inefficiency is another reason project delays occur - the observations in this presentation may make it possible to at least predict them, and possibly avoid them. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 44
  45. 45. Valuable Stakeholder Groups' Collaboration Opportunities • Knowing the degree of involvement that each stakeholder group should have as well as knowing which collaborations hold the most value during the Enterprise Architecture life cycle are essential for optimizing communication paths in such a way that stakeholders' time is not wasted. • No doubt there are many IT professionals that can contribute anecdotal evidence of slowed progress (in the form of unnecessarily oversized meetings, or other activities that add little value to the actual proper implementation of the Enterprise Architecture). • Finally, this quantification of involvement permits more accurate planning - stakeholder groups will be involved at the 'right' time (in this author's experience, 'right' generally means 'earlier') Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 45
  46. 46. Results Interpretation • Evaluating Risk – Our model shows at any given point the relative amount of constraints applied to each Perspective. – Perspectives that have less relative constraints are susceptible to being implemented with lesser cohesion to the other perspectives' specifications and therefore can be considered riskier to develop in terms of being less likely to be successful. – Higher risk in this context is synonymous with higher likelihood of being inconsistent with the content of already created Cells. – Based on which perspective is the initial one, the model estimates how risky it is to work on a Perspective at a given step. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 46
  47. 47. Evaluating Risk • The following tables rank each Perspective risk level on a scale of 1 to 5 where 1 represents the least risk and 5 the most risk. • Color coding is used to indicate progressively higher risk levels (green = low risk, yellow = moderate risk, red = high risk). • Transitions in ranking order are reported when they occur. • These rankings vary depending upon which is the initial Perspective. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 47
  48. 48. Evaluating Risk Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 48 5 Perspectives: Contextual, Conceptual, Logical, Physical, Detailed. We respectively symbolize each one as follow: • X:Planners • C:Owners/Business Analysts • L: Architects/Designers • P:Engineers • D:Technicians/Programmers.
  49. 49. Evaluating Risk Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 49 5 Perspectives: Contextual, Conceptual, Logical, Physical, Detailed. We respectively symbolize each one as follow: • X:Planners • C:Owners/Business Analysts • L: Architects/Designers • P:Engineers • D:Technicians/Programmers.
  50. 50. Evaluating Risk Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 50 5 Perspectives: Contextual, Conceptual, Logical, Physical, Detailed. We respectively symbolize each one as follow: • X:Planners • C:Owners/Business Analysts • L: Architects/Designers • P:Engineers • D:Technicians/Programmers.
  51. 51. Evaluating Risk • It is invaluable to know which Perspective is more or less tightly specified at any point in the Enterprise Architecture development life cycle. Such awareness can then mandate additional risk mitigating initiatives if and when the need arises to commit resources and efforts to less specified Perspectives. • The initial Perspective always begins by having the least risk in comparison to the other Perspectives because it first holds almost all constraints. Constraints are propagated throughout the ZF via contiguous Perspectives up to the point where a steady state risk ranking is reached. • No matter which Perspective is selected as the initial one, the ranking most likely ends up being the following one from least risky (or most specified) to most risky (or least specified): Detailed, Physical, Logical, Conceptual, and Contextual Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 51
  52. 52. Conclusion • We have demonstrated that our model can be used to rationally prescribe preferred degrees of involvement that Enterprise Stakeholders should have throughout the implementation of an Enterprise Architecture life cycle. • An important insight revealed by our model is that the stakeholders' degrees of involvement vary not only throughout the implementation life cycle but also according to which Enterprise Architecture Perspective initiates all subsequent efforts. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 52
  53. 53. Conclusion • From the Stakeholders' preferred degrees of involvement, we have highlighted critical steps in the Enterprise Architecture implementation life cycle where specific stakeholder groups are not only predominant but also candidates for useful collaboration opportunities with the second most influential stakeholder group. • Finally, our model was used to assess the relative and varying degrees of risk associated with implementing the artifacts of a given Enterprise Architecture Perspective. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 53
  54. 54. Conclusion • Many Software Engineering and Enterprise Architecture methodologies and frameworks [Minoli 2008] have been mapped to the ZF. The examples are plentiful: – RUP (De Villiers, 2003), – TOGAF (The Open Group Architecture Forum, 2009), – MDA (OMG, 2003 ;Frankel et al, 2003), – EAP (The Chief Information Officers Council,1999), – C4ISR (C4ISR Architecture Framework Version 2.0, 1997), and – DODAF (DoD Architecture Framework, 2007). • From each individual mapping, a method similar to the one presented in this presentation can be used to rationally identify the influence that the mapped Cells have on each other over time. • The model results then become valuable inputs to the planning and management of stakeholder resources allocated to these cells as they get implemented. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 54
  55. 55. References • Amber S. W. (2002), Agile Modeling: Effective practices for eXtreme Programming and the unified process, Wiley, New York. • Blanchard B. and Fabrycky W. (1998), Systems Engineering and Analysis, Prentice Hall, Upper Saddle River, NJ. • Booch G. (1998), Object Solutions: Managing the Object-Oriented Project, Addison-Wesley, Menlo Park, CA. • Brooks F. P., Jr. (1975), "The Mythical Man Month". Addison-Wesley. • Office of the Assistant Secretary of Defense for Command, Control, Comunications and Intelligence (1997),C4ISR Architecture Framework Version 2.0, Washington DC. • Cripe B. (2009), Information Architecture for Enterprise 2.0: enabling Access, Intelligence, & Participation, FishBowl Solutions White Paper. • Department of Defense (2007), DoD Architecture Framework Version 1.7. • De Villiers D. J. (2003), Using the Zachman Framework to Assess the Rational Unified Process, developerWorks, http://www.ibm.com/developerworks/rational/library/372.html. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 55
  56. 56. References • Evans E. (2004), Domain Driven Design: Tackling complexity in the heart of software, Addison-Wesley. • Frankel D. et al.(2003), The Zachman Framework and the OMG's Model Driven Architecture, Business Process Trends Whitepaper. • Juran J. and Gryna F. (1993), Quality Planning and Analysis, McGraw Hill Inc. • Koffi A.D. (2005), A Model for the Evolution of Software and Systems Engineering Project Cultures Throughout Their Life Cycles, Wiley, Systems Engineering Journal 8(2) (2005), 151-163. • Kurstedt, H. (2000), Management Systems Theory, Applications,and Design, Virginia Polytechnic Institute and State University - ISE Department, Blacksburg VA, pp 888-893. • Locke S. (2008), Enterprise Convergence in our lifetime, http://www.ies.aust.com/ten/TEN42.htm#Enterprise_Convergence. • Lui K. and Chan K. (2008), Software Development Rhythms: Harmonizaing Agile Practices for Synergy, John Wiley & Sons Inc., Hoboken, NJ. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 56
  57. 57. References • Minoli D. (2008), Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and Infrastructure Technology,Auerbach Publications, Boca Raton, FL. • Myers M. (2010), Tactical Enterprise Architecture: Challenges to Building a Strategic Program, The Journal of Enterprise Architecture, February, pp 7-15. • Nightingale D. and Rhodes D. (2004), Enterprise Systems Architecting: Emerging Art and Science within Engineering Systems, MIT Engineering Systems Symposium. • Object Management Group (2003), MDA (Model Driven Architecture) Guide. • Rouse W. (2005), Enterprises as Systems: Essential Challenges and Approaches to Transformation, Wiley, Systems Engineering Journal 8(2) (2005), 138-150. • Rosenberg D., Stephens M., and Collins-Cope M. (2005), Agile Development with ICONIX Process-People, Process and Pragmatism, Apress. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 57
  58. 58. References • Royce W. (1998), Software Project Management a Unified Framework, Reading, MA. • Sage A. (1991), Decision Support Systems Engineering, John Wiley & Sons Inc. • Schwaber K. (2007), The Enterprise and SCRUM, Microsoft Press, Redmond, WA. • Schekkerman J. (2003), Extended Enterprise Architecture Maturity Model, Institute for Enterprsie Architecture Developments. • Sowa J. F. and Zachman J. A.(1992), Extending and Formalizing the Framework for Information Systems Architecture, IBM Systems Journal, 31/3, pp 590-616. • The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1. September. • The Open Group Architecture Forum (2009), TOGAFTM Version 9. • The Zachman FrameworkTM: The Official Consise Definition (2009), http://www.zachmaninternational.com/index.php/the-zachman-framework. • Zachman J. A., A Framework for Information Systems Architecture (1987), IBM Systems Journal, 26/3, pp 276-295. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 58
  59. 59. Copyright (c) 2011-2013 Pragmatic Cohesion Consulting 59 Model Software licenses now available for full access to the models presented in this document. Contact Didier at Pragmatic Cohesion Consulting to find out how to implement Effective Cost Reduction Initiatives in your IT Projects by controlling significant Risk Factors throughout their lifecycles. http://pragmaticohesion.com/

×