97 things that architects should know _ 04 are centered on communication, taking into account concise and clear expressions and enlightened leadership style

97 things that architects should know _ 04 are centered on communication, taking into account concise and clear expressions and enlightened leadership style

04 communication is king; clarity and leadership, its humble servants
Focusing on communication, taking into account concise and clear expressions and enlightened leadership style

Mark Richard
Mark Richards

All
Too often, software release ts sit in their ivory towers, dictating
Specifications, technology decisions, and technology direction to
Developers below. More often than not, this leads to dissension in
Ranks, quickly followed by a revolt by the masses, finally resulting in
Software product that doesn' t even come close to resembling
Original requirements. Every software architect shocould know how
Communicate the goals and objectives of a software project. The key
Valid communication is clarity and leadership.

Software architects generally like to sit in a comfortable environment and give technical decisions and instructions to developers. This can easily lead to resistance, conflict, and eventually lead to a far cry between products and initial needs. Software architects should improve their communication skills and help everyone understand the project objectives. The key lies in clear and effective communication and enlightened leadership.

Clarity
Describes how you communicate. No one on your team is going to read
100-page architecture Decisions document. being clear and concise in
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
Valid means of communication is informal whiteboard meetings.
Nothing gets your ideas your SS better than bringing a group
Developers (or other tables TS) 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
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
Lengthy Word documents ents and focus more on getting your ideas guest SS, and
Afterward worry about recording the details of your invalid tural
Decisions.

The communication must be concise and clear. No one is willing to read lengthy architecture decision-making documents and express your point of view in a concise manner is a necessary condition for project success. Project startup
At the beginning, everything can be simplified and simple, and never be written into lengthy Word documents. Use tools, such as simple Visio charts, to express your thoughts. Try to make it easier. After all, your thoughts will change
. Another effective means of communication is informal whiteboard meetings, which bring together developers (and other architects) and write down your ideas on the whiteboard, which is more effective than any other method. In addition, do not forget to carry it with you
Take a photo of the content on the whiteboard with a camera and share it with the team through the Wiki. After all, it is not easy to recall the content discussed after the meeting. Get rid of lengthy Word documents and try to make everyone accept your point of view. Don't forget.
Record the discussion results in detail.

One thing most software failed ts 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 valid tive
Environment. Keeping developers in the dark about the big picture or why
Decisions were made is a clear recipe for disaster. Having
Developer on your side creates a collaborative environment whereby
Decisions you make as an effecect 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 valid tive leadership
Will improve communication and create a strong and healthy work
Environment.

On the other hand, architects often ignore themselves as leaders. As leaders, we must gain the respect of our peers before we can proceed smoothly. If the developer
Employees have no idea about the project blueprint and decision-making level, which will inevitably lead to potential risks. Arrange a trusted developer to take the lead in creating a collaboration environment. Please verify your architecture decisions. Let developers participate in the architecture
They will buy your account only during the subscription process. Work with developers. Remember that all team members (including quality control team and Business Analyst)
Project managers and developers are eager for clear communication and enlightened leadership. Only in this way can we improve the communication effect and establish a united and healthy working environment.

If "communication is king," then clarity and leadership are its humble servants.

Focusing on communication, adhere to concise and clear expressions and enlightened leadership style.

About the author:

Mark
Richard is a director and senior solutions under ect at collaborative
Consulting, LLC, where he is involved in the architecture and design
Large-scale service-oriented ubuntures 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.

Mark Richards is collaborative
Consulting is a director and senior Solution Architect of Consulting Limited Liability Company. His main job is to design and provide a large-scale service-oriented architecture for the financial service industry using J2EE and related technologies. From
Since entering the software industry in 1984, he has accumulated a lot of J2EE architecture and development experience, object-oriented design and development, and system integration experience.