locked
What is the ideal team structure like that when architecting a solution? RRS feed

  • Question

  • I was wondering what people's experience is in terms of the type of team they feel is/was ideal when working as an architect? I'm thinking specifically about the production of the inital architecture here. E.g. I nice mix of developers, testers, customers, business analysts, systems support, etc. Or perhaps that's too much of a committee with too few relevant people and only a select few should be used?
     
    Wednesday, May 14, 2008 9:27 PM

Answers



  • I think that it is good to have a spread of different viewpoints to be able to interview, better than one representative that may have their own itinerary.

    I think I would possibly use the masses to do some brainstorming regarding features and so on, then have a smaller group of people to actually shortlist a sensible feature set.

    I have to admit though, more often than not, you don't really get the choice.  There are usually stakeholders that are naturally going to be involved, even if offer little insight or help, and there will always be those that would be helpful and useful, and don't shout loudly enough.

    I think that it's also important to make sure that when features are being gathered, to ask question about them, directly to engage other viewpoints, to check the assumptions, and that the feature is correct, and not tied to a particular individual.

    It really is a balancing act.  The best bet is also to have a good cross section of people who regularly use and give feedback on the product, so that it is obvious if things are not headed in the right direction.

    I hope this helps,

    Martin Platt.
    Wednesday, May 14, 2008 9:36 PM

All replies



  • I think that it is good to have a spread of different viewpoints to be able to interview, better than one representative that may have their own itinerary.

    I think I would possibly use the masses to do some brainstorming regarding features and so on, then have a smaller group of people to actually shortlist a sensible feature set.

    I have to admit though, more often than not, you don't really get the choice.  There are usually stakeholders that are naturally going to be involved, even if offer little insight or help, and there will always be those that would be helpful and useful, and don't shout loudly enough.

    I think that it's also important to make sure that when features are being gathered, to ask question about them, directly to engage other viewpoints, to check the assumptions, and that the feature is correct, and not tied to a particular individual.

    It really is a balancing act.  The best bet is also to have a good cross section of people who regularly use and give feedback on the product, so that it is obvious if things are not headed in the right direction.

    I hope this helps,

    Martin Platt.
    Wednesday, May 14, 2008 9:36 PM
  • Thanks Martin, it would seem that in your experience there is little difference to the team with respect to the architecure as there is with any part of the process?  I ask because I've found it difficult to get some stakeholders interested because arch' tends to be too removed from end features whereas when the coding starts it's a little easier (although sometimes still a struggle) to get them to join in. Although some stakeholders (systems teams) it can be the exact opposite!


    Wednesday, May 14, 2008 11:05 PM
  •  pkr2000 wrote:
    I was wondering what people's experience is in terms of the type of team they feel is/was ideal when working as an architect? I'm thinking specifically about the production of the inital architecture here. E.g. I nice mix of developers, testers, customers, business analysts, systems support, etc. Or perhaps that's too much of a committee with too few relevant people and only a select few should be used?

     

    To me, your question does not make sense at all: how can a team structure be with specific reference to working as an architect? The architect is one of the roles/activities, that's more or less all.

     

    Although I find Martin's answer very sensible, in that each of us in any role has got some "analysis" to do, still I believe you forget the real process... As Architects, we might maybe need to ask a lot of people a lot of questions, still we won't ask questions about *primary project requirements*; that needs being done in Analysis.

     

    The auxiliarity attributed by Software Engineering to Architecture (seen as technology and infrastructure management), in practice stands for the fact that a real Architect should be like a real System Administrator: be there ready to help where needed.

     

    Architecture is not a driver; it is an enabler.

     

    -LV

    Wednesday, May 14, 2008 11:17 PM


  • Well, yeah, if it is available, it's nice to involve as many as possible to get a better view, if they're available to you.  The reality is that they often are not.

    I'm not sure that I see what you mean.  Do you mean that when you're cutting code you can put a prototype in front of people to get them to join in, but they won't do a whiteboard session?  If that is what you're saying, in some situations that has definitely been the case, then there's the situation where as architect you have never experienced the problem domain before, so it's difficult to understand the big picture, given a group of very specific features (often specified in terms of clicks and controls)

    It is difficult to get that balance, and I think that these sorts of skills are the things that set good architects apart from designers.  It's all about negotiation and persuasion.  My view is more that if somebody is not wanting to give feedback, then either they're not really a stakeholder, or they can't be bothered.  If they can't be bothered, or are not bothered enough about outcomes then there's probably somebody better to invite along.  If they don't join in fully, then their opinions will not carry very far through the project lifetime.

    Getting people interested is being able to make them feel involved in the outcomes, that their input makes a difference, and that their involvement will positively affect their future work by being better processes, more efficient, faster, controlled or whatever.

    Martin Platt.
    Wednesday, May 14, 2008 11:31 PM
  • I absolutely agree, esp. the last paragraph, 'feel involved in the outcomes...'

    Yes getting people involved is certainly the correct tactic and I also agree that it is part of "social" skills required.

     

    What I was trying to say about losing people when analysing the arch' is that for of the users the arch' is just too removed from their daily tasks.

    Let me make up an exaggerated example; An airport wants a system to scan luggage into containers and then onto a plane. So the arch' consists of tag scanner terminals, message queue, database, check-in desk terminals, back-office management. So to discuss the architecture you invite Business Analysts (BA), project sponsor, senior developer, a senior baggage handler and a check-in clerk. So the discussion quickly turns to drawing big block diagrams on a whiteboard with the message queue server, the database server, etc. So you quickly to start to lose the interest of the baggage handler and check-in clerk because you're not focusing on their domain. Wheras when the "developer team" (arch, developers, testers, BA, sponsor, baggage handler*s*, but no check-in clerk) working on the baggage scanner client holds the meeting to discuss the client software development the baggage handler is now fully engaged because the conversation is centering around their domain. It's still all conceptual (to start with) whiteboard work but now they're interested. Obviously it's still a continous evaluation process for the arch' so feedback from these meeting may still influence the arch'.

     

    So would you have initially invited the baggage handler + check-in clerk, would you have interviewed them (?) to check for interest, would you simply realise they probably wouldn't be interested yet and so rely on the BA\more senior customers, or etc?

     

     

     

     

    Thursday, May 15, 2008 6:18 AM
  •  pkr2000 wrote:
    So to discuss the architecture you invite Business Analysts (BA)

     

    Should be the other way round: the Analyst calls the Architect and tells: "Hey man! We've got this problem to solve, what do you think? What have we got in-house already? (Call Configuration Management.) What would you suggest building from scratch?  (Call Developers/Designers)." Actually better: The Analyst calls the Developers/Designers: "Hey guys! We've got a problem to solve. What do you think? ... Cool! A a starting point at least. Let's listen from the auxiliaries also; you know those pals, the Architect above all, they go mad if we don't call."

     

    Analysis is _the_ driver; Coding _is_ production; Architecture (whatever it is, and that's another question) is _an_ enabler; same applies to PM, BTW.

     

    -LV

    Friday, May 16, 2008 12:55 AM
  • If the main purpose for a team structure were to architect a solution, your question could make sense but it isn’t. In other words, a customer does not need to pay any money for any deliverable out of “architecting the solution” other than the actual working software part of the projected business value.

    See Rapid Development: Taming Wild Software Schedules by Steve McConnell for an excellent study about the relationship between type of problems to be solved and related team structures.

    Sunday, May 18, 2008 9:50 PM
  • Marco, what (or who in) your experience would you involve in making those decisions? Thanks for the link it's been a long time since I've read that.

     

    [Edit] PS for a bit of background reading about my question see Architectural Envisioning on Agile Projects

    Monday, May 19, 2008 7:21 AM
  • The referred article is quite interesting; but I am going slowly in the reading. In the meantime let me add a comment about what I have observed in my projects. I have observed the need for a balanced mix of general strategies like problem resolution, creativity and tactical execution (where tactical execution tends to be addressed by generative programming techniques when the observed occurrence confirms that need); hence, the team structure that has worked in my context is also a mix of problem-solving, creativity and tactical execution teams with autonomy and trust as the dominant traits. Then, my most frequently used team models are skunkworks team and feature team.

    Tuesday, May 27, 2008 11:58 AM
  •  

    The Ideal team structure is the one that delivers best result. Having said that, we all know that we are not living in ideal world. But our choices for the team at times are constrained by following:

    Individual's Availability.

    Technology Expertise

    Budget etc to name a few.

     

    But when it comes to deliver the best thing that works is Synergy among the team members. At times the role of architect is being confused with a Senior (or Smart) Developer, Analyst, PM etc. But in purest form Architect not only helps delivering the best technical solution but also works with BA to refine the requirement and translate the business buzzwords to technical terms (for development team). So he has to be competent in both the areas equally.

     

    Cheers

    Samir

    Tuesday, June 3, 2008 1:03 AM
  • Samir, in your experience what combination of team members makes for a good team, e.g. would you include customer or system's or support stakeholders in that team?

     

    Tuesday, June 3, 2008 10:26 PM
  • pkr2000,

    As much as possible I would like to have customer in the team. More than customer it has to be the user whom I would like to have as part of the team if not full time then at least 1-2 hrs a day while the system is being developed. In past whenever I had a customer (or their representative) in the team we had a positive impact on the entire development process.

     

    Customers play a role of those who can give the business functionality related inputs and also they can be handy during the testing. Since they are part of the team they can detect the error early and the turnaround time and cost of the error is minimal.

     

    In the development team I personally prefer 1-2 experienced developers and rest university graduates (recent passout) as they have are very open to new challenges and technologies.

     

    Cheers

    Samir

    Tuesday, June 3, 2008 11:46 PM