All too often software architects sit in their ivory towers, dictating specifications, technology decisions, and technology direction to the developers below. More often than not this leads to dissension in the ranks, quickly followed by a revolt by the masses, finally resulting in a software product that doesn't even come close to resembling the original requirements. Every software architect should know about and practice the 3 C's of software architecture: Communication, Collaboration, and Clarity.

All too often software architects sit in their ivory towers, dictating specifications, technology decisions, and technology direction to the developers below. More often than not this leads to dissension in the ranks, quickly followed by a revolt by the masses, finally resulting in a software product that doesn't even come close to resembling the original requirements. Every software architect should know about and practice the 3 C's of software architecture: Communication, Collaboration, and Clarity.

-

Communication is vital to the success of any software project. To create successful software, architects must communicate with developers, developers must communicate with architects, and so on. However, in my experience this does not occur as often as it should. Instead, architects hand off large documents or Visio diagrams to developers without explaining or describing the context of why decisions are made. The most effective means of communication bar-none is the whiteboard meeting. Nothing gets your ideas across as an architect better than bringing in a group of developers (or other architects) into a room and whiteboarding your ideas. The main point here is this; throw away the Visio diagrams and Word documents. Focus more on getting your ideas across. Once developers and other architects understand your ideas, then worry about recording the details of your architectural decisions.

+

''Communication'' is vital to the success of any software project. To create successful software, architects and developers must communicate. However, this rarely seems to happen. Instead, architects hand off large documents or complex Visio diagrams to developers without explaining why decisions were made. A much more effective means of communication is informal whiteboard meetings. Nothing gets your ideas across better than bringing in a group of developers (or other architects) into a room and whiteboarding your ideas. So throw away the lengthy Word documents and focus more on getting your ideas across, and afterwards worry about recording the details of your architectural decisions.

-

Collaboration, the second "C", refers more to the type of relationship you develop as an architect between developers and other architects. One thing most software architects fail to realize is that a software architect is also a leader. As a leader, you must gain the respect of your co-workers to work effectively in a healthy and effective environment. Keeping developers in the dark about the big picture or why decisions were made is a clear recipe for disaster. Having the developer on your side creates a collaborative environment whereby decisions you make as an architect are validated. In turn, you get buy-in from developers by keeping them involved in the architecture process. Work with developers, not against them.

+

''Collaboration'' refers more to the type of relationship you develop as an architect between developers and other architects. One thing most software architects fail to realize is that a software architect is also a leader. As a leader, you must gain the respect of your co-workers to work effectively in a healthy and effective environment. Keeping developers in the dark about the big picture or why decisions were made is a clear recipe for disaster. Having the developer on your side creates a collaborative environment whereby decisions you make as an architect are validated. In turn, you get buy-in from developers by keeping them involved in the architecture process. Work with developers, not against them.

-

Clarity, the third "C" of software architecture, describes how you communicate. No one on your team is going to read a 100 page architecture decisions document. Being clear and concise in the way you communicate your ideas is vital to the success of any software project. Keep things as simple as possible at the start. By all means, at the start of a project do not start writing lengthy Word documents. Use tools like Visio to create simple diagrams to convey your thoughts. Keep them simple, for they will almost certainly be changing daily. Also, be sure to always have a digital camera or cell phone with a camera with you at all times. Nothing is more frustrating than being pushed out of a meeting room with all of your ideas stuck on a white board. Snap a picture, download it, and share it via a wiki to the rest of the team.

+

''Clarity'' describes how you communicate. No one on your team is going to read a 100 page architecture decisions document. Being clear and concise in the way you communicate your ideas is vital to the success of any software project. Keep things as simple as possible at the start of a project, and by all means do not start writing lengthy Word documents. Use tools like Visio to create simple diagrams to convey your thoughts. Keep them simple, for they will almost certainly be changing daily. Also, be sure to always have a digital camera with you at all times. Nothing is more frustrating than being pushed out of a meeting room with all of your ideas stuck on a white board. Snap a picture, download it, and share it via a wiki to the rest of the team.

-

It is unfortunate that communication skills are not a requirement for a software architect. Remember, as a software architect you are also a leader, and as a leader you are responsible for bringing the team together to reach a common goal. By practicing the 3 C's of software architecture, you can more effectively reach out to your team members and create a strong and healthy work environment.

+

It is unfortunate that communication skills are not a requirement for a software architect. Remember, as a software architect you are also a leader and therefore responsible for bringing the team together to reach a common goal. By practicing the 3 C's of software architecture, you can more effectively reach out to your team members and create a strong and healthy work environment.

Current revision

Communication is King

All too often software architects sit in their ivory towers, dictating specifications, technology decisions, and technology direction to the developers below. More often than not this leads to dissension in the ranks, quickly followed by a revolt by the masses, finally resulting in a software product that doesn't even come close to resembling the original requirements. Every software architect should know about and practice the 3 C's of software architecture: Communication, Collaboration, and Clarity.

Communication is vital to the success of any software project. To create successful software, architects and developers must communicate. However, this rarely seems to happen. Instead, architects hand off large documents or complex Visio diagrams to developers without explaining why decisions were made. A much more effective means of communication is informal whiteboard meetings. Nothing gets your ideas across better than bringing in a group of developers (or other architects) into a room and whiteboarding your ideas. So throw away the lengthy Word documents and focus more on getting your ideas across, and afterwards worry about recording the details of your architectural decisions.

Collaboration refers more to the type of relationship you develop as an architect between developers and other architects. One thing most software architects fail to realize is that a software architect is also a leader. As a leader, you must gain the respect of your co-workers to work effectively in a healthy and effective environment. Keeping developers in the dark about the big picture or why decisions were made is a clear recipe for disaster. Having the developer on your side creates a collaborative environment whereby decisions you make as an architect are validated. In turn, you get buy-in from developers by keeping them involved in the architecture process. Work with developers, not against them.

Clarity describes how you communicate. No one on your team is going to read a 100 page architecture decisions document. Being clear and concise in the way you communicate your ideas is vital to the success of any software project. Keep things as simple as possible at the start of a project, and by all means do not start writing lengthy Word documents. Use tools like Visio to create simple diagrams to convey your thoughts. Keep them simple, for they will almost certainly be changing daily. Also, be sure to always have a digital camera with you at all times. Nothing is more frustrating than being pushed out of a meeting room with all of your ideas stuck on a white board. Snap a picture, download it, and share it via a wiki to the rest of the team.

It is unfortunate that communication skills are not a requirement for a software architect. Remember, as a software architect you are also a leader and therefore responsible for bringing the team together to reach a common goal. By practicing the 3 C's of software architecture, you can more effectively reach out to your team members and create a strong and healthy work environment.