Mark Richards is a director and senior solutions architect at Collaborative Consulting, LLC, where he is involved in the architecture and design of large-scale service-oriented architectures in J2EE and other technologies, primarily in the financial services industry. He has been involved in the software industry since 1984, and has significant experience in J2EE architecture and development, object-oriented design and development, and systems integration.
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 how to communicate the goals and objectives of a software project. The key to effective communication is clarity and leadership.
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 frequently. Another effective means of communication is informal whiteboard meetings. Nothing gets your ideas across better than bringing a group of developers (or other architects) into a room and whiteboarding your ideas. Also, be sure to 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 whiteboard. Snap a picture, download it, and share it via a wiki with the rest of the team. Throw away the lengthy Word documents and focus more on getting your ideas across, and afterward worry about recording the details of your architectural decisions.
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 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. Keep in mind that all team members (e.g., the QA team, business analysts, and project managers, as well as developers) require clear communication and leadership. Employing clarity and demonstrating effective leadership will improve communication and create a strong and healthy work environment.
If "Communication Is King," then clarity and leadership are its humble servants.
Get 97 Things Every Software Architect Should Know now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
