Software architecture is a platform for conversation
Architectures don't live in isolation
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.
Start with the big picture
Wide angle, telephoto, macro ... every picture should tell a different part of the same story
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?
Speaking at DevWeek 2010
Two talks about improving software
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.
Design software as a long running process
Relying on restarts is bad software craftsmanship
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.
Software architecture manifesto
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.
- Some up-front architecture over doing the whole lot or none at all
- Designing for non-functional requirements over trying to tack them on at the end of the project
- Evaluating technology over just choosing it because it looks good on your CV/resume
- Experimentation over hoping your design will work
- Code over endless discussions, meetings and diagrams
- Collaboration over ivory tower dictation
- Involvement over running away and letting the team deal with the "implementation" problems
- Coaching team members over stroking your own ego
- Pragmatism over perfection
- Real problems over intellectual (self) stimulation
- Simplicity and common sense over complex and convoluted ideas
- 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?
Software architecture for developers
A two day training course to broaden your software development skills
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:
- What is software architecture?: This category covers all of the basics such as what software architecture is all about and why it's important.
- 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.
- 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.
- 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.
- 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.
Software architecture document guidelines
Guidelines for creating your own software architecture documents
Back in March last year we published an initial set of software architecture document guidelines and I thought that it was time for an update. There are no major changes although I've modified some of the section headings so that you can use this as a complementary resource to the slides from my Documenting your software architecture - why and how? presentation. As before, I hope you find these resources useful in creating your own software architecture documentation.
Strategy rather than code
Is enterprise architecture the next step for your software career?
There are many different types of architecture and many names to describe the same thing. This essay summarises application, system and enterprise architecture before looking at whether enterprise architecture is the next logical step for people on the software architecture career path.
The code doesn't tell the whole story
We all know that writing good code is important and refactoring forces us to think about making methods smaller, more reusable and self-documenting. Some people say that comments are bad and that self-commenting code is what we should strive for. And I don't disagree. Everybody *should* strive for good code that's easy to read, understand and maintain. But the code doesn't tell the whole story.
Documenting your software architecture - why and how?
Describe what the code itself doesn't
Another of the sessions that I delivered at the recent Software Architect 2009 conference was entitled "Documenting your software architecture - why and how?" and covered some of the drivers for creating software architecture documentation along with some guidelines on how to do this. As I said in the session, any 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.
As with Broadening the T, I'm going to put one or more essays together that cover the content in more detail. In the meantime, you can view or download the slides.
