6 Architecture consideration within Scrum


  1. Normally enterprise architecture should take place before the project even starts.It should be part of the project start-up or mandate. 
  2. In particular the organizations application architecture and integration architecture should be done. 
  3. Its unlikely that there will be a enough information at this point for information architecture,This will need to evolve as the project progresses. As for the other enterprise level architectures, many of these will be defined and form part of a definition of done.
  4. Typically in the start-up of a project, a BA, product owner will capture epic ideas and these will be broken down into high level feature stories/requirements. Note this is not going to be detailed and ready for a team to implement, but it covers enough knowledge that an architect should be able to formulate a technical approach. This also servers as a high level release plan.
  5. A good technical/system architect should be able to look at these feature requirement and formulate a technical approach to building the solution. He/she should deliver an architectural vision with big layers, highlighting technologies of choice which align to the organizations standards. Interfaces to external systems should be identified from the proposed new integration architecture.
  6. The key here is for the architect to identify technical risks where there are unknowns and arrange for spikes to mitigate these risks. For the rest of the work, the technical architect should be in the team and build with the team.



Comments

Post a Comment

Popular posts from this blog

Scrum Answer to Top 10 Software Project Risks

Source: (The Standish Group, 2011) Lack of top management commitment Scrum demands commitment from the top management through the assignation of a full-time cross-functional self organized team. The team is protected and can take their own decisions about the project with the support of the top management. Failure to gain user commitment In Scrum, the team constantly show working software to the users, which increase the commitment and feedback. Misunderstanding the requirements Scrum knows that is not possible to fully understand all the user requirements. In each iteration, the team work in the more important and clear requirements. As the software is developed, the team get better insights about the project goals and have more clarity about the following requirements. Lack of adequate user involvement Constantly working software makes the users more involve in the process. Lack of required knowledge/skills in the project personnel In Scrum, the teams are cros...
Read more