Simon is a hands-on software architect and has a BSc (Hons) in Computer Science from the University of Reading. Over the past 12 years, he’s been involved in projects ranging from rich desktop clients and web applications through to highly scalable distributed systems and service-oriented architectures; predominantly within the finance industry. He's also undertaken consulting and training roles with a broader focus on people, process and technology.
The Pragmatic Java Architect sessions in London
Do you need a Java architect?
Myself and the other contributors to The Pragmatic Architect are running a couple of unconference style sessions in London over the next few weeks. The first is at the London JSIG (5th April, 12-2pm) and the second is at Skills Matter (19th April, 6:30-8:30pm). The basic idea of the sessions is to share our own experiences of what it means to be an architect on a Java project. Of course, we don't claim to know everything, so we're really interested in hearing about other people's experiences too, which is why these sessions are discussion rather than presentation based. Here's a summary of the session.
The role of a technical architect requires a balance of deep technical and non-technical skills, combined with a broad knowledge of the software development process. It can be a tough role and something that you can't just step into overnight. Couple this with the huge number of options available for building Java SE and EE systems and it's easy to become overwhelmed.
This is a roundtable session where members of thepragmaticarchitect.com share their experiences of their roles as Java architects on Finance projects in London. Come along to listen to and ask questions about the following sorts of topics:
- Technology selection: Full stack Java EE or lightweight Spring? Commercial or open source?
- Architecture selection: How do you decide upon an architecture given the vast choice of Java APIs and libraries? How do you prove the chosen architecture meets your non-functional requirements?
- Service Oriented Architecture (SOA): How do you build an SOA with Java EE?
- Deployment choices: How do you decide which platform and topology is right for you?
- Quality assurance: How good is "good enough" and which tools really do add value during development? Eclipse, IDEA, Netbeans or something else?
- Automated testing with JUnit: How combining full stack system tests with traditional unit tests really make a difference.
- Development process: Why understanding your options is important and how to introduce iterative/agile working practices into a "traditional" team.
- Balance: What do you do when you get caught up in the day to day development and forget about your architecture responsibilities?
- Pragmatism: How do you ensure that your project is done right while still meeting your deadlines?
- Do you really need a Java architect?
Architects and aspiring architects should find this session interesting so we hope to see you there.
Re: The Pragmatic Java Architect sessions in London
1. Why would someone choose to be an architect rather than a coder? My intuition would be that they want to have control over the code, rather than be in the position of being told what to do in code. The cynical part of me suggests that some people choose to be an architect because they find coding difficult, or don't understand enough of it. I know one architect, and he's in that category. Sorry, Matt, if you're reading this.
2. I noticed the word 'topology'. Is it always appropriate to architect top-down? Bottomology sounds a bit lewd, but I'm quite convinced that really good coding is done both top-down and bottom-up. A top-down architect might not realise that 3 of the systems he's asked to be implemented are actually identical, just with different terms. The implementor will (hopefully) realise that, and get rid of the duplication. Maybe it would be more useful if the architect was the implementor, or part of the implementing team. That way the architect can learn, directly, about the difficulties or inefficiencies that he's embedded in the architecture.
3. Is the role of an architect mainly needed because, traditionally, developers are awful at communicating with customers? I used to work for a company who, when the going was tough, would sack developers (no, I wasn't sacked!), then hire salespeople. When the going was good, they'd sack salespeople and hire more developers. I always thought this was wasteful; a lot of developers would make good salespeople, given a chance. Personally I thought any developers without a project should be put on sales. Perhaps my faith in people's flexibility is misled; what's your view?
Re: The Pragmatic Java Architect sessions in London
It's interesting that you refer to needing "the role of an architect". I would say that you'll always have architecture. What's important is whether it's the right architecture; that suggests the role of an architect. There is no implication that this need be an individual, a former team lead or outside the team - that is often imposed by corporate structure.
There are efficiencies with having the architect as the implementor but you also run the risk of the architecture becoming "inbred" and unimaginative. You continue to play to your strengths, or worse, your mistakes that noone picked up on. Your example of the implementor picking up on duplication seems unlikely - I can see this sort of situation having been farmed out to three separate development teams. Only someone outside the development teams would have picked it up! If you've got a bad architect then of course this might happen - but you might just as easily have a bad developer! In any case, I would advise against unilateral action by removing duplication without consultation - it might be in there for good reason.
Developers involved in sales? Sure - the sales effort often requires proof of concept and prototype work to be undertaken. Developers as salespeople? Not so sure - it's a different skillset altogether. That doesn't mean that there aren't developers with those skills but I notice you didn't suggest that salespeople become developers during the good times - is the relationship between their skills really asymmetrical? ;)
Finally, do people choose to become architects because they can't (or don't want to) code? In truth, I suspect some do. Beware the "Architects Don't Code" anti-pattern! I can't imagine how an architect will produce (or review) a production-quality spike architecture if they don't code well!
Re: The Pragmatic Java Architect sessions in London
I think you absolutely do need someone/some team/some organisation playing the role of architect on a system. I've blogged my thoughts on this here:
As to why do people become architects - I'm guessing there are a number of less cynical reasons - perhaps for the challenge, perhaps simply because a position becomes available. For me it was the frustration of working on systems which had a feeling of being a mixed bag of different ideas and techniques to solve the same problem.
I haven't come across any architects that don't code - I certainly would expect architects to still be involved to some degree in coding whether it's simply prototyping or working on core parts of the system which utilise new technologies/apis and need to be integrated/tested to mitigate any risks.
Re: The Pragmatic Java Architect sessions in London
I started writing a comment and it turned into an essay, so I blogged it here
I started off just summarising the main points that I felt came out of the sessions themselves, which I think boil down to:
- Having somebody who plays the role of the architect is important to successful project delivery
- A good architect is usually someone who has already been a relatively senior developer.
- An architect should still get time to do development.
- Successful implementation of an architecture can depend on whether or not the architect is part of the team on an ongoing basis.
There are of course many reasons for and results of these, which is what caused me to expand them so much.
Does anyone who was at one or more of the sessions agree / disagree with these? It might just have been my group that thought these and the other group thought something else.
As I said in my blog entry, I have in retrospect found it quite interesting that most of the discussion was about points such as those rather than specifically about Java architectures.
