Key takeaways:

• Software architecture documentation should be complementary to the code and describe what the code itself doesn’t. For example, it’s really hard to identify things like architectural principles, operational aspects and how security works from just the code itself.
• Keep it short and useful
• What it should contain:
  • Explanation of the software structure
  • The architectural principles and constraints
  • Development and deployment technologies and platforms
  • A justification of how the architecture satisfies the requirements

You can find the slide set here.

BTW: Coding the Architecture contains a lot of useful resources for software architects.

In this truly unique technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects — including Neal Ford, Michael Nygard, and Bill de h ra — offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from years of experience. Among the 97 principles in this book, you’ll find useful advice such as:

• Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
• Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
• Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
• Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
• For the End User, the Interface Is the System (Vinayak Hegde)
• It’s Never Too Early to Think About Performance (Rebecca Parsons)

To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project.

You can find the 97 things for free here.

As a developer, I often wonder which Android platforms my applications should support,especially as the number of Android-powered devices grows. Should my application only focus on the latest version of the platform or should it support older ones as well?

To help with this kind of decision, I am excited to announce the new device dashboard. It provides information about deployed Android-powered devices that is helpful to developers as they build and update their apps. The dashboard provides the relative distribution of Android platform versions on devices running Android Market.

…

In summary, Android 1.5, 1.6, and 2.0.1 are the 3 versions of the platform that are deployed in volume. Our goal is to provide you with the tools and information to make it easy for you to target specific versions of the platform or all the versions that are deployed in volume.

We plan to update the dashboard regularly to reflect deployment of new Android platforms. We also plan to expand the dashboard to include other information like devices per screen size and so on.

Don’t get me wrong: the data is very interesting. However, it strongly reminds me on the situation on Windows, where still about 30% of the users use Windows XP. Having such a big fragmentation of OS versions really forces you to either make big compromises and build your application only using the features of the lowest OS version or to make your application adapt to the OS version it is running on. The later one adds a lot of trouble in development efforts, testing and bug fixing.

Still, it will be interesting to see how the fragmentation of Android devices evolve and how this will influence the attraction of developers providing Apps for the Android OS. Of course, having developers focusing only on certain Android OS versions and/or hardware characteristics could also make the hardware vendors streamline their hardware specs and OS versions. Selling Android devices which show only very few apps on the Android Market might not sell so well after all.

Web Sites

Coding the Architecture

“Coding the Architecture” is a website and community for hands-on, pragmatic software architects. Here you’ll find content and discussion about architecture and the role of an architect, along with our experiences of undertaking that role.

The site is worth browsing through the different articles, providing practical approaches to topics related to software architecture.

Special Links:

• “Why do we need Software Architecture“
• “The role of the Software Architect“
• “How to document Software Architecture“

Design Patterns for .Net

The goal of this site is to not only provide a portal to useful and pragmatic software design and career related topics, but to also deliver articles, editorials, presentations, and news on the same.

Although the title of this site reads like providing special guidance for .NET related Software Architecture, many articles cover topics more related to the role of an Software Architect. However, also best practices for designing solutions for special topics are provided.

Special links:

• What Does it Mean to be a Software Architect? (Part 1, Part 2, Part 3)
• The Hard Skills are the Soft Skills
• The Passage from Developer to Architect
• Architectural Decisions and Their Consequences (Part 1, Part 2)
• Becoming an Architect (Summary Presentation)
• Anti-Patterns: The Top 10 List, The Human Factor

MSDN Architecture Center

This Architecture Developer Center is the place to access to all our information without being subscribed to our other channels. You also get blogged opinions from renowned architects (MS architects or external luminaries), 5-to-10-minute videos , and discussion forums where you might share thoughts with your colleagues.
This center is a place where you can get architecture ideas to be implemented either in the Microsoft platform or any other. We will also show you what the current Microsoft platform is and what its roadmap looks like.

Microsoft’s central starting point for architecture related topics.

Special links:

• The Architecture Journal provides in-depth articles to certain topics, e.g. the role of an Software Architect or other more technical topics
• The patterns & practices group provides guidance for Microsoft related technologies including Documentation and sample implementations of certain patterns, e.g. here can you find a List of Microsoft patterns and practices for Application Architecture and Design, or also have a look at Composite Client Application Guidance which can “help you design and build flexible client applications using loosely coupled, independently evolvable pieces that work together and are integrated into the overall application”.

Resources for Software Architects

Software architecture is getting a lot of attention. Is it just the silver bullet du jour? We think not. It surely is critical to today’s business success, yet it requires technical, business and organizational talents and skills that warrant their own path of career development, education, and research.

This site organizes a variety of resources to help enterprise architects and software architects deepen and expand their understanding of architecture and the role of the architect.

Special Links:

• General Link List for Software Architecture related topics
• Link list to articles related to the role of an Software Architect
• What is Software Architecture?
• Why do we need Software Architecture?

Articles

Escape Metropolis: Bridging the Divide Between Developers and Architects

The conflict between Planners and Workers in the film Metropolis can serve as a metaphor for the divide between architects and developers in the software industry. A veteran who’s been on both sides has some suggestions for bridging the gap.

What Do Architects Do Anyway?

Presentation from Ron Jacobs, Architect, Microsoft Corporation at the Microsoft Architect Inside Conference 2007

Despite what a lot of people believe, it’s easy to introduce memory and resources leaks in .NET applications. The Garbage Collector, or GC for close friends, is not a magician who would completely relieve you from taking care of your memory and resources consumption.

I’ll explain in this article why memory leaks exist in .NET and how to avoid them. Don’t worry, I won’t focus here on the inner workings of the garbage collector and other advanced characteristics of memory and resources management in .NET.

It’s important to understand leaks and how to avoid them, especially since they are not the kind of things that is easy to detect automatically. Unit tests won’t help here. And when your application crashes in production, you’ll be in a rush looking for solutions. So, relax and take the time to learn more about this subject before it’s too late.

Table of Content

• Introduction
• Leaks? Resources? What do you mean?
• How to detect leaks and find the leaking resources
• Common memory leak causes
• Common memory leaks causes demonstrated
• How to avoid leaks
• Tools
• Conclusion
• Resources

…

How to avoid leaks

Now that you know more about leaks and how then can happen, I’d like to stress a few points and give you some tips.

Let’s first discuss about a general rule. Usually, an object that creates another object is responsible for disposing it. Of course, this is not the case if the creator is a factory.

The reverse: an object that receives a reference to another object is not responsible for disposing it.

In fact, this really depends on the situation. In any case, what’s important to keep in mind is who owns an object.

Second rule: Each += is a potential enemy!

Given my own experience, I’d say that events are the main source of leaks in .NET. They deserve double- and even triple-checks. Each time you add a subscription to an event in your code, you should worry about the consequences and ask yourself whether you need to add a -= to unsubscribe from the event. If you have to, do it immediately before you forget about it. Often, you’ll do that in a Dispose method.

Having listener objects unsubscribe from the events they subscribe to is usually the recommended way to ensure they can be collected. However, when you absolutely know that an observed object wont publish notifications anymore and you wish that its subscribers can be released, you can force the removal of all the subscriptions to the observed object. I have a code sample on my blog that shows how to do this.

A quick tip now. Often, issues start to appear when object references are shared among several objects. This happens because it may become difficult to keep track of what references what. Sometimes it’s better to clone objects in memory and have views work with the clones rather than having views and model objects intertwined.

Finally, even if it’s a well-known best practice in .NET, I’d like to stress one more time the importance of calling Dispose. Each time you allocate a resource, make sure you call Dispose or encapsulate the use of the resource in a using block. If you don’t do this all the time, you can quickly end up with leaking resources – most of the time unmanaged resources.

Read the whole article at How to detect and avoid memory and resources leaks in .NET applications.

In this document, I’m going to talk about how to access WCF services using Silverlight 2 without magic. There will be no proxies, no generated code, no 3rd party utilities, and no disgusting “Add Service Reference” usage. Just raw WCF. This document will cover WCF connectivity in quite some depth. We will talk about service setup, various WCF, SOA, and Silverlight paradigms, client setup, some security issues, and a few supplemental features and techniques to help you aide and optimize service access. You will learn about various WCF attributes, some interfaces, and a bunch of internals. Though this document will be in depth, nothing will ever surpass the depth of MSDN. So, for a more full discussion on any topic, see the WCF documentation on MSDN.

Even though we’re focusing on Silverlight, most of what will be explained will be discussed in a .NET context and then applied to Silverlight 2. That is, instead of learning .NET WCF and Silverlight WCF, you will .NET WCF and how to vary this for Silverlight. This comparative learning method should help you both remember and understand the concepts better.

Read the full document here.

These principles include maintaining separation of concerns, using abstraction to implement loose coupling between layers and components, implementing service location capabilities, and managing crosscutting concerns such as logging and security. While these may seem to be desirable but unrelated aims, one technique can help you to apply several design principles easily. The Dependency Inversion principle implies separation of concerns through abstractions rather than concrete implementations. In terms of design patterns, you can achieve this by applying the Inversion of Control (IoC) pattern and its related pattern, Dependency Injection (DI).

The theory is simple enough. Instead of specifying at design time the actual concrete type that each class or component will use to perform some activity or process, you arrange for these classes or components to retrieve the appropriate object from a container that you previously configured with type maps and registered types.

Dependency Injection is great for achieving loose coupling of components. There are a lot of tools available that can be used for injecting dependencies. A list of such tools can be found on the Wikipedia page as well as on the Clean Code Developer Tools page.