Your SlideShare is downloading. ×
0
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Managing enterprise stakeholders collaboration a qualitative and quantitative rational approach

3,242

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

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,242
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
18
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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/

×