How to Break Down Architecture

Software architecture – at what point does the documentation start? Where does it end? What processes should be followed to see architecture through from its inception where requirements are still vague through to the finishings of a crystallised notion? As with almost all design disciplines a software architect starts with the big picture. Once the requirements have been very loosely defined it is possible to produce some marchitecture. Marchitecture is very informal (a cross between marketing and architecture) – pretty pictures and colourful blocks. This allows the architect to convey what might be built to customers or management. It gives a very high level overview and probably does not represent technically what will really be built at this stage. The marchitecture will later evolve into architecture which gives a true representation of the system as further requirements become apparent.

So why produce marchitecture? Well it allows very early visibility into the project, and can be understood by a large audience. It provokes thought and debate at an early stage, which lead to further ideas and confidence building in the project. The marchitecture can often be used later in marketing and supporting documentation for the product.

The next phases should produce architectural documentation formally represented e.g. in UML. But we should not go diving straight into the fine details as it will be very difficult for anyone to grasp the concepts of the system as a whole. Instead people need to be guided though various levels of abstraction to allow them to build their understanding. A high level of abstraction is often referred to as a low precision view. We also need to cater for different audiences needing to view the architecture only down to a certain level of abstraction.

This all falls very nicely into the development cycle as an architect will naturally go through similar levels of abstraction in his or her mind whilst the system is being fleshed out. So I would recommend documenting architecture on three or four levels of abstraction as you firm up your understanding. This process is known as hierarchical decomposition. A component within the achitecture is only specified once the corresponding sub-system has been firmed up within the previous level of abstraction. Clever numbering of architectural components is often used to specify the level of abstraction they come from. Class objects are only defined at the lowest level of abstraction.

Another huge advantage in using this method is to be able to offer early cost estimates on each component. These costs can then be refined in the next level of abstraction as more detail is known. Failing to produce architecture in this way will result in a giant blobby mess which no one can get a handle on, and the architect will struggle to manage the complexity.

On Split Development Teams and Communication

Managing communication between development teams split either geographically or by time-zone can be challenging. So why bother carving teams up? More importantly, how do you ensure effective communication takes place?

If we are only considering the software development process, ideally development teams would always be collocated. However there are often other factors which cause teams to be split. For example the necessity to provide support across time-zones or regions, or the cost of personnel being less in other locations.

So if you have to split your teams how do you ensure affective communication is taking place without having to write reams of documentation and micromanaging tasks? I believe the key is to keep the communication as dynamic and off-the-cuff as possible. Actively encourage verbal communication e.g. via telephone with concise follow up emails confirming technical details. Carbon copy interested parties, but not the whole world. I also believe web-cams can also be useful to encourage communication, and these can add an interpersonal touch which would otherwise leave remote teams feeling like robots carrying out allocated tasks.

Better still is the use of persistent chat software. You can set up a channel per project, and all historic communication is visible and searchable to everyone. Where there is a time-zone difference it is great to come in the next morning and see what has been going on the night before.

I'm told that Parlano makes a great persistent chat product called MindAlign. However they have recently been bought up by Microsoft who are integrating MindAlign into Windows Communication Server. As soon as MindAlign is available again I will trial it on some projects.

Another option is to use the discussion features within your architecture/modeling software. Enterprise Architect offers this type of functionality (which I'm currently trialing), as well as the ability to drag UML objects onto the discussion to offer in-context chat. Another great thing about EA is that the free read-only version still allows people to join in the discussion. EA seriously lacks in a very important area however; real-time alerting does not exist, the only way to know a new message has been posted is to refresh the discussion window.

Enterprise Architect, TFS, and check-in policys

If you have a check in policy setup within Microsoft Team Foundation Server (TFS), Sparx System’s Enterprise Architect will fail to check in work, and it is not possible to override the check in policy either. For example, our TFS check-in policy dictates that the user should always associate a work item with a check-in, but EA does not show the dialog which allows us to do this when checking in. Luckily there is a solution, kindly provided to us by Sparx Systems. I thought this is worth sharing: “

EA's built in support for TFS uses the TFS command line client "tf.exe" to communicate with the server. Unfortunately, when we check-in files using the CLI, it does not open the TFS check-in dialog, so no, we cannot access the work items from EA using this connection. However, you can also connect to TFS using the MS TFS-SCC client, which is also supported by EA. This client does open the "check-in" dialog and therefore does facilitate association of the check-in with a work-item. You can download the TFS 2005 SCC client from here, or the TFS 2008 SCC client from here. Once you have downloaded and installed an SCC client for TFS, you can convert your existing EA VC configurations from command line client to SCC client, by opening EA's Version Control Settings dialog, then selecting the existing configuration in the lower part of the dialog to display the details in the upper part of the dialog. You will notice that the "type" is selected as TFS and the radio button for SCC is also enabled. Select SCC as the type, then click on Save. You should be prompted to select your SCC provider, then if you are not already logged into TFS through Visual Studio, the SCC client will prompt you to log in to TFS. Once you successfully log in, you will remain logged in to TFS, until the TFS session closes.

”

Management Growing Pains

As team sizes grow a hands-on manager will struggle to keep on top of their own work load, often causing bottle necks within software projects. This has certainly been my personal experience. The "roll your sleeves back, get stuck in" style of management can no longer be applied universally to tasks because there are too many tasks. Managers will often be uncomfortable in letting other team members carry out important jobs, yet they now struggle to find time to do it to quality themselves. The key to solving the problem is to recognise and accept that the larger the team the more inefficient it becomes. Often in software development teams doubling output requires exponential team growth. Let other team members initially take longer than you would to perform a task and then make time to review the task they have carried out. If you are not happy with the results, explain to them why and ensure they understand. That way quality can only improve. Do's and Don'ts:

• Don't personally produce direct project deliverables; instead enable the team to produce these by way of facilitating.
• Don't say "leave it with me" or similar responses to questions which cause you to accept work; instead say "ask xyz how they..." or "read xyz, that should give you a better insight..." or "I usually do it like this...".
• Don't feel guilty for giving team members more responsibility which was previously beyond the scope of their job. But do accept accountability for their work.
• Do schedule regular task review sessions and offer coaching and advice.
• Do allow team members to make their own mistakes, but create a sandbox for this to happen in.
• Do repeatedly encourage communication.

If you feel that the team has become too inefficient due to size, consider logically splitting the team with each part concentrating on a different area of concern. This attempts to minimise the "there is only so many surgeons you can get round a body" scenario. There are of course several downsides to doing this. I would generally recommend development teams being no larger than 8-10 people.