2009 highlights and plans for 2010 - part 1
Lots of new content about pragmatic software architecture
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.
