Wednesday, January 31, 2007

Effective Presentations by Software Architects

In an earlier post the topic of clear, concise, and terse writing was presented. This post raises the importance of effective architecture presentations. It’s critical for every architect to be able to create and deliver effective presentations in an amount of time allocated. The following tips, derived from experience, should be kept in mind. It is assumed you’ll be using a Power Point or similar software.

  1. Mind your audience. It’s imperative to set the tone and presentation content based on the audience and audience’s expectations. If someone requests a presentation on the architecture of a system find out what they want to get out from the presentation. This will make the process of creating the presentation easier and your results will be measurable.
  2. Mind your time. If you’re allowed 30 minutes for presentation you will only get 30 minutes. This is especially true with angel investors, venture capitalists, executives, and anybody who simply values their time. Extenuating circumstances aside – running out of time is a result of poor preparation.
  3. Preparation is essential. Throwing some diagrams together and trying to wing it will result in poor quality. The presentation must have a flow that tells a story that your audience cares about. Prepare a handout outlining the key aspects of your presentation, but only distribute it when you start speaking.
  4. Be professional. Your presentation slides must be in a consistent format. Font, positioning, color scheme must be uniform.
  5. Practice. Most people fear public speaking. Those who don’t are unique or liars. When you hear yourself talk aloud while standing you’ll feel the areas of the presentation that do not transition well. Practice presenting in front of an audience even if it’s just one person who doesn’t know anything about software architectures. Practice will logarithmically build up your confidence unless you don’t know what you’re talking about.
  6. Know your subject matter. The audience will be able to tell if you don’t know what you’re talking about – just by seeing your gestures, tone, and logic. Anticipate tough “why” questions and be able to respond intelligently. After all an architect must always explain why a give decision was made or not made.
  7. Backup slides. Include backup slides at the end of your presentation if audience wants more detail on some part of a system presented earlier. Backup slides don’t need to be polished.

Remember that as a software architect you’re the chief spokesperson for a software system.

- Firebrand Architect on duty: CK

Wednesday, January 10, 2007

Architects need to improve their written communication skills

Effective written communication skills are essential for every software architect. Expressing your ideas clearly, tersely, and effectively is paramount. If your audience does not fully understands your vision or design, then you’ll have to build (and probably fund) the system yourself. It is your responsibility, as the architect, to ensure that your readers understand your ideas.

Written communication is important, because that’s the only effective way to communicate with a large number of people who may be geographically distributed across the world in different time zones. A single software architecture design package is often the source of reference for hundreds of people on a large scale system or a system of systems.

The international software engineering community recognizes English language is the standard language for cross cultural communication. Therefore it is paramount for any software architect to improve their skill set of the written English. Improving written English is probably even more important than improving oral English.

There might be many guidebooks for improving your writing, but my colleague and scholar of the English language recommended only one book: “The Elements of Style” by William Strunk. The book has been in print for a few decades. It is available in the original edition, the illustrated hard cover edition (my copy), and the fourth edition. The content is about the same across all of the editions. This book is a definitive reference guide for an everyday writer. The book has no prerequisites and can (and should) be used by every technical person. After using this book you will notice that your ideas are shaped more clearly and your sentences are easier to understand. This book belongs on your technical books bookshelf.

Sunday, January 07, 2007

Beyond technolgoy in technical books - joy for architects

The winds are changing – the software engineering mainstream practitioners are finally starting to value the importance of the human aspects of software engineering. And that’s only good news for software and solution architects.

If you’ve been reading some of the newer technical literature, such as the Pro [Microsoft] BizTalk 2006 book, you would have noticed one paramount shift in the book’s introduction part. First the authors provide the core overview of the BizTalk architecture, as expected, but then spend the next chapter going over various human and organizational aspects of running a project.

This is important. This shows a conscious effort on behalf of the authors to convince the reader that establishing a technical and management structure is essential to the success of the project. The book provides brief guidance for setting up communication chain of command, provides an example of a rudimentary build and deployment process, and emphasizes on the importance of organization and team work.

Most books a specific technology only concentrate on technology and often neglect the human aspects of software architecture. The Pro BizTalk 2006 does a fine job of emphasizing, if not requiring, that software engineering practitioners follow best practices when utilizing BizTalk 2006.

- Firebrand Architect on duty: CK

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...