Leadership and Management in Software Architecture

From Workshops

Jump to: navigation, search

Contents

Workshop Co-located with ICSE 2009

Tuesday, May 19th, 2009, 9:00-17:00, Vancouver, Canada

  • Accepted Papers [1] (Zip)
  • Workshop's Agenda [2]

Organizers

  1. Len Bass
  2. Brian Berenbach

Workshop Theme

Software architecture, in education and practice, is primarily concerned with technical issues associated with the quality of software architecture and design. However, as project size increases, leadership and management skills of the architect become more important, to the point where the leadership ability of the project architect can .make or break. a project. This workshop is intended to focus on one often neglected topic of architecture: leadership.

The participants discussed several topics related to leadership and management skills of the software architect. Both experience and research papers were presented on the following topics:

  • Best practices
  • Lessons learned
  • Research in leadership and management
  • Software Team dynamics
  • The effective management of large teams
  • Crisis management
  • Human factors in risk assessment

This is an ideal forum for architects, project managers, and other software professionals to exchange ideas and experiences in leadership and technical management.

The workshop theme is leadership and management skills for the practicing software architect. We intend to focus the workshop on critical aspects of leadership that tend to overshadow any technical skills as project size and complexity increase.

Workshop Goals

The workshop is concerned primarily with leadership and management issues. Other workshops and presentations effectively cover the technical aspects of architecture. We hope to derive from the workshop:

  • Sharing of experiences with a possible compendium of war stories.
  • Compiling a set of best practices in software engineering leadership
  • Pitfalls and traps in technical management
  • The recognition of early warning signs
  • Identification of additional training that software professionals need to accept high level positions of technical leadership on large and/or complex projects.

Types of Contributions

Position papers (3-5 pages) Short papers state the position of the author(s) on any of the topics within the scope of the workshop. For example, position papers could describe experiences with being the lead architect for large development effort or experiences with understanding corporate requirements for leadership skills for architects. Position papers will be evaluated based on their potential for generating discussion, and on the originality of the positions expressed.

Full papers (8-10 pages) describe and report on the evaluation of leadership techniques in support of lead architect activities. For example, a full paper could describe how a comparative evaluation of different techniques was performed in practice an industrial setting; or it may present the results of a lab-based experiment or field trials. Full papers will be evaluated based on the originality and significance of the contribution, soundness of the validation process or quality of the survey procedure, and on the broader applicability of the results.

Informal Papers (1+ pages). Informal papers are those prepared by attendees who do not have the time to prepare a publishable workshop paper. These papers are not peer reviewed and will be given to workshop participants, but will not be published either in the companion proceedings or digitally and the author will not present. In order to submit an informal paper, the author must register for and attend the workshop.

For the formal paper submission, please send a PDF submission conforming to ICSE proceedings format to brian dot berenbach at siemens dot com. More information can be found at the workshop web site.

Important Dates

  • Workshop Paper Due Date: January 11th, 2009
  • Author Notification: February 4th, 2009
  • Camera Ready Paper: February 12th, 2009
  • Informal Paper Due Date: April 1, 2009
  • Workshop: May 19th, 2009

Program Committee

Report of 2009 Workshop

Introduction

The second edition of the Leadership and Management in Software Architecture Workshop took place at ICSE 2009 in Vancouver on May 19, 2009. The attendees were Paul Bannerman, Andre Bondi, Richard Dotson, Rik Farenhorst, Remo Ferrari, Suzanne Garcia, Gail Harris, Andre Karpistsenko, John Klein, Bill Koscho, Nazim Madhavji, Ma Wenting, Martin Naedele, Don O’Connell, Kresimir Popovic, Bill Ries, and Vanessa Stricker. The 2008 edition of the workshop [SEN Notes July, 2008] was primarily concerned with the skills necessary for an individual architect with some attention being paid to how an architect is supported by the organization in the performance of necessary architectural duties. This workshop reversed the emphasis. Primary attention was paid to organizational considerations with some attention being paid to the skills necessary to be an architect. The skills addressed, however, were not technical skills but were leadership and communication skills. The workshop consisted of two portions. In the first portion, there were eight presentations of 15 minutes each. The papers on which these presentations were based are available from the ACM Digital Library (http://portal.acm.org). In the second portion of the workshop, three topics were discussed. These were how to communicate to and convince management of the importance of architectural decisions, roles, responsibilities, and relationships within an organization that involve the architect, and agile methods and architecture. We now summarize these discussions

Communicating to and with management about software architecture and software architectural decisions

This discussion had three different components. What language to use in speaking to management, how to convince management that architecture and architectural decisions have value, and how to involve management in the risk management process.

Language

The language that an architect uses is important and it is important to adjust the language to reflect the understanding of the recipients. An architect must be able to speak in “techno-speak” to those responsible for implementing a system. Problems from below arrive at the architect’s desk in techno-speak and technical decisions being communicated to those below should be couched in techo-speak so that they can be understood. On the other hand, higher level managers speak in “executive-speak” and an architect must be able to speak and understand executive-speak. Executives speak primarily in financial or schedule terms – costs, income, and schedule. Executives also understand the concepts of risk, investment, and opportunity. Technical issues should be couched in terms of risk to cost, schedule, or income or in terms of making investments or taking advantage of an opportunity. Techno-speak, jargon words, or technical acronyms should be avoided when speaking with executives. The attendees made several other points about communicating to management.

  • Business manager incentives are often different than incentives for the architect/development team. The architect must recognize these incentives and couch communication in a fashion to appeal to the business manger’s self interest.
  • The architect needs to navigate between the short-term and long-term goals and communicate business aspects effectively
  • If the business doesn't know how to express or analyze something as an investment, differentiating between the two will be difficult and having an architect in the middle doesn't solve this problem.

Value

There are several different ways to articulate the value of an architecture to a business.

  • The value of architecture is enabling the business to avoid rework downstream that is usually more expensive. A counterpoint is that some in the business world believe that since software is malleable that rework has zero or low cost. The architect must know the cost of different types of rework and know whether those costs are significant in the context of a particular project. It may be that the hardware costs dwarf the software costs and that software rework costs will be negligible compared to hardware costs. Rework also takes time and time may be more valuable to the business than cost. The architect must know the values of management and shape their argument to appeal to these values.
  • A value of architecture is in helping business leaders understand the decisions that need to be made and the implications of those decisions. Technical options must be couched in business terms. E.g. option 1 has a higher long term cost but a smaller short term cost whereas option 2 is the opposite.
  • A value of architecture is to help the organization understand its business goals, based on architecture decisions that are being made. E.g. do we need to be able to sell this system internationally? If so, we need to make an investment to implement a particular technical option to support subsequent international sales.

The attendees expressed concern that architects were not always “given a seat at the table” when management decisions that affect them are being made. Several points were made.

  • An architect must have credibility in order to be given a seat.
  • CIOs also have difficulty getting a seat.
  • Governance mechanisms may be a mechanism to get architecture viewpoint included in the "business" governance of the enterprise

Risks

Risks and the risk management process are an area where the responsibilities of the architect and the responsibilities of management intersect. Risks should be managed as a portfolio and having a portion of the governance structure for a project include a periodic assessment of risks and the progress toward mitigating those risks is a good mechanism for communicating to management the progress that a project is making and in gaining credibility for the architect. It will also give management insight into the decision process and help convince them that good decisions are being made. This returns to the language issues. The discussion of risk has to include the business implications of the options being considered in order to build credibility.

Roles, responsibilities, and relationships

An architect has certain roles within the organization and has responsibilities associated with those roles. The architect also has relationships within the organization. The discussion on this topic also touched on the skills that the architect needs in order to satisfy the responsibilities. The specifics of this topic include the different types of architects and their associated roles, how an architect builds credibility and influences others, the skills involved in being a good architect, and professional certifications.

Types of architects

An important observation is that there are a number of different types of architects and the type of architect that is being referred to will impact the roles, responsibilities, and relationships that the architect should have. Some of the different types of architects mentioned were corporate level architect of IT systems (an enterprise architect), systems architects as differentiated from software architects, an architect involved in bidding on large commercial system i.e. for a new database system for social security, a project architect who is the architect for constructing a particular project, and an architect that works with product management to develop software products. Clearly, some of these roles may overlap and may be satisfied by the same person but some organizations have one set of architects involved in the bidding process and another set involved in the construction of successful bids. The highest visibility type of architect, according to the discussion, was the architect involved in the bidding process since they were responsible for helping to bring new business into the organization. The further an architect was from a profit center, the less visibility they had. In nonprofit projects, making the cost of failure visible to management is another form of acquiring visibility. Regardless of the type of architect, they must involve all of the stakeholders in the architecting process. The type of involvement will depend on the particular stakeholder but involving the stakeholders is essential. Management must be involved so that they have visibility into the project and trust in its successful conclusion. Customers must be involved so that they have confidence their needs will be met, and developers must be involved so that they have bought in to the architecture and have an understanding of the rationale behind particular decisions and the knowledge to know when to question other decisions. Furthermore, some types of architects should be involved in the creation of a roadmap of products and in the determination of business opportunities for new products based on technological change and the current product suite. Sometimes this involves some aggressiveness on the part of the architect since they may not be asked to participate in particular activities. This does not mean that the architect makes business decisions but it does mean that they must understand the relationship between the business goals, the technology, and the current product suite and be able to communicate their insights in business terms.

Building credibility

An architect has to build credibility among the stakeholders including the developers, the customers, and management. This is done by viewing architecting as a service. Credibility is developed slowly and the architect must communicate and coordinate in three directions – up, down, and laterally. In communicating up the following points were made.

  • The architect must find ways to visibly solve problems that business needs to have solved (pain points) even if they're not the primary "duties" (transforming work products) of the architect.
  • Sometimes finding a business champion that understands the technical issues is a better way to communicate than doing it yourself
  • The architect has to derive what is valued by the business managers from information/communication that is not focused on the architectural issues
  • Building credibility with management is very difficult if management is continually being rotated to different positions or if management is dysfunctional.

In communicating down, the following points were made.

  • The software architect needs to have the developers and coders have faith in him or her.
  • Using mandates is usually not as effective as having influence. Stating a mandate encourages people to think of methods for getting around the mandate whereas having influence encourages people to trust in you and your judgment.
  • It should be made clear what an architect is accountable for. This will encourage people to bring problems to the architect that are within the scope of his or her responsibilities.

Skill set

An architect is the technical counterpoint to the project manager. An architect must have leadership skills that include the ability to make decisions, to influence others, and to delegate. Some leadership skills are innate but they can be improved with training. The training, however, must be hands on in some sense. Simply listening to lectures about leadership skills is not effective. There is a different skill set necessary to make $1000 decisions than to make $10 Million decisions. The scope of an architect’s responsibilities should match the skill set they have in terms of the impact of their decisions.

Professionalism

There was a brief discussion about whether industry wide professional certificates would help in establishing the role of the architect within an organization. The point was made that some organizations (Boeing and Siemens of the organizations represented at the workshop) have their own internal architect certification. Each organization has its own requirements because of the domain in which they work. Industry wide certification may not make sense because of this diversity. For example, the scale of decision making as a professional Java architect is very different from the scale of decision making of a Boeing airplane certified software architect.

Agile methods and architecture

Finally, there was a discussion about how the use of agile methods might affect the other topics discussed. The fundamental conclusion was – not very much. Some of the points made were

  • Providing incremental delivery is one means for communicating to stakeholders.
  • Having user involvement is another means for communicating to stakeholders although users are not necessarily a good source for requirements, especially in projects that change business processes.
  • There are terminology differences between the roles as described in an agile process and the terminology used by architects but there are not substantive differences. The agile methods recognize the need for an architecture, have lead designers who might be called architects in other contexts, and face the same problems of having to communicate with management in executive-speak.
  • The type of project will dramatically affect the roles and activities. The analogy was made to building a thatched hut versus building a skyscraper and the amount of up front planning required in each case.

Previous Gathering

Some Useful References

Retrieved from "http://www.lmsa-community.org/wikis/index.php/Leadership_and_Management_in_Software_Architecture"
Personal tools