Architect Soft Skills: Part III, System Thinking

My previous post on the architect's soft skills discussed leadership. If you have good leadership skills, you can get people to follow you. This increases your responsibility to actually know where to go. Two soft skills that can help you with that are:

• System Thinking, which I address in this post.
• Strategic Thinking, which I'll address on the next part of this series.

Microsoft Encarta defines system as "any collection of component elements that work together to perform a task." (You may want to take a look at some of the characteristics of systems by Donald E. Gray). When we get a problem--that is, a software solution that needs to be built--we tend to think about breaking it down into manageable "parts" (the subsystems/components/services/objects) that makes that solution. This, however is not enough. We also need what is known as "Systems Thinking".

System Thinking originated as a way to think about social systems but has emerged as a way for problem solving problems for systems in other practices. In essence it is about understanding that system parts that work together behave differently then each part alone ("The whole is greater than the sum of its parts"). Which is, by the way, the reason "loose coupling" is such a holy grail--as it helps reduce the parts interdependence and interactions (and thus simplify the system).

One important trait for understanding systems behavior and component interaction is the ability to create abstractions and models; that is, simplifications of the reality which contain enough detail to be useful (Another thing that is needed is the ability to communicate that to the different stakeholders which is another soft skill I'll expand upon). It is important to remember that mental models limit the perspective we have which is why we need to have several models and why it is beneficial to have more than one person working on a problem.

As it happens this is also aligned with my definition of software architecture:

Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attribute requirements. The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size).

This definition gives interactions and the environmental implications on the system as a whole the same weight as designing the parts themselves. if the architect doesn't (or can't) understand the effects of the components playing together the quality attributes (performance, availability etc.) of the system will suffer and the system will not operate as planned.

For an introduction to the subject, I recommend Gerald M. Weinberg's Introduction to General Systems Thinking. It lives up to its name.

Posted by Arnon Rotem-Gal-Oz at 07:49 AM  Permalink