Software Architecture for Developers

What is it?

We have put together a comprehensive two day course that will help jumpstart developers on their way to becoming a software architect. The course is an interactive introduction to software architecture and what it means to be a software architect. It's aimed at software developers who are looking towards their first software architect role, as well as architects that are new to the role. Attendees will gain :

• An understanding of what it means to be a software architect and the responsibilities associated with the role.
• An understanding of the trade-offs that are made when making architectural decisions.
• Some experience of what it feels like to be an architect on a bespoke software development project; including gathering non-functional requirements, determining the drivers for architecture and defining an architecture.
• An understanding that, as a software architect, it's okay to do some coding.

What do we cover?

• What is architecture?
  "Architecture" is a very misunderstood term within the software industry, so we start out by defining what it means to us, talking about how it differs to design and introducing the context for the rest of the course. We cover architecture at different levels; from application architecture through to enterprise architecture.
• The role of an architect
  With a definition of architecture under our belts, we move on to clarify the role of an architect by looking at the roles and responsibilities, which leads us to the conclusion that the architect role is different from that of a lead developer.
• Architecture in the software development lifecycle
  Next we look at the involvement that an architect might have during a typical software development lifecycle, all of which is applicable regardless of whether you're using a traditional, iterative or agile approach.
• What drives the architecture?
  Software architecture doesn't exist in a vacuum, and is driven by the functional requirements, the non-functional requirements, constraints and principles. We take a look at all of them to understand the impact that they have.
• Architecture definition
  We start off by questioning what happens when you don't explicitly define the architecture, then follow on by looking at how you do it through documentation and code. Architecture definition is a large part of the course and we highlight that architecture involves more than a single view of the system, with those views being important to different stakeholders. We take a look at the various views that you might include in a software architecture document and practical exercises allow you to put this knowledge into practice.

How does it work?

The course is interactive; with a combination of presentation, group discussion and group working. Throughout the course you'll be solidifying everything you learn by defining the architecture for a small software system through a series of exercises focused around a case study. The purpose of the case study is two-fold. First of all, it provides an opportunity to think about how to take a high-level system vision through to an architecture definition, and secondly it's an opportunity to undertake that architecture definition.

The first step in the case study is that we provide each group with the high-level vision for a software system. This single sheet summary provides details of the business context along with a bulleted list of the desired functional requirements. From this, we ask each group to identify the non-functional requirements that they expect would need to be specified for this system, along with thoughts on how to test them.

To ensure that everybody is working against a consistent set of requirements, each group is then provided with a sample set of non-functional requirements for the case study and is asked to undertake the architecture definition. This exercise tends to last for about half a day and we ask groups to do the following.

• Come up with the architecture for the case study.
• Decide on the technologies that they are going to use to implement it.
• Draw up the logical view(s) of their architecture, showing the high-level components and their interactions.
• Assess and justify that their architecture will satisfy the functional and non-functional requirements.

At the end of the exercise, we compare what each of the groups has come up with; discussing the choice of technologies, diagram notation and process used to define the architecture. Here are some examples of the diagrams that attendees have drawn on previous courses.

A final note

This workshop is completly different from what you are used to where you are sent by your company to be trained. You don't arrive, sit down, listen and leave the room being an architect. Instead you only go through 50 slides in two days, and spend your time working in small groups and interacting with the others. At the end you leave the workshop with your head full of ideas. [Antonio Goncalves, June 2009]