Coding the Architecture - experiences tag

London User Group - December 2007

Tue, 11 Dec 2007 17:12:33 GMT

Thanks very much to everybody that came along to the London User Group last Thursday night - it was our largest turnout yet at just under 40 people. Also, congratulations to the winners of the QCon London 2008 pass and the books. We look forward to receiving your book reviews next year. ;-)

The topic for the evening was "From Developer to Architect" and I thought it was really interesting that we all presented a different view of our transition into an architect role, yet there were some common themes that kept cropping up. Probably the best example is that architects need to take a "macro view" of the system. There were also some interesting things said during the discussion part of the session that I thought were worth sharing :

The difference between developers and architects is "the weight of their mistakes".
The architect has "the vision of the system".
Architects are a "salesman for their ideas" and "they need to bring people with them along the way".

Also, there were some good questions that sparked discussion.

Can you be an architect on a team of one?
Can the architect role be distributed amongst the team?

It was a very good night and the discussion continued over a few drinks in "The Crown". As always, the slides are available to download and, for those of you that want to continue the discussion, please feel free to use the Google Group. The user group will be taking a break in January, so we'll see you in February.

London User Group - December 2007

Tue, 20 Nov 2007 17:02:29 GMT

Here are the details of the December Coding the Architecture London User Group.

Title : From Developer to Architect
Summary : The transition from software developer to software architect is often shrouded in mystique and few people talk about it. But what does it really mean to be an architect and how does it differ from being a developer? Join us for this session where a number of hands-on software architects share their experiences of when they took on their first architecture role. This is your opportunity to find out exactly what "being an architect" is all about.
Date : Thursday, 6th December 2007
Time : 18:30-20:00
Location : Skills Matter, 1 Sekforde Street
Format : Presentation followed by a breakout for discussion, with further discussion in a local pub (The Crown).

As a little early Christmas present, we'll be giving away a few books, courtesy of O'Reilly and Pearson Education. Come along for a chance to win one of them.

Update (30th November) : We also have a free 3 day conference pass to QCon London 2008 to give away.

Please sign-up on the Skills Matter website.

Where's the coffee machine?

Fri, 16 Nov 2007 08:36:00 GMT

I have recently moved into a technical architect role at a new client. Over the last month or so, I have asked lots of questions. Here are some that I found particularly useful...

Who is that? - I always ask for a new client's organisation chart, or better still, find someone to take me through the hierarchy on a white board. As an architect, your sphere of influence is much greater and you are expected to interact with many more stakeholders - multiple project managers, infrastructure / networking techies, IT directors, people from all corners of "the business", testers, suppliers / prospective vendors, your client's clients, etc. Knowing all their roles and places in the organisation is key to understanding their motivation.
How urgent is that really? - Work comes at me from all directions with little warning. People want some of my time to review a design, troubleshoot a potential prod issue, dissect some smelly code, run a perf test, optimise an ailing query, and so on. I am essentially a single processor unit, so managing the constant context switching has been one of the hardest skills to pick up. As always, prioritising the tasks is critical. In my experience, it is only the person at the top of the org chart (CTO or IT Director) who has enough of a neutral overview to do this properly.
Are you hungry? - Go out for lunch. Often. People are more inclined to accept a lunch or coffee invite from the new guy, and I've found that this is a very useful information gathering tactic. Once out of the office, conversation is generally more candid, and discussions won't get interrupted by IM, email, badgering colleagues and ringing phones.
OMG, how long is that method? - OK, so a bit of a contrived question, but worth emphasising. I've gained the most insight into my client's business, their challenges and the development team's strengths by pulling apart the codebase. I have had to dial down my natual pedantry level and learn to concentrate on the big ticket non functional requirements such as security and performance, whilst not worrying about the odd unused import.

I'd be interested to see what questions others ask when they start on a new project / client...

First experiences

Thu, 23 Mar 2006 15:07:41 GMT

As I said yesterday, we're going to publish first experiences of being in an architect role and, without further ado, I'd like to present Richard Holdsworth's first experiences. Richard is a recently appointed technical architect with a major international travel company, where he's involved in the architecture of a new system built around a service oriented architecture.

At the time of being asked to perform the role of Architect I felt that I was perhaps at least a year or two from being "technically qualified" to consider myself as such. However, it seemed too good an opportunity to miss so I braced myself for an intense number of months in which I would be branded a fraud.

However, no sooner did my mentor arrive that I began to understand the wider aspect and responsibilities of the role and how it is not an elevation of status above a senior developer but merely a side step from the development team to enable us the ability to view, and be involved with, the whole development process.

As the role is new to my company there were a few misunderstandings early on regarding the job specification and boundaries such as:

How much time we should spend with the business?

Should we be responsible for chasing development progress?

How much code, if any, we should contribute?

I am happy to say that now I enjoy talking to business as much as possible to drive out the design, I'm not expected to provide progress reports, except on my own work, and I contribute as and when necessary to the development effort.

Unfortunately, partly due to my own misunderstanding of the role, I believe I spent too much time in the early part of the project concerned with the documentation that I was expected to produce to senior management when I feel I should have been getting my hands dirty with the actual technology and producing a prototype which would have improved my ability to mentor and not to mention early testing.

As for the other aspects of my job such as code reviews, best practice and other methods to ensure the quality of software development I find it hard to imagine how any IT project can function without an Architect these days.

I like the expression about the architect role being a "side step from the development team". I'd not really thought about it like this before but it makes a lot of sense. Rather than an architect stepping down to do some development, they're stepping back into the development team. An interesting perspective and I can definitely relate to the questions around the boundaries of the role because I had similar questions when I was new to the role myself. Many thanks to Rick for sharing your experiences.

First experiences

Wed, 22 Mar 2006 20:03:00 GMT

Part of my role includes mentoring, and that includes working with people who are experienced architects, people who are new to the role and people that are aspiring architects. For me, it's a very valuable part of my role because not only do I get to help others, it also helps me better understand my own role as an architect. I know that may sound a little strange, but I'm a firm believer that explanation leads to clarification, in everybody's mind.

Something that I thought would be useful to readers of The Pragmatic Architect (which I know includes experienced and aspiring architects) is to ask people that are new to the role to share their first experiences. We've all been there and I think that reading about other peoples experiences is a great way to gain more insight about what it means to be an architect. Also, it provides a way to highlight some of the common issues/misunderstandings/questions about the role, reassuring others that they are not alone on their journey to becoming a technical architect.

A few people have already been kind enough to share their own first experiences and they genuinely do provide some fascinating insight. In fact, some of them even made me step back and think about the role of an architect and how it's defined, which I admit I wasn't really expecting to happen. I'll publish the first of these over the next couple of days. If you would like to share your own experiences and have them published on the site, I'd really like you to get in touch.