社区：
51CTO: A short question on your session this morning. so what I interpret is that teams should not go agile blindly when you don't have enough good people in the team. Do you always see this situation?
Simon: Yes, all the time, unfortunately. The Agile Manifesto was celebrating their 10th anniversary last year, so you know agile was established for a long time. Big companies want to adopt agile, because its transparency, deliverables, budget, moving fast, and getting feedbacks. And all that sounds pretty. People are struggling with the guidance when going agile, so one of the questions I had quite often is that, ok we are adopting agile, but we are struggling with project management and document assessment. And if you look at frameworks such as scrum, they give you profiles and lots of things, but less practices on how to run projects. There are other aspects of agile processes, people don't quite understand what they engage on, they put all the focus on the techniques, but they forget about the basics: they forget about security, scalability, they stop making decisions...they just rush into things. I ran into these teams recently, so one of the teams come and say, we adopted agile 4 months ago, we kept doing sprints, but now we have so many technical debt, and we need to re-architect everything. If they've come thinking up front, maybe they won't end up in that situation in the first place. It's very very common.
51CTO: So how can you make sure that when some one who can see from top to bottoms comes in, these things won't happen?
Simon: Imagine you have a team of 6. If we've got security requirements, performance requirements, scalability, or any other complex functional requirements, sometimes we all forget about them. There needs to be a role to make sure people follow these requirements. It's a single point of tech leadership. Of course you can share that role, but most teams don't work like that. So it's about having someone in the team to step back a bit to make sure things move under the requirements.
51CTO: Just a short question, do most teams in the UK have this chaotic behaviour?
Simon: Yes, most teams. It's the same worldwide, to be honest.
51CTO: You have mentioned in your many posts, that different teams and engineers have different definitions to the term "architect". But still, under any kind of classification, any defined "architect" should have something common, either their responsibilities, or their abilities. Can you briefly describe some generalized architects, in terms of what they need to know and what they need to do?
Simon: That's an interesting question. Just the word architect means different things to different people. In fact, if you go and look after what architect means, again there are so many definitions. There is a body called the IASA, which is the International Association of IT Architecture. They used to be called the International Association of Software Architecture, but they changed that, because they want to come up with a definition for all IT Architecture. It is sort of controversal to try to come up with a definition, but my view is that people don't need to bother with the buzz words. The IASA guys, they used to have a Business Tech Strategist term, which doesn't really make sense. I'm definitely willing to create some well known definition, but I think more importantly, and in agile teams, the definition of the organization comes in first. We have to define the role, list up responsibilities, and make sure at least one person is doing it. It really should be a team by team kind of role. Each team should have an architect.
51CTO: Do you think that architect working independently like you, and those architects working in a specific product team, are there differences?
Simon: Ok, I'm independent, but I tend to work as a team. The roles are the same, but the priority is slightly different. If you are building things for the customers, the requirements might not change that much. While on the product teams, it's a different role, because you are right on the front line, you are making decisions on how you make things, you have to look into scalability, how things might change along the way.
51CTO: So you started your career in IT since 1996. That has been 16 years. Have you experienced periods when you feel you have a large leap forward?
Simon: I definitely have experienced periods when there is a vast jump backwards. When I first came into the role of an architect, I wasn't sure what I need to do. I was drawing UML diagrams, and I thought, ok, I have jumped from coding to drawing pictures, this isn't right. How these things linked together? I think I was taking a step back, but then I realized you have to step back to see the bigger picture. I was taking different projects throughout the year, so module designs, component designs, service designs and so on. Actually, it's all the tiny things that help you succeed or fail. When you build something and things don't perform well, you need some one with experience to look back at what might happened. It's a lot of backwards and forwards, I'd say it's a revolutionary career. And I'm still learning. How the security mechanisms work, use transactional arc systems, and there are so many technologies up there, clouds, all the web stuff, services...there are so much stuff to learn. It's a tough role in the software trend. Lots to learn. Never stop learning.
51CTO: So do you think things are changing faster in those 2-3 years?
Simon: Definitely fast.
51CTO: As compared to 10 years ago?
Simon: Well, I think it was already moving fast ten years ago. It was the Internet bubbles, that time I was doing Java, all kinds of buzz words came: web, enterprise Java, JavaBeans, servlets, JSPs, application servers, clustering...that was a very fast time in the Java industry. Java slows down now, .NET picked up, and if you look at things like cloud, that has gone rapidly fast as well. Amazon's got elastic clouds, VMware's got Cloud Foundry, platforms are coming up...it's always moving fast.
51CTO: Ok, so you know many things, and you mentioned about the T-shaped architects. Do all developers need to work to that direction?
Simon: Ideally all developers.
51CTO: So those specialists who can only code, is there any room left for them?
Simon: Yes. Although in agile we talk about generalized specialists, in an ideal world, everybody is equal, they make decisions, look after the build environment, and build things together. In the real world, it's hard. It's really hard to find people who are generalized specialists. So in the real world, you will always need those specialists who can only code. It's up to the team and people you've got. If your people just want to code, they don't care about the bigger picture, that's fine. Don't force them to do things they don't want, like making decisions. They'll do a bad job anyway. Just leave them there and use their expertise.
