Architects and Architect ing

1. Architects and Architecting A management perspective: Identifying architects Assessing architecting

2. Identifying Architects Traits Development Organizational position Power, People, Achievement

3. Introduction In search of good architecting • How can a manager identify a good architect? • What traits make a good systems architect? • Indeed, what traits make a great systems architect? • What is the minimum needed to get the job done? Denise Howard/Stan Settles

4. Main Point & Map Architects in context A few traits seem to be quite helpful, but there is more room for research We will look at • The traits of architects • Developing architects • Positioning architecting in the organization • A framework for identifying motivation Denise Howard/Stan Settles

5. I. Traits Management & Architecting skills Denise Howard/Stan Settles

6. I. Traits Likely Essentials • The ability to conceptualize • An ability to take a wide view • Ease with abstraction • Creativity • And perhaps, the ability to synthesize diverse elements into a related whole Denise Howard/Stan Settles

7. Self: Has self-discipline Has self-confidence Has (internal?) locus of control Oriented toward purposes Will to succeed, determination Willing to search for solutions Interpersonal: Communicates well Ability to read people well Not egotistical Enhances others’ work Ability to build teams Charisma I. Traits Research interviews Denise Howard/Stan Settles

8. Mental: Has generalist view Tolerates ambiguity Has curiosity Associates ideas well Works abstractly ?: Has vision, faith (Maybe occupies the same neighborhood in the mind as synthesis) I. Traits Research interviews, cont’d Denise Howard/Stan Settles

9. I. Traits Prevalence • Few people embody all of these traits • Perhaps traits form a system too • Linear listing might not capture the interplay of which traits in various measures are essential, if any are Denise Howard/Stan Settles

10. I. Traits A certain relentlessness • The relentless communication heuristic: Don’t ever stop talking about the system (Losk in Rechtin, 1991, 292) “Creative, obsessive, juggling of requirements, constraints, technology, costs, and standards” (Spinrad in Rechtin, 1991, 291) Denise Howard/Stan Settles

11. I. Traits The primacy of communication • Another relentless communication heuristic: There’s no such thing as immaculate communication! (Losk in Rechtin, 1991, 292) • Communicating a shared vision requires checking, correcting, and boosting the message frequently • An easy willingness to do so is valuable Denise Howard/Stan Settles

12. I. Traits A short field guide to architects Professor Rechtin’s guidance for managers seeking a potential architect: First impressions: • Someone with a broad system-wide view • And skill at communicating ideas Denise Howard/Stan Settles

13. II. Development Getting to architect • Estimate that it takes 10 well-spent years before architecting • Mentoring is advocated • But mentoring can sometimes be a mechanism for passing on erroneous ideas (Normative) • Architects need independence to grow • Commitment is long-term (decades), even more than SE • Small number of projects per professional lifetime Denise Howard/Stan Settles

14. III. Organizational Positioning architecting • Positioned to see the “whole view” (with respect to the system at hand) • Must be adjacent to decision makers and their value judgments • Might be viewed as staff, but probably needs more authority • Position near a base of support, especially for new architects Denise Howard/Stan Settles

15. III. Organizational A place for architecting • A different style of thinking in development groups, different than SE • Not a super systems engineer • Not a “general engineer”, expert in no particular area • Summary: position so that systems architects can get the job done Denise Howard/Stan Settles

16. Summary Recognizing architecting • How do you learn what you don’t know that you don’t know? -- The learning paradox • Architecting confronts that paradox in many organizations • “Effective systems architecting requires: (1) a management decision that the function is needed …” (Rechtin, 1991, 289) • The learning paradox often resolves suddenly, through outside examples Denise Howard/Stan Settles

17. Epilog Social needs triad • Power * Affiliation * Achievement • Following discussion from Dr. Timothy Butler • Harvard Business School • A framework for understanding architects, managers, clients and the interplay between them • These factors vary within people, across situations, and over time Denise Howard/Stan Settles

18. Epilog Power • The ability to act • Aristotle’s elegant definition • Formal or positional power: CEO or cabinet • Dominance -- High and low • High can take precedence over affiliation and achievement • Seeks shortest possible route to positions of authority Denise Howard/Stan Settles

19. Epilog Power categories • Many varieties* • Prestige – affiliation with well-regarded institutions or traditions • Exhibitionism – drawing attention to self in dramatic or unusual fashion • Ambition – raw drive and determination • Reputation – having and maintaining admired qualities *James Hillman, Kinds of Power Denise Howard/Stan Settles

20. Epilog Power categories, cont’d • Influence – ties to others in a position to act • Resistance – advocate in a just or compelling cause (Gandhi or MLK) • Leadership – attracting followers • Charisma – inspiring through physical presence • Fearsomeness – using fear to accomplish objectives Denise Howard/Stan Settles

21. Epilog Achievement • Achievement – accomplishment independent of consequences in the organization. It encompasses: • Challenge * Learning * Authorship • Challenge • personal (mastery, intrinsic) or • competitive (managers like this, extrinsic) Denise Howard/Stan Settles

22. Epilog Achievement & expertise • Continual investment in self-development – reinvest as resources are freed by continuing development • Heroic aspect of expertise (Bereiter & Scardamalia, 1993, p 107): • “In such cases, pursuing high standards and continuing to advance requires an element of heroism. And we mean heroism literally, in the sense of arduous efforts that benefit society but that are disproportionate to what society provides in the way of rewards and supports.” Denise Howard/Stan Settles

23. Summary Questions for exploring systems When you analyze a new system, you might want to ask questions like these: • Are there any traits, left out in the lists above, which you think could be essential in the development of a particular system? Denise Howard/Stan Settles

24. Summary Questions, cont’d • Did the architects have enough latitude to architect effectively? • Did the architects have appropriate access to decision makers who decide values? • Was the organization able to allow architecting? • Was the organization able to recognize architecting? Denise Howard/Stan Settles

25. Architect’s role Sources • Dr. Timothy Butler, Harvard Business School. • Butler, T. (2007). Getting unstuck: How dead ends become new paths. Boston, MA: Harvard Business School Press. Ch. 7 • Bereiter, C., & Scardamalia, M. (1993). Surpassing ourselves: An inquiry into the nature and implications of expertise. Chicago: Open Court. Denise Howard/Stan Settles

26. Assessing Architecting & Architectures In concept In acceptance Success Failure

27. Introduction Staying on course • How can it be determined whether system creation is going well or poorly? • What should both managers and architects watch for • What, if anything, can be learned from systems that successfully completed the journey – as well as those that didn’t Denise Howard/Stan Settles

28. Main Point & Map Assessing how it’s going The surest indicators of a system’s progress toward success or failure are not necessarily quantitative measures. We will look at • Concept phase indicators • Acceptance visibility • Success & context • Flawed systems Denise Howard/Stan Settles

29. I. Concept Concept assessments • Is there trust and confidence between architect and client? • Does the project seem to be going well? • Does the concept inspire more than routine effort among specialists? • “The architectural team … reflects the system it is modeling.” (Rechtin, 1991, 296) team ≡ system Denise Howard/Stan Settles

30. I. Concept Concept assessments, cont’d • Is the concept converging? Is backtracking diminishing? • In the cost modeling world, is the model gaining accuracy? • Do the implementers begin to feel the concept is feasible within constraints? Denise Howard/Stan Settles

31. II. Acceptance System change & builder interests • Does the builder have a proprietary interest in making system elements opaque? • Consider “an enabling clause in all outside contracts and an internal understanding of full cooperation with the architect.” (Rechtin, 1991, 298c) • Changes to element internals during building can have ripple effects -- often not good • Red flag: unhappy architect because of insufficient access to system internals Denise Howard/Stan Settles

32. III. Success The fit with context • The necessary, but not sufficient condition — system utility • “An operational mission was accomplished exceptionally well, in a timely, reliable, and high-quality manner, and did so for many years.” (Rechtin, 1991, 299) Denise Howard/Stan Settles

33. How about a random success? • “There is nothing more detrimental to a program than a random success” • Frank Roberts, Chief Engineer for the TFE 731 Turbofan Engine, circa 1972. Denise Howard/Stan Settles

34. IV. Failure Flaws in the foundation • Lack of contact between architect and client in conceptual design (can result in) • Failure to understand • purposes, • priorities, • necessary resources, • success, • markets, • social, political, economic factors, • opponents • Recovery from one of the above is sometimes possible Denise Howard/Stan Settles

35. IV. Failure Flaws in the concept • Reliance on “expert consensus” with flawed data • Simplification based on immature technology • Inability to adapt to unexpected events • Systems technically or socially ahead of their time Denise Howard/Stan Settles

36. IV. Failure It was ahead of its time • How do you match a system to its time? • A visionary architect may well be ahead of the social and technical horizon • How does the architect handle this? • (Note: There is a field of study on the diffusion of innovation) Denise Howard/Stan Settles

37. IV. Failure Flaws in acceptance • The client is forced to • Accept a lesser system • Or add resources • Multiple flaws are often present in failures, such as • Management errors • Various instabilities: funding, changing goals, sponsors, context (sociopolitical) • Multiple flaws make recovery difficult Denise Howard/Stan Settles

38. Summary Knowing what to look for • Assessing the progress of an architected project requires its own expertise • Evidence of good project progress (or otherwise) can be relatively subtle • Knowing what to look for can allow for corrections and save a project that might otherwise founder on seemingly small issues Denise Howard/Stan Settles

39. Summary Questions for exploring systems • Engineering historian Henry Petroski claims that it is through failure that engineers learn. Why would the text claim that systems failures are too difficult to sort out (Rechtin, 1991, 303c)? Are we missing a valuable source of learning, or is systems failure analysis an unproductive distraction? • What should the triage criteria be for saving a system or letting it go? Denise Howard/Stan Settles

40. Summary Questions, cont’d • Can we learn anything from projects, otherwise excellent, that didn’t take hold in their contexts? • How should we treat systems that were well-conceived and executed, but were simply ahead of their time? • Can a system ever be held in reserve until it is no longer ahead of its time? Denise Howard/Stan Settles