Do the Software Architects get the Needed Support for the job They Perform?


Published on

In this paper, we report on two year case study
research in a software development organization which
includes more than 20 architects of different social profile,
knowledge and time zone locations. During that time, we built
up understanding on how to support software architects in
knowledge codification (converting human expertise to
organized, categorized, indexed, easily accessible knowledge in
a knowledge base form available for the organizational
members). By following an action research cycle, we first
diagnosed the architecting process of this organization and
proposed solutions for identified problems. The revelations
gained over the past two years have resulted in creation of a
theoretical instruction framework of what software architects
do and what support they need.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Do the Software Architects get the Needed Support for the job They Perform?

  1. 1. Do the Software Architects get the Needed Support for the job They Perform? Krešimir Popović Željko Hocenski Goran Martinović IT Solutions and Services Department of Computer and Department of Computer and Siemens Software Engineering Software Engineering Osijek, Županijska 21, Croatia Faculty of Electrical Engineering Faculty of Electrical Engineering Osijek, Kneza Trpimira 2b, Croatia Osijek, Kneza Trpimira 2b, Croatia goran.martinovic@etfos.hrAbstract— In this paper, we report on two year case study codification process (knowledge sharing) because it isresearch in a software development organization which impossible to codify in a document or a database theincludes more than 20 architects of different social profile, knowledge, skills, expertise, understanding and passion of anknowledge and time zone locations. During that time, we built employee.up understanding on how to support software architects in We conducted five case studies at this organization,knowledge codification (converting human expertise to which were all part of an action research cycle methodologyorganized, categorized, indexed, easily accessible knowledge in (whereby researchers and practitioners work together ina knowledge base form available for the organizational directing the course of change and the accompanyingmembers). By following an action research cycle, we first research) [2]. These action research cycles were based upondiagnosed the architecting process of this organization andproposed solutions for identified problems. The revelations lessons learned workshops which were held after eachgained over the past two years have resulted in creation of a project. They helped us gain understanding about commontheoretical instruction framework of what software architects problems which architects encounter and what incentivesdo and what support they need. they need for sharing architectural knowledge. The best way to create these incentives lies in hybrid, Keywords - architect; framework; case study; action research just-in-time tool support. Based on the lessons learned andcycle; knowledge codification. all related observations during the five case studies, we have established a theoretical instruction framework consisting of I. INTRODUCTION architecting activities and support mechanisms for sharing knowledge. This framework helps researchers and Over the past few years more attention has been put on practitioners understand what architects really do and whatthe role of decision making in the software architecting kind of support for sharing their knowledge.process. Consequently, the role of the software architect in This paper is organized as follows. In Section 2, wethis process is a frequently recurring topic of discussion, and report on our case study research conducted over the pastmore and more practitioners and researchers argue on what a two years based on action research cycle; in Section 3, weproper set of duties, skills and knowledge of software conclude and announce future studies.architects should be [1]. The obvious advancements in this architectural II. FIVE CASE STUDIESknowledge community notwithstanding, we argue that some Each case study is based on action research cyclescoping and maturation would be beneficial to both methodology formed as participatory method (see Figure 1)researchers and practitioners. This ensures that the designed [2], based on five step model. It is grounded in practicalmethods, tools and techniques could actually help in solving action aimed at solving an immediate problem situation. Thereal-world problems. The only way to do this is to explore action research cycle requires the establishment of awhat architects do in practice and what kind of support they research environment. It provides the authority, orneed (see Table 1). Over the past two years we have studied sanctions, under which the researchers and host practitionersthe architecting process of a software development specify actions. A key aspect of the infrastructure is theorganization which includes more than 20 architects of collaborative nature of the undertaking.different social profile, knowledge and time zone location.Main focus was how to support architects in knowledge
  2. 2. architects), convening working groups and leading on developments, prompting “next steps” from participants. A. Case study #1: Architect’s activities and roles Definition of the problem - in this case study we were mainly focused on the architect’s activities and roles in the software architecting process. We found that architects are responsible for communication with stakeholders and team members, requirements negotiations, conflict management, modeling design decisions, quality control, searching relevant information, assessing feasibility of the architectural solution, balance between quality criteria, stakeholder concerns, and requirements [3]. Problem carried out - some incentives needed to be created to stimulate architectural knowledge sharing while studying the architecting process [4]. One way to do this is by making codification of architectural knowledge as easy Figure 1: The action research cycle in research environment as possible. Sometimes it was hard to share certain knowledge because of its tacit nature [5]. Tacit knowledge Action research cycles applied during software architect sharing in software development organizations includessupport are described as cyclical processes. activities such as team discussions, helping others adapt to • Diagnosing - corresponds to the identification of customer requirements, team-to-team knowledge transfer, the primary problems that are the underlying updating other team members on technologies or tasks, or causes of the organization’s desire for change. sharing information on how to be successful or most • Action planning - specifies organizational actions productive on a project. that should relieve or improve these primary The best way to increase community performance is that problems. The plan establishes the target for stakeholders and team members are informed of each other’s change and the approach to change. expertise, affiliations, previous work. Creating trust and • Action taking – implements the planned action. improving communication mechanisms in order to increase The researchers and architects collaborate in the the architects’ motivation for cooperation and sharing active intervention into the research environment, knowledge helps in organizational learning. Each month a causing certain changes to be made. joint videoconference was convened between architects to • Evaluating - determines whether the theoretical give them the opportunity to air their concerns and learn effects of the action were realized, and whether more about their each other roles and priorities. A meeting these effects relieved the problems. In the place was held with Lead Change Agent with main goal to explore where the change was successful, the evaluation opportunities for joint working and figure out what technique must critically question whether the action to use for current activities and roles marking. After a few undertaken, among the myriad of organizational weeks it was agreed that cognitive mapping will be used. actions, was the sole cause of success. Where the Once expertise, experience, and know-how have been change was unsuccessful, some framework for the rendered (made) explicit, the resulting content can be next iteration of the action research cycle represented as a cognitive map. A cognitive map served as a (including adjusting the hypotheses) should be representation of the "mental model" of a persons established. knowledge and provides a good form of codified knowledge. • Learning specification - the knowledge gained in The nodes represent the key concepts, while the links the action research (whether the action was between them show the interrelations between concepts. The successful or unsuccessful) is used for restructuring tool chosen for this task was called Mind Manager [6]. of organizational norms to reflect the new Key result – most architects do not have time and all the knowledge gained by the organization during the skills necessary for maximum efficiency in running a project, research. The results of the theoretical framework but some are still capable of overcoming sudden project provide important insight to the scientific issues. community for dealing with future research Evidence – most architects showed that they are capable settings. of recognizing an issue and also recognizing that they are not Processes described above were supervised by Lead the best qualified to deal with it at the moment, then decidedChange Agent. His main responsibilities were: negotiator, to delegate the issue to a more qualified person within theircommunicator, lead researcher in collecting and analyzing personal network. If there was no such person, then this issuedata, reflecting on progress, sharing gathered data, was delegated to a more qualified person outside theirreflections on progress with participants (researches and personal network (possibly referenced by the company). However, some architects have not recognize that the issue is
  3. 3. outside their experience and have therefore caused a delay in Evidence 2 - an existing system for storing architecturehandling the issue and drew the attention of the upper guidelines and best practices was barely used becausemanagement to the problem. The upper management then architects evaluated that current documentation practice isdecided to provide an additional person to help deal with the not worthwhile of their time (e.g., use of non “user friendly”issue. documentation tools for data management, outdated contents, steep learning curve, no automatic systemB. Case study #2: Knowledge sharing notifications about document updates, no tools to visually Definition of the problem - one of the main insights present overall project current state).gained in this case study is that architects benefit from a so-called ‘hybrid’ strategy in sharing architectural knowledge. C. Case study #3: Just-In-Time supportThis means that a proper combination between a codification Architects may benefit from intelligent support during(focused on the use of technology to enable, store, index, architecting activities or automated support for enrichmentretrieve and reuse explicit knowledge, with more emphasis of codified architectural knowledge. This case study arguesplaced on adding knowledge to databases, or otherwise that decision making demands that the decision makers mustdocumenting work processes, best practices, lessons learned, be able to search through the mountains of data and find thehow-to-guides) and personalization strategy (it places right knowledge pieces at the right time [10]. Sinceemphasis on informal-knowledge sharing where the focus is architects are decision makers and leaders [11], theyon connecting knowledge workers for communicating or to definitely benefit from access to and delivery of relevantfacilitate transfer of knowledge, rather than to store it) needs architectural knowledge at the right point in time to maketo be found [7][8]. There was a need to find a way how to well-founded decisions. In case of tacit knowledgestore and classify project tasks (project history road map) so architects must be able to find the right person, instead ofthat other team members can learn from “our” mistakes in the right document.future projects. This observation was made that some team Definition of the problem - at first, during this casemembers encountered the same issues from previous projects study, three issues were problematic in finding adequateand had experience to solve them but other team members knowledge pieces: synchronicity between co-located teams,were not aware of them. That caused problems with the awareness and communication medium.“team synchronicity” and started to impair project overall • Synchronicity - time zone differences and differentteam performance. patterns of working (e.g. national holidays) lead to Problem carried out - to overcome this issue it was limited times when team members can communicateneeded to find a tool to easily manage documents version synchronously.control and search option. It was agreed to use Alfresco • Awareness - geographical separation lead to lack ofcontent management system [9]. Using this tool all team awareness of other team members skills andmembers had a possibility to check if their current issue was expertise or even about their existence in a largesolved before. If it was solved before then they could find project (real-time user profile status).out “who” solved it, “how“ it was solved and contact • Communication medium – sometimes it was not“problem solver” to discuss details personally. Contacting possible to communicate face-to-face because ofthe “problem solver” has shown that it is more appropriate in team member geographical dislocation. Withorganizations facing unique problems or a high level of differences in time zones and other workingcreativity is needed to meet specific needs or when similar patterns, team members have not always been ableproblems require customized solutions because of the to communicate directly.influence of a highly adaptive environment. Problem carried out - solution to these issues was to Key result 1 - when sharing experience, people prefer to encourage team members to record their knowledge bylook for support from personal networks rather than from using informal collaboration tools (wikis, forums, instantelectronic networks to gain knowledge about the knowledge. messaging, video conference calls, e-mails, blogs, podcasts, Evidence 1 – we observed that majority of team social bookmarks, remote desktop viewings). These toolsmembers preferred talking to their social circle than invest have low barriers for entry, so team members can easilytime in searching an electronic network for answers. When record their knowledge. Discussing technical issues online,asked why, the replies went in two directions: preference to using a threaded discussion system (forum) made the resultstalk and discuss issues directly rather than searching for visible and searchable for all participants. Informalanswers in piles of documents; confidence in the answer if it collaboration tools have offered more than the basiccame from a trusted source, rather than anonymous communication functions provided by e-mail andknowledge base post (with unknown history of dealing with conventional telephones. First of all, these tools made teamsimilar problems). Even team members working from members aware of each other. This occurred directlydifferent time zones preferred waiting for a direct answer through the function of "presence," simply by logging into afrom knowledge authority rather than searching electronic network, so that others can tell that youre present, or morenetworks. indirectly through discovery of new contacts on social Key result 2 - most mechanisms in place to share networks. After team members become aware of each other,knowledge are ineffective. then they were able to communicate and work together to achieve common business goals. An interesting side effect
  4. 4. of informal knowledge sharing tools, such as blogs, hasshown that they increase awareness. When team membersread blogs, they learn “who” the authors are and what theirareas of interest and expertise are. This allowed users toconvey their ability and willingness to communicate. Key result - team members were more willing todiscuss creative solutions with each other (videoconferencing or live chat) if they were able to make a betterassessment of their colleagues personalities and expertise. Evidence – face-to-face communication has shownusefulness when developing new technical concepts orduring a requirements analysis phase with businessstakeholders. These processes become truly effective onlywhen the participants could see each other because of theimportance of nonverbal communication. Taking part in a Figure 2: Tools used by community of architectsvideoconferencing session in real-time is the next-best thingto face-to-face communication. It helped to build mutual This insight helped architects in various activities such astrust and understanding. This, in turn, lead the team conducting reviews, writing reports, communication withmembers being willing to explore innovative, "crazy" ideas stakeholders. We also learned, that certain so-called ‘wiki(thinking out loud) that involve recombination of patterns’ [12] need to be kept in mind to prevent things goinginformation in non-obvious ways. out of hand. In that way uniform codification of specific types of knowledge is preserved. But all these insights during “our” project showed that a versatile tool in itself is notD. Case study #4: Community groups enough [13]; process rules and guidelines will be also needed In this case study we explored usage of informal to make effective use of the tool and to position it correctlycollaboration social tools for sharing specialized architectural in the process of software architecture.knowledge divided by community groups of certain Key result – communities of like-experiencedexpertise. These tools have showed several characteristics individuals help integrate newcomers to the project.which make them very suitable as knowledge sharing Evidence - adding manpower to a late software projectenvironment in the architecting process: makes it later (Brooks’ law). To overcome this issue, Definition of the problem – three main problems: communities of like-experienced individuals are useful in Increase in effectiveness of complex tasks - integrating newcomers. Pair programing, code reviews and complex software systems include a large number requirements discussions that are already ongoing within the of requirements. Many of them were initially community, greatly improved the introduction of project informally specified because business stakeholders concepts to newcomers. Newcomers were more aware of were not trained to provide formal specification. It their responsibilities and the responsibilities of others, as has been consistently proved to be impractical to well a overall integration of components into the project and specify large systems formally. During this case their part in the project. study software requirement specification often changed, adding further to the degree of uncertainty. E. Case study #5: Conflict management Lower barriers - cultural issue, language issue, Conflict may be defined as a struggle or contest between newcomer’s issue (newcomers to the project cannot people with opposing needs, ideas, beliefs, values, or goals. easily be assigned to mentors who are located on a Conflict on teams is inevitable; however, the results of different continent. They gain access to the project conflict are not predetermined. Conflict might escalate and history through collaborative tools for knowledge lead to nonproductive results, or conflict can be beneficially sharing). resolved and lead to quality final products. Therefore, Facilitate metrics and analysis – training and usage learning to manage conflict is integral to a high- of complex analytic tools to measure collaboration, performance team (Human influences made a 22x difference thereby providing useful management information. in total project effort and cost, according to COCOMO II) [14]. Conflict management is the principle that all conflicts Problem carried out - informal collaboration tools cannot be resolved, but learning how to manage conflicts were adopted by the architects and they were considered can decrease the odds of nonproductive escalation [15]. as clear improvement over the current documentation Definition of the problem - in this case study we argue system they had. Informal collaboration tools have been that conflict management involves acquiring skills related to used for creating a ‘community of architects’ (see Figure conflict resolution, self-awareness about conflict modes, 2) in which everybody knows from each other where conflict communication skills, and establishing a structure certain expertise or experience resides. for management of conflict in work environment. Problem carried out - to prevent negative conflicts several main ground rules (positive and negative behavior)
  5. 5. had to be enforced by Lead Change Agent to prevent action- architects really do and what kind of support for sharingresearch cycle fails (or it will loop indefinitely). The most architectural knowledge would be most suitable in specificimportant rule followed by the Lead Change Agent was: situations.“Don’t be afraid to replace bad people”. We don’t say this In the future, we plan to extend our experiments to makelightly, but we had software architects which too often the most of the opportunities presented by the globalignore problems of employees due to fear of confrontation, economy. Enterprises need a comprehensive, streamlinedor lack of understanding of the technical aspects of the communications infrastructure. This is one that integrates allemployee’s job. It was shown during this case study that it of their communication devices and software – unifiedis better to confront the problematic employee as the best collaboration in cloud as SaaS (Software as a Service inway to influence a change of attitude. E.g. if there were cloud computing). In the unified communicationproblems at home, they needed more time to deal with their environment, all communication tools — from voice, data,personal issues, or they have been asked to perform a task video conferencing and instant messaging through e-mailbeyond their capabilities and needed more training. When and text messaging — are fully integrated in real time andthe problem still persisted (employee was still presented by one overall Web 2.0 interface. The goal wouldunderperforming or causing problems in the workplace) be to investigate and show metrics on productivity,then she/he should be replaced because of her/his impact on complexity and cost reduction as well as work relationshipsthe morale of other employees. in unified environment. This would certainly be necessary Key result - all conflicts must be resolved before the because during case studies architect used lots of tool ofblame-game starts between team members. different vendors which become burden in case of usability. Evidence - blame-game starts after a conflict has beenignored for too long. When blame-game starts, the whole REFERENCEScommunication structure of the project is in jeopardy – face- [1] P. Clements, R. Kazman, M. Klein, D. Devesh, S. Reddy, P. Verma,to-face communication is avoided, team members start “The Duties, Skills, and Knowledge of Software Architects“,acting defensively about every decision, personal attacks Proceedings of the Sixth Working IEEE/IFIP Conference on Software Architecture, January 2007, pp. 20, doi:10.1109/WICSA.2007.41start, communication is interrupted when a team member [2] R. L. Baskerville, “Investigating Information Systems with Actionfeelings get hurt. Every project that reached the blame-game Research”, Communications of the AIS, vol. 2, issue 3es, pp. 2-31,stage continued with the same communication problems November 1999.even after the original conflict was resolved, because things [3] P. Kruchten, What do software architects do?, Technical Report SEIhave been said that shouldn’t have been said and people’s online report, April 2006.feelings got hurt. [4] T. Ghosh, Creating Incentives for Knowledge Sharing. Technical report, MIT Open Courseware, Sloan school of management, III. CONCLUSION AND FUTURE WORK Cambridge, Massachusetts, USA, 2004. By conducting two years of case study research in a [5] L. Argote, Organizational Learning: Creating, Retaining, and Transferring Knowledge, Kluwer Academic, Boston, development organization which includes more [6] MindJet company,, May 2010.than 20 architects of different social profile, knowledge and [7] M. T. Hansen, N. Nohria, and T. Tierney, What’s Your Strategy fortime zone location we have built up an understanding of Managing Knowledge? Harvard Business Review, 77(2):106–116,what architects in practice do and what kind of support they 1999.need. This paper argued that architects do much more than [8] M. Huysman and V. Wulf, “IT to Support Knowledge Sharing intake design decisions or produce architectural Communities, Towards a Social Capital Analysis”, Journal ofdocumentation. Architecting requires that they spend a Information Technology, vol. 21, pp. 40–51, 2006.significant portion of their time on communication with [9] Alfresco Software Inc.,, May 2010.colleagues or other stakeholders, quality control, and on [10] L. Kerschberg and H. Jeong, “Just-in-Time Knowledgeexpanding their knowledge in any way they can. Management“. In Professional Knowledge Management, vol. 3782,Consequently, to assist architects in sharing knowledge pp. 1–18. Springer Berlin / Heidelberg, 2005.during all these activities, support for codification of [11] P. Eles and P. Cripps, The Process of Software Architecting, Addison-Wesley Professional, ISBN-13: 978-0-321-35748-9, Julyarchitectural knowledge is not sufficient. Explicit 2009.mechanisms for managing decisions, searching relevant [12] S. Mader, Wiki Patterns, John Wiley & Sons, ISBN: 978-0-470-information or finding the right colleague are at least 22362-8, December 2007.equally important to ensure that architectural knowledge is [13] P. Barthelmess, “Collaboration and coordination in process-centeredacquired ‘Just-in-Time’. To further alleviate the workload of software development environments”, pp. 911-928, University ofarchitects, support or enrichment of architectural knowledge Colorado at Boulder, Campus Box 430, Boulder, CO 80309-430,may prove valuable as well. Experiments with informal USA, April 2003.collaboration tools indicated that only lightweight and [14] S. McConnell, “10 Most Powerful Ideas in Software Engineering“,versatile knowledge management platforms which include 31st International Conference on Software Engineering, Companion Volume, pp. 12-12, doi: 10.1109/ICSE-COMPANION.2009.5070958aforementioned support create the required incentives to [15] K. Popovic and,Z. Hocenski, “Conflict management”, Proceedings ofmotivate architects to share architectural knowledge. In the 2009 ICSE Workshop on Leadership and Management inaddition, we argued that instruction framework could help Software Architecture (LMSA 09), May 2009, pp. 15-19, doi:both researchers and practitioners to understand what 10.1109/LMSA.2009.5074859
  6. 6. TABLE I.WHAT ARCHITECTS DO AND WHAT THEY NEED What software architects do Take decisions Communicate with team members - Weight cons and pros of architectural solutions - Inform team members about tasks and activities - Impact of decisions on architecture - Delegate tasks to team members - Establish guidelines and rules - Talk to team members about arch. issues / topics - Meet stakeholders demands and concerns - Seek for second opinion from team members - Trade conflicts between decisions - Explain arch. rules and principles to team members - Build consensus among stakeholders - Motivate team members - Estimate each team member social and knowledge - Expect from team member only what he/she can give quality Communicate with stakeholders Document knowledge - Report about project current status and progress - Document proposed and final architectural solutions - Elicit stakeholders wishes and concerns - Describe architectural principles for future reuse - Negotiate with stakeholders conflicts - Write project statuses to stakeholders - Store discussions with stakeholders (MoM – Minutes Of - Explain architectural decision to stakeholders Meeting) - Convince stakeholders of the contribution of arch. - Visualize general arch. solutions and sub-solutions using solution graphical tools, e.g. tools based on UML Share knowledge Control process - Evaluate team members and stakeholders deviations from - Learn from team members and stakeholders the agreed architectural guidelines / rules - Ensure that the architecture fulfills the stakeholders - Transfer knowledge to team members during discussions requests - Search for information on the Internet, Intranet (Wikis), - Update or improve architectural documentation if publications and articles approved by stakeholders - Learn from project good and bad sides (lessons learned) - Judge the architecture on correctness and completeness and share it with team members - Share social skill knowledge - Keep track of timeline progress Conflict management - Resolve personal issues as mediators between team members - Reorganize team member tasks due to personal issues - Ready to perform unpopular decisions for the benefit of project - Calm under pressure when project timeline and conflict resolving are not leading to final positive conclusion What do the software architects need Codification and personalization support Searching for knowledge - Notifications of newly available architectural documents, - Retrieval of documents linked to specific architecture articles and publications - Automatically generated document based on specific - List of news and updates in the architecture domain input parameters - Feedback while producing documentation - Periodic updates on specific architectural knowledge - Third-party support/course from specialized external - Search support for reusable guidelines/rules companies - Suggestions and tips which architectural guidelines to apply Management of architectural decisions Community groups - Template for describing architectural decisions - Retrieve experiences from other team members - Store discussion history with stakeholders and team - Overview of conflicting stakeholders requirements members (even external cooperators) - Keep track of changes in decisions via visualization tools - Information exchange via video, voice and chat - Ability to signal team members about specific - Insight in the current problems and bottlenecks documentation updated (e.g. automatic e-mail sending if specific document is updated) - Overview of important architectural decisions - Insight who is working on which parts of the projectCodification and enrichment of architectural knowledge - Detection of architectural decisions with deliverables - Enhancement of documentation with metadata - Overview and modeling of open design issues- Central knowledge repository for all department members (contains documents, best practices, lessons learned, …)