Session:An Architect's Competencies and Duties--Discussions
From WICSA Conference Wiki
Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this working session.
Contents |
Attendees
Please add yourself to this list. Tell us something about your background. Add to the Discussions questions section below a few sentences about the working session topic such as your position and questions you would like to see discussed.
Paul Clements: Dr. Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked since 1994 leading or co-leading projects in software product line engineering and software architecture documentation and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: "Software Architecture in Practice" (1998, second edition 2003), "Evaluating Software Architectures: Methods and Case Studies" (2001), and "Documenting Software Architectures: View and Beyond" (2002). He also co-wrote "Software Product Lines: Practices and Patterns" (2001), and was co-author and editor of "Constructing Superior Software" (1999). In addition, Clements has also authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems.
Dan Paulish, Siemens Corporate Research (USA)
Bhudeb Chakravarti, National Institute of Smart Government & IIIT, Hyderabad
Remco de Boer, Vrije Universiteit Amsterdam (NL)
N. Swaminathan, Business Systems and Cybernetics Centre, Tata Consultancy Services (India)
Patricia Lago, Vrije Universiteit Amsterdam (NL)
Key ideas
(key ideas, how papers relate to each other and support the session theme)
- definitions or concepts of competence
- measuring competence
- strategies or practices to improve competence
- what architects must do/have/know in order to be competent
See also http://www.sei.cmu.edu/architecture/competence.html
Discussion questions
1. What is a working definition of architecture competence?
2. How do we measure competence? If we measure it by only looking at past results, is that practical? If we measure it by measuring how well architects do the day-to-day activities they must do, is it accurate?
3. Can we produce one or models that explain/predict competence? For example, a duties/skills/knowledge model of competence would say that an architect must do prescribed duties well, have specific skills, and exercise specific knowledge, and how well they do/have these things correlates positively to the quality of the architectures they produce. Another model might look at an organization's internal commmunication paths and the roles/responsibilities of its members. And so forth.
4. There are many kinds of architects (enterprise, software, system, platform, application, etc.). Can we produce a model of competence that applies to them all? Should we?
5. There are many organizational "units" in whose competence we are interested: individual architect, architecture team, architecture department, development project, development department, business unit, whole organization. How does the competence of these various units affect each other (can a competent individual do good work in an incompetent organization?)? Can we come up with a single model that fits all levels? Should we?
6. The end game for studying and measuring competence is improving competence. What are strategies we can use to do that?
Discussions
After two paper presentations, our group brainstormed a specific list of discussion topics, and then voted on which to pursue. The list, with each topic preceded by the votes it was awarded, follows:
11 Core competencies
1 Competence in design using “standard” architectural approaches
12 Categories of the duties, skills, and knowledge
8 Project management competence vs. architecture competence
5 Competence of an organization or consortium of organizations
3 Responsibilities linked to competencies needed to fulfill them
11 How do we measure competence? (individual, team, org.)
First discussion topic: Categories of duties, skills, and knowledge
Project manager: Resource allocation
Architect: Solutions
Customer relations manager: Customer needs
Competence in service organizations vs. other kinds of organizations
Second discussion topic (quickly deemed highly related to the first): Core competencies
A “core” competence is one that, if a person does not have, we do not consider that person an architect.
Other (non-core) competences might be something we would expect from any senior technical person.
Might want to compare duty categories with standard architectural approaches (4+1, Zachman, TOGAF, …) to make sure that the duties listed are sufficient to allow successful execution of the chosen approach.
Third discussion topic: Measuring competence
• Basic, advanced, expert scale
• Post hoc: Measuring customer satisfaction, success of architectures
• Kornferry Intl., LA-based
• Think of a known-to-be-competent architect – why are they so?
• Can have benchmark solutions, and compare architects’ work against those
• Result: matrix?
• Want to measure competence of teams, e.g., 2 architects with complementary non-overlapping skills
• Competence of an “architecting unit” (person, pair, team, …)
• Two parts: Person’s intrinsic competence / “Ability to perform” in a given context or environment
• Have architect participate in (e.g.,) architecture evaluation exercise and test his/her skills in doing so
• Certification of (levels of) architects
Competence of organizations
• Architects are demonstrably valuable: salary, prestige, …
• Able to embrace culture, how arch. processes are carried out, how they fit in org. culture in general; related to project mgt., etc.
• Need to have separate architecture processes
• Has strategic value in s/w development process
• Has to provide the context in which competent architects can perform well
• Has career path for architects
• Training and skill improvement opportunities
• Someone to match skill sets to needs
• Collaborate, reuse, and share architectural solutions and artifacts
• Institutionalize design patterns and other standard solutions
• Ability to solve a particular class of problems
• Maturity of processes; asset base
• Knowledge base (problem understanding)
• Demonstrated ability to deliver effective solutions in a problem space
• Domain knowledge
• Ability to document architectures
• Codification and socialization [solutions, processes, etc.]
• Ability to find faults with others (and knowing when not to identify them openly)
• [Many of these have counterparts in the individual-competence list]
• Able to “sell” your architecture
• Gain customer confidence in your architectural solutions
• Have plans for technology-development partnerships; have technical vision of the future
• Clearly defined roles/responsibilities/authority for architects that are focused and situation-dependent
• Architecture review board
• Back-up architects available; bench strength. Not critically dependent upon an individual, who might get hit by a bus
• Organization clearly and demonstrably values architectures and architects
• Presence (must have architecture) and explicit recognition of architects and architecture
• Doesn’t just use the term to impress people
• Ratio of architects in company meets some threshold
