Coding the Architecture

Speaking at Software Architect 2009

Mon, 29 Jun 2009 09:25:12 GMT

I'm pleased to announce that I'm presenting a number of sessions at Software Architect 2009, which takes place at the end of September in London. Here are the details of the sessions I'm presenting and we'll try to organise a CTA user group to coincide with the event. Kevin is also presenting, but I'll let him tell you about that. :-)

First of all, following its continued success, we're again running our 1-day software architecture workshop (which forms the basis of our longer training course). This is a pre-conference workshop and a great way to start the conference for anybody new or unfamiliar with software architecture and the role it has in building better software.

From Developer to Architect

This session 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. You will gain:

An understanding of what it means to be a software architect, and the role's responsibilities.

An understanding of the trade-offs connected with architectural decisions.

Some experience of what it feels like to be an architect, 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.

Combining presentation, group discussion and group working, throughout the day you'll be solidifying everything you learn by defining the architecture for a small software system. The overall goal is that you can take the experience gained here and apply it to your own projects. No architecture experience required, but software development experience is assumed.

Next up is a session that will look at some of the real-world skills that are needed by software architects today. This takes our view of the role of a software architect and fleshes out the technology aspects of it.

Broadening the T

A breadth of experience is key for successful software architects, but how do you get this and what should you know? In this technical session we'll look at the things every software architect should know, drilling down into the following topics:

Architecture and design patterns

Technologies, frameworks and tools

Designing for and testing non-functional requirements

All of this will done in the context of the Microsoft .NET and Java technology stacks, so you'll get some concrete guidance on what knowledge will help you in your role as a successful software architect.

Finally is a session that expands on Kevin's Sharing Architectures presentation to look at what should be included in an architecture definition. Real-world examples will be presented here to provide some concrete examples.

Documenting your software architecture - why and how?

A description of your software architecture is essential for any project of any size, explaining the rationale behind the design decisions and how the software will work in the real world. Such descriptions should include an explanation of the software structure, the architectural principles adopted, the constraints in force, the platforms on which the system is deployed and an explicit justification of how the architecture satisfies the requirements. A good software architecture document should describe what the code itself doesn't. This session will tell you how to do this.

Stating the obvious

Tue, 16 Jun 2009 14:08:33 GMT

If you've watched A developer's guide to load testing, you will have seen the graph below already. It shows the results from load testing a website written in .NET with the Apache JMeter load testing tool. Along the bottom of the graph are the actions that make up the load test script, while the vertical axis is the response time in seconds. Each line represents the results from a different test run with a different number of concurrent users.

The interesting thing about this graph is that the average response time for any page request is just a few seconds, with the exception of the spike around a third of the way in. This spike is caused by the .NET web tier having to aggregate information from several calls to a backend system, where some resource locking bottlenecks the incoming requests. From analysing the load testing environment during the test run, we were able to ascertain where the hotspot was because (a) the CPU load for the web-tier dropped off when this call was taking place and (b) we could see the requests being queued up on the backend system. From a technical perspective then, load testing is a fantastic way to find and highlight bottlenecks in the overall architecture, providing an opportunity to present some real evidence about the performance degradation and where the hotspots are.

Furthermore, in this example there was a general feeling that this particular action was slow, but the evidence was only empirical. People had experienced this slowness but had never actually measured it before. Kevin made a comment during the last user group where he mentioned that the architect sits between the technical and business spaces, spanning the two and bringing them together. Raw results from a load test are one thing, but presenting the data in a way that makes sense to non-technical people can tell a completely different story. Sometimes your load testing results state the obvious, but sometimes they don't.

A developer's guide to load testing - video

Mon, 15 Jun 2009 22:27:51 GMT

Just a quickie ... the video from A developer's guide to load testing at Skills Matter last week is now available to view online. The microphone picked up the questions and comments quite well, which is excellent. Enjoy, and feel free to use the Google Group to continue the discussion.

Thanks again to Skills Matter.

June 2009 training course

Fri, 12 Jun 2009 22:06:00 GMT

I ran our From Developer to Architect training course (Coding the Architecture Workshop) earlier this week at Skills Matter in London. 8 people came along, all with slightly different levels of software development/architecture experience and technology background. Historically this course has predominantly attracted people with a Java background, although this is starting to change with more people having experience of the .NET framework. As Antonio Goncalves mentions in his blog entry about the course:

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.

If you've been along to one of the Coding the Architecture user groups then you'll know what to expect from this course. There's an element of presentation to set a baseline level of knowledge, but most of the course is very interactive and collaborative, with a focus on nurturing discussion rather than just being a 2-day question and answer session. From my perspective, it's a fantastic course to run because even *I* leave the workshop with my head full of ideas! There's some interesting discussion on TWiT 197 on how education should be less about learning how to pass exams and more about creativity/thinking for yourself. This is exactly the rationale behind our course too.

You can find more information about what the course covers on our training page, but I wanted to share some insight into the case study exercise. It's a collaborative exercise where groups are asked to define an architecture from a small set of functional and non-functional requirements. Given that everybody has different backgrounds and experiences, there's no right answer and the range of technical solutions can often be quite vast. What's important about the case study is looking at how to approach the architecture definition exercise ... which inputs to consider, where to start, how to convey the architecture, what level of detail to go to and, of course, which technologies to choose. The file linked below includes some of the diagrams produced as part of the case study; highlighting the different views, level of detail and notation used to convey solutions.

Diagrams from our "From Developer to Architect" training course (ZIP, 2.7MB)

Even without knowledge of the case study, the diagrams illustrate the variation in how architecture can be conveyed. Expect some essays about this and our overall approach to software architecture in the future; and feel free to get in touch if you have any questions about the course or how we can help you with your own software architectures. Oh, and thanks once again to everybody that came along and made it such an enjoyable couple of days. :-)

A developer's guide to load testing - slides

Thu, 11 Jun 2009 18:40:49 GMT

Thanks to everybody that came along to the CTA user group earlier in the week. The tube strike may had reduced the numbers but we still had some great discussion about load testing. My slides are available to download (~4MB) and if anybody wants to continue the discussion, please feel free to use the Google Group.

A developer's guide to load testing (PDF, ~4MB)

I'll post an update when the Skills Matter podcast/video is available to view online.