locked
How long the Architect role lasts in a new development project ? RRS feed

  • Question

  • Hi,

     

    Let's say we have a new development project and initially we are spending time doing analysis, prototypes, finalizing the technology where architect person is highly utilized. Architect will continue on high and low level design or the blue print for the project. What next ?... the development.

     

    What Architect should do during development... He needs to change his cap become a lead now and start overseeing the development and get into the coding or is it time to move out of the project... What's the expectation from the management at this stage ?

     

    What role does the Architect role play in the agile development projects where there are no blue prints ?

     

    Pradeep

    Thursday, August 14, 2008 5:29 PM

Answers

  • Thought I'd add my experiences to this interesting discussion.  Like silvercode, I see the architect as an enabler.

     

    Large projects accrue a certain amount of technical debt by the time they are deployed.  These arise for a variaety of reasons but include;

     

    1. Compromises are made to meet business critical deadlines.

    2. Requirements are descoped for business reasons

    3. New requirements are identified during the development but cannot be included in initial product.

     

    These factors mean that an architect is often required not just for the initial project but for subsequent phases of an evolving architecture.

     

    Also, an organisation may not have resources to fulfil all the roles independantly.  Therefore, an archtiect often has to wear many hats in an organisation.

     

    These may include leading the technical team and negotiating with stake holders.

     

    Therefore, the architect will probably be dividing their time between a variety of projects.  Most likely divided between architecting new systems and tackling issues in existing and evolving projects.

     

    Finally, it is a mistake to think agile projects have no documentation or blueprints.  They produce only the documents or blueprints that are required to describe significant areas of the system. Hence the phrase 'just enough documentation' in agile literature.

     

    hope this helps.

     

    Monday, August 18, 2008 2:59 PM

All replies

  • I think that an architect should be just that, not for example a lead programmer. An architect can be a lead architect if a project is so huge that it needs several architects, but a programmer should be a programmer. Also a company needs main architect that is above normal architects.

    Architect does the architecture and designer does the design, then programmers take the designs and make some software. If designer comes up with some new issues that need the attention of architect, then the architect studies the issue and adjusts the architecture for designers. Also architect has to work with possible other project architects, the lead architect, and the company main architect to get architecting synchronized in the company. If there seems to be no work to do, then the architect just takes some issue by himself and studies it plus adjusts the architecture.

    There are no methods that has no blue prints in software and system engineering, because that would be no engineering but crafting. Crafting doesn't need architects at all, its more like art.

    Management propably doesn't have a clue and I don't care as long as they manage things the way I want.
    Thursday, August 14, 2008 6:04 PM
  • "Architect does the architecture and designer does the design"

     

    - What is this architecture really is in the context of the new system we are developing... Analysys and Technology finalization or is there something else ?

     

    Thursday, August 14, 2008 6:11 PM
  • There exists many approaches to software architecting and there are not any standard about it yet. The tasks of a software architect and system architect vary, but they concentrate on selecting and creating structure and minimizing complexities.

    http://en.wikipedia.org/wiki/Software_architect
    http://en.wikipedia.org/wiki/Software_architecture

    I think that an architect should create the general environment (=architecture) for the help and limits for designers to use. The architect creates architecture and designers use that. How detailed the architecture should be? Well, it can be quite detailed when you think that the architecture is for guiding and limiting the designers.

    The architect is usually seen as the person who designs the solution (what the system does, what kind it is, and so on). I don't think much like that. I think that architect should be more like an enabler. Architect gives the possibilities, an analyst tells what is needed, and then lead designer designs the system with normal designers.

    So there are two kinds of blue prints. The architecture and the design. The design follows the architecture and the implementation follows the design and architecture. These are also divided for software and system so that software has software architecture and system has system architecture. The designs cross so that the system has to know what data goes into a certain software application, because a system can have many interacting applications.

    Of course the architect can check how the designers and programmers are creating software, because that helps the architect to understand how the architecture works. But I don't think its the responsibility of the architect to supervise that everything is done as architected. There should be some other helper people for that. The architect should concentrate on making the architecture better.

    When the architecture is ready, the architect hands the architecture to the project. Then the architect starts to learn from the project and to improve the architecture. The architect should talk with other people about the architecture, but talking should not take too much time away from anyone, plus the architect should have last word about the architecture. The architect should also communicate with the company main architect and synchronize ideas, which takes time too. And if the architect notices any mistakes in the architecture, he should use time to fix them. If there are ambiguities or difficult to understand issues, they should be fixed. Terms and concepts should be revised.

    At some point the project ceases into maintenance phase, and the architect could have done something (that takes time too) to make the life of the maintainers easier. There can be solutions for improved security, with the help of main architect of course. Law. standards, and regulations need to be considered.

    Usually projects won't last years after years, so after some time is spent and the project goes into maintenance phase, the architect can go to an other project. But the architect should be around, in case he is needed again. If the architecture is made with care, the maintainers don't have to start tweaking the architecture later. So the architect should use time so that everything is in good shape for sure.
    Friday, August 15, 2008 8:36 AM
  • Thought I'd add my experiences to this interesting discussion.  Like silvercode, I see the architect as an enabler.

     

    Large projects accrue a certain amount of technical debt by the time they are deployed.  These arise for a variaety of reasons but include;

     

    1. Compromises are made to meet business critical deadlines.

    2. Requirements are descoped for business reasons

    3. New requirements are identified during the development but cannot be included in initial product.

     

    These factors mean that an architect is often required not just for the initial project but for subsequent phases of an evolving architecture.

     

    Also, an organisation may not have resources to fulfil all the roles independantly.  Therefore, an archtiect often has to wear many hats in an organisation.

     

    These may include leading the technical team and negotiating with stake holders.

     

    Therefore, the architect will probably be dividing their time between a variety of projects.  Most likely divided between architecting new systems and tackling issues in existing and evolving projects.

     

    Finally, it is a mistake to think agile projects have no documentation or blueprints.  They produce only the documents or blueprints that are required to describe significant areas of the system. Hence the phrase 'just enough documentation' in agile literature.

     

    hope this helps.

     

    Monday, August 18, 2008 2:59 PM
  • What should the architect be doing during development?  The architect's main responsibility once development is underway is to monitor quality.  You may need to be involved as the design is further detailed and as design related issues are raised.  Where the development team is removed from the organisation, this is even more important and the you should try to be an approver of the design before the developer has invested too much effort in coding.  Areas of residual concern are often based around non-functional needs.

     

    In an Agile development project, the architect is often not involved in daily scrums and those who are involved are frequently not thinking about an elegant blueprint for the solution.  In these scenarios, you as architect need to produce a much more detailed design [than you would have done in a RUP project] before the Agile approach to Elaboration and Construction kicks in.  One suggestion is to develop a parallel stream of work where the architect and the developer collaborate on the blueprint whilst the the others are attacking functionality.  

     

    Thursday, August 21, 2008 9:55 PM
  • Thanks for the different inputs.

     

    I have come across an another designation called "Documentation Architect" where customer's expectation of the role to be to spend 60% of the time on creating documents on architecture and design and 40% on prototypes and finalizing the technologies and design.

     

    Why is this different designation "Documentation Architect"... Any Architect is suppose to create documents and blue prints for the application.

    Wednesday, October 22, 2008 2:32 AM
  •  PradeepKV wrote:

    "Architect does the architecture and designer does the design"

     

    - What is this architecture really is in the context of the new system we are developing... Analysys and Technology finalization or is there something else ?

     

     

    Very good question and typically adds confusion to new projects.  I would say you need to setup a "Roles and Responsibilites" document which maps out the specific roles and what is expected of them in terms of work and deliverables.  You will not believe how many times this has saved me.  Again, those who know me understand that I am a pragmatist - so I *rarely* get to suggest these type of documents.  Most customers dont see the value and just want to get to work.  With that said...

     

    At its core, the Architect is responsible for taking all the disparate components ( infrastructure, development, networking, security, etc ) and ensuring that they are work together to facilitate the solution.  Think of the Architect as the Foreman who overlooks the construction of a building.  This entails having the big picture ( i.e. creating visual documents to maintain a consistent view ), diving deep when certain component development runs into challenges ( engineering ), and ironing out the dependencies between them ( project management ).

    Friday, October 24, 2008 6:30 PM