Coding the Architecture - sdalton

Question of the week

Fri, 04 Apr 2008 09:39:11 GMT

As mentioned last week, we are going to be sharing questions that we get asked that seem applicable to the CTA audience. Feel free to e-mail us your questions or use the Google Group.

This weeks question is from a new hands-on technical architect.

Let me ask you, what are some good resources for hands-on technical architects?

A very good question, and one with a multitude of answers - we certainly don't have a definitive list of resources, but can certainly tell you some that we find useful.

Web

The Coding the Architecture Website
InfoQ

InfoQ Architecture Community

Technorati

this one

Books

Software Systems Architecture - Working with Stakeholders Using Viewpoints and Perspectives by Nick Rozanski and Eoin Woods

book

here

Beyond Software Architecture

book

Podcasts

The Coding the Architecture Podcast
Software Engineering Radio
The Java Posse

Real Life

Local architecture or technology special interest groups

CTA Usergroup

It is worth remember that to be a sucessful hands-on architect, you also need to keep track of the underlying technologies, not just architecture. Another point to note is that it's not just about having resources specific to architecture but about digesting the resources that you use at the appropriate level.

If you have any more resources that you have found very useful then feel free to leave a comment.

Podcast #2 : QCon revisited

Tue, 25 Mar 2008 10:23:20 GMT

As promised the 2nd CTA podcast is a roundtable discussion between some of the CTA contributors - namely Simon Brown, Sam Dalton and Kevin Seal. In this podcast we discuss some of the themes emerging from the recent QCon conference held in London and our views on those themes.

The podcast can be downloaded here or you can subscribe. Full show notes follow below:

1. Introduction

QCon Conference London detail can be found here.

2. Monitoring and Management (0:27)

Roll your own vs. "off the shelf" monitoring
Asynchronous monitoring
JXInsight
The need for an System Architect and an overall understanding of WHAT to monitor and a holistic view
Including Monitoring NFRs upfront in SAD
Monitoring the monitoring vs. best effort
eBay and 1.5TB of monitoring and logfile information per day

3. Rehashing Refactoring (11:56)

Refactoring now mainstream, now emphasizing at the micro-level
Code-debt - how can you measure it?
Refactoring is not something to be "saved up"
Lots of rearchitecture projects sold as refactoring
Sometimes starting again is a better solution than large scale refactoring
Why do things end up in such a mess so often?
Need to get back to writing code for humans to understand
Worry about emphasis on low-level code optimizations rather than architecture
Is refactoring its own worst enemy being referred to as a separate discipline to regular software development?
We are our own worst enemies - we (especially the architects) need to stand up for the quality of our code - stop allowing ourselves to be convinced to make shortcuts

4. The Return of the Architect? (25:08)

Thinking about performance, monitoring etc upfront
Terracotta, Coherence, Gigaspaces
Kevin's views on Terracotta
How much performance could you squeeze from a system in 2 weeks with code changes alone?
Real-time VMs and performance improvements
The benefits of continuous performance testing
Premature optimization
Understanding a system's deficiencies can be as valuable as fixing them

Has Agile become a dirty word?

Tue, 11 Mar 2008 15:50:10 GMT

A few years ago, Agile was everywhere. There were books galore, articles in the technology press, tracks at conferences etc.

That is not to say that it has gone away, but a few years ago everything was being sold and hyped as being Agile. Things from process to products to services were having the Agile name splashed across them - whether it was a correct use of the term or not.

In some ways this was a good thing for the Agile movement as it got the term out there, and a whole lot of people were exposed to it. Some of the more curious people may even have done a bit of research and truly understood the tenets of Agile as a result. However, I would argue that this has had possibly the biggest detrimental affect on Agile possible.

We are now in a position where we have managers that feel that they were bitten by Agile when in fact what they were bitten by was miss-selling. Consultancies sold Agile and did Cowboy.

This has resulted in an allergy to all things Agile amongst many senior managers and budget holders - to the point where even mentioning the word results in a death stare. This is also resulting in a shift back to the perceived comfort of tightly controlled processes that give the managers and budget holders an illusion of control. They fail to realise that actually what they have is a stifling of productivity and ingenuity, and a company of frustrated people who can see there is another way.

My question to you is simple - have you experienced this and how have you approached it?

The First CTA Podcast

Thu, 06 Mar 2008 12:05:29 GMT

As mentioned at the last user group, the members of the Coding the Architecture website have decided to start producing some podcasts.

This was born out of a request to make the user group sessions available to people that could not attend the actual session. As such the first podcast is a recording of the user group that took place on 4th March in London.

You can download the podcast here, and if you have iTunes you can download the enhanced podcast - including all of the presentation slides - here. You can subscribe to all of our podcasts using this feed, and we will considering adding this to the iTunes Podcast Directory in the future once we have a few episodes recorded.

Look out for more podcasts from us in the very near future. In the meantime please let us know what you think, and if you have any suggestions for future podcasts.

Architecture as a Separate Function

Mon, 03 Mar 2008 15:04:00 GMT

Back in 2006 we wrote about how Architects are Part of the Team and shouldn't sit in ivory towers. This entry addresses some of the problems that arise when this is not the case.

In several organisations that I have been exposed to the architects sit within a completely different organisational area to the development team. Whilst I can appreciate this from a budgetary and reporting perspective (to an extent), it causes a number of very visible problems.