In addition to the new content, 2009 saw us present at a number of conferences and events over the year, with all of the slides being able to download and view online. Here are some highlights.

• Documenting your software architecture - why and how?: This presentation was about why you should document your software architecture and how to do it. It complements our software architecture document guidelines.
• Broadening the T: This presentation covered the skills needed by hands-on software architects; including seeing the big picture, dealing with non-functional requirements, using patterns at the architecture level, testing architectures, monitoring and diagnosing performance problems.
• Pitfalls for new software architects: As it says on the tin ... what should you watch out for as a software architect?
• From developer to architect: This is our one-day tutorial session that provides a whistle-stop tour of software architecture. It's basically a stripped down and older version of our recently enhanced two-day training course.

Stay tuned for details of our 2010 presentation schedule.

Add a comment

Posted by Simon Brown on 06 January 2010 08:18:00 GMT #

Happy new year all! Despite the financial climate, 2009 turned out to be a fairly busy year. The rationale behind Coding the Architecture is to be a useful resource for hands-on, pragmatic software architects written by people with the same background. For this reason I'm delighted to report that most of my working time in 2009 was spent in front of Visual Studio writing C# code! There was, of course, a balance of the software architecture tasks, but the majority of my time *was* spent writing code. I've always believed that good software architects should remain hands-on to some degree and I still believe that today. Software architecture is about understanding how to design software from the big picture perspective while understanding the technology that you're going to use to ultimately build the software. Having both the big picture and the detail in mind puts you in an excellent position to deliver successful working software. And that's really what the software industry is about.

In the past I've tended to focus on writing about the role of the software architect and 2009 saw a broadening out to cover other aspects of software architecture such as how you start actually "doing" software architecture. There were a number of blog entries and essays written during 2009 - here are some of the highlights.

• Strategy rather than code: What *is* enterprise architecture and is it the next step for your software career?
• You don't need a UML tool: A short essay about why you don't need a UML tool to do software architecture.
• Start with the big picture: This essay talks about the levels of detail you might go into when you're defining a software system.
• The code doesn't tell the whole story: The code might be the ultimate deliverable, but it isn't everything.
• Software architecture is a platform for conversation: An essay that explains why you should talk to people during the software architecture definition process.
• The Other Interface: Why you shouldn't ignore logging in your software.
• Software architecture document guidelines: Software documentation should be complementary to the code and describe what the code itself doesn't. This essay provides some guidelines as to what you might want to include.

If you're new to the site, have a look around because there's some excellent content that's easier to find now that we've reorganised the site into the what, role, define, share and deliver categories. Expect more to be added in the coming weeks and look out for part 2 where I'll run through some of our other highlights from 2009.

Add a comment

Posted by Simon Brown on 05 January 2010 20:15:46 GMT #

I've had a few people ask me for a write-up of the recent training course, so I thought I'd put something together. This was the first time I've run the course with the new content and structure in place and the feedback was excellent. In the past, I think I'd always assumed that people had their own way of designing software so we never explicitly covered this in any detail other than offering guidance during the main case study exercise. The course now includes much more content and guidelines for designing software although it doesn't go so far as to define a complete end-to-end process. Jason Gorman has a good blog entry called Value Is Not The Opposite Of Waste: Why I Don't Buy Into Process Improvement that talks about how simply putting a process in place doesn't necessarily make things better. And I agree. I don't particularly want to preach a "software architecture process", but I do want to highlight the principles of good software design and how to successfully come up with a software architecture. I'd rather ensure people have the correct knowledge and understanding that can then be used and adapted to fit in with *their* way of working. Having said that, I still think that I'd like to put slightly more guidance around some techniques that can be used to get to the big picture and beyond. I have some ideas on this and will write them up after the Christmas break.

The reorganisation of the course content into the same five areas as the website has also worked really well and makes for a much more logical flow from introducing architecture and the software architecture role through to defining, sharing (e.g. documenting) and delivering/evaluating software architecture. I had a really great time in London running the course at the new Skills Matter offices. For those of you already booked on the March 2010 course in London, I look forward to seeing you there.

Add a comment

Posted by Simon Brown on 18 December 2009 13:28:54 GMT #

When tasked with the job of coming up with an architecture and design for a new software system, one of the first questions people ask is about which tool they should use. Such discussions usually focus around the Unified Modeling Language (UML) and whether their organisation has any licenses for some of the more well-known UML tools.

Read the full essay...

Add a comment

Posted by Simon Brown on 04 December 2009 19:27:06 GMT #

If you're writing software as a part of your day-to-day job, then it's likely that your software isn't going to live in isolation. We tend to feel safe in our little project teams, particularly when everybody knows each other and team spirits are high. We've even built up development processes around helping us communicate better, prioritise better and ultimately deliver better software. However, most software projects are still developed in isolation by teams that are locked away from their users and their operational environments.

Read the full essay...

Add a comment

Posted by Simon Brown on 01 December 2009 22:03:13 GMT #

One of the hardest things about the software architecture role is being asked to come up with a software architecture when all you're given is a set of requirements and a blank piece of paper. It's certainly one of the most fun parts of the role, but it can be a daunting prospect trying to figure out where to start and what to do. Many software teams dive straight into the code and this can initially be very productive but many teams soon start to venture down the slippery slope of constant refactoring while they try to find a design that works. Often, a little forethought is all that's needed to get the architecture definition process heading in the right direction. So where do you start?

Read the full essay...

Add a comment

Posted by Simon Brown on 18 November 2009 08:05:57 GMT #

A quick note to say that I'll be presenting two talks at DevWeek 2010, which is taking place at the Barbican in London next year. Both talks have an underlying theme of improving software quality...

1. Improving quality with an automated build process

This session will look at the development processes in use for an ASP.NET application where quality and consistency have a direct effect on the reputation of the organisation. We'll look at: Subversion and our use of code branches to manage release complexity; Visual Studio and the add-ins we use on a daily basis; NUnit and our strategies for achieving over 90% code coverage through a combination of automated unit, integration and load testing; NAnt and how it allows us to build, test and release code from any of our development branches in an automated and repeatable way; CruiseControl.NET and how it performs continuous integration and testing on all of our development branches.

2. A developer's guide to load testing

Load testing is an often forgotten and seemingly difficult task that many people shy away from doing. It doesn't have to be this way though, with a basic level of load testing often enough to give you confidence that you've satisfied your performance and scalability requirements. This session will look at load testing a website from a developer's perspective. We'll look at the difference between load testing, stress testing and soak testing along with a hands-on demonstration of an open source load testing tool that you can use to get started. If you're building websites in Java, .NET, PHP or indeed any other programming language, this session will show you how easy it is to load test your website.

The latter is a much extended version of the load testing session I presented at Skills Matter earlier this year, where we'll actually go through creating a full load test script with Apache JMeter as well as looking at some of the problems associated with measuring latency when load testing. As always, DevWeek looks to be an excellent conference.

Add a comment

Posted by Simon Brown on 09 November 2009 22:09:54 GMT #

I had an interesting discussion today about the differences between writing a Windows service in .NET and an ASP.NET web application. Somebody made a comment that Windows services were harder to write because you need to make sure you deal with memory properly in order to avoid memory leaks, whereas you didn't need to do this with an ASP.NET web application. In short, the perception was that Windows services are long running processes and that ASP.NET applications running under IIS aren't. There are several things to pick up on here.

First of all, .NET (like Java) is a managed platform that does its own garbage collection so you don't need to worry about explicitly allocating and disposing memory. Unless you're integrating with unmanaged code (e.g. older DLLs, COM objects, other native code, etc) you don't generally need to worry about low-level memory allocation.

Memory leaks *are* something that you need to worry about though and they're really easy to cause in .NET or Java applications. All you need to do is cache lots of data in static references, not dispose of resources you are using, etc. You're not really "leaking" memory, you're just storing it away somewhere and never reusing it again. If you're interested in this topic, InfoQ published a good article today called Dealing with Memory Leaks in .NET that digs into this some more.

The thing that I found the most surprising is the difference in how Windows services and ASP.NET applications are often viewed. A Windows service is clearly a long running process because once it's up and running, that's it until it gets restarted manually or from a system reboot. With a Windows service, any memory leak will start to become very obvious as the system slowly grinds to a halt and it's this that caused the comment about Windows services being harder to write. For some reason, ASP.NET applications aren't necessarily perceived as long running processes. With my Java background, I find this odd and several times people have mentioned that they rely on AppDomain recycling in IIS to prevent their applications from consuming too much memory. AppDomain recycling is essentially the same as what happens when you hot-deploy a web application on a Java EE server - drop the classloader and plug-in a new one to reload everything from a fresh state. For a moment then, let's think about what happens when an AppDomain behind an ASP.NET application is recycled in IIS (there's a much more detailed explanation here).

• Any shared state in your application (e.g. stored by static variables) disappears. If you're caching frequently used data or data that takes a long time to calculate, then this will all vanish.
• Any sessions backed by the in-process session store (i.e. in the AppDomain) get blasted.
• You'll normally see a performance hit the next you hit the site as pages are reloaded and recompiled, connections are re-established, etc.

AppDomain recycling can have a fairly large overhead then, which brings me nicely onto the point of this. You're likely to have fewer issues in the future if you design every piece of software as a long running process. It doesn't matter whether you're building a Windows service, an ASP.NET web application or even a desktop application; you should always write code to avoid memory leaks rather than ignoring them. Relying on restarts or AppDomain recycling as a workaround for sloppy coding and memory leaks is not my idea of software craftsmanship.

Responses[5]

Posted by Simon Brown on 05 November 2009 20:42:51 GMT #

Taking some inspiration from the recently published SOA and FAIL manifestos, I thought I'd have a go at writing my own for software architecture.

1. Some up-front architecture over doing the whole lot or none at all
2. Designing for non-functional requirements over trying to tack them on at the end of the project
3. Evaluating technology over just choosing it because it looks good on your CV/resume
4. Experimentation over hoping your design will work
5. Code over endless discussions, meetings and diagrams
6. Collaboration over ivory tower dictation
7. Involvement over running away and letting the team deal with the "implementation" problems
8. Coaching team members over stroking your own ego
9. Pragmatism over perfection
10. Real problems over intellectual (self) stimulation
11. Simplicity and common sense over complex and convoluted ideas
12. Short and useful architecture documentation that reflects reality over encyclopaedias that nobody reads, understands or cares about

Humour aside, this does reflect my view of the role of a software architect. What else would you include?

Responses[4]

Posted by Simon Brown on 02 November 2009 08:43:36 GMT #

We've been running our software architecture course for a couple of years now and although we've consistently received very positive feedback, we're always looking for ways to improve it. And that's exactly what we've done over the past few weeks.

First of all, the name of the course has been changed to "Software architecture for developers" as it better reflects the intent of the course, which is about broadening people's software development skills and making them more architecturally aware. We want people to better understand how to make design decisions on software projects and be more confident that their choices will work.

The other major change to the course is that the structure now reflects the new organisation of the website, where content is broken down into the following categories:

1. What is software architecture?: This category covers all of the basics such as what software architecture is all about and why it's important.
2. What is the role of a software architect?: This is probably the largest category on the site where you'll find lots of discussion about what software architects (should, in our opinion) do.
3. How do you define software architecture?: This category is about putting software architecture into practice, where you'll find articles about what drives architecture, technology selection, dealing with non-functional requirements and so on.
4. How do you share software architecture?: Having a software architecture is only part of the puzzle and this category is all about collaborating, documenting and sharing it.
5. How do you deliver software architecture?: The final category is about delivering the architecture; covering aspects such as process, methodology, evaluating and testing architectures.

In addition, more exercises have been introduced and we now have more dedicated content to delve into things like creating software architecture documentation and evaluating software architectures. This content *was* included before through a number of supplementary presentations, but the new structure gives these topics their own focus. You can take a (thumbnail sized) peek at the slides and you can find more detailed information about the course at http://www.softwarearchitecturefordevelopers.com. The next public runs of the course this year are the 8th of December (London) and 14th of December (Paris), but you can see the Skills Matter website for other dates.

Feel free to get in touch (e-mail or Twitter) if you have any questions or would like talk about a private/internal run of the course for your team.

Add a comment

Posted by Simon Brown on 29 October 2009 16:46:15 GMT #