Restrictive Development- Propagating Architectural Patterns

Restrictive Development- Propagating Architectural Patterns

• davidhart_home

  I also think architecture governance is an important issue and I guess in a sense I am doing something similar when I provide "Module Blueprints" as part of the Software Architecture Document.

  One difference, I believe, is that my (current) thinking is that this chapter should only be written after the first few iterations when both the architecture and the design directions are more clear.

  I also think that during these first iterations, higher involvement by the architect is needed - both as a reviewer and as a team member

  Regarding being a team member. I think that partial involvement with the design and some prototyping is enough - others believe the architect should implement as well ("eat your own dog food"). I guess that has to do with project size and the number of project the architect has to support (I also think it is problematic as you get bogged down in sea-level details and project time constraints )

  By the way, you may want to read a related blogpost I wrote: SAF - Deployment - What to do when the architecture seems stable

  
  
  

• smartpi

  question, this is all about propagated through the different construction phases. But what about the testing phase or better after the building proces how do you check/ test if the project that has been build satisfies the architecture. What do you use

   

   

  
  
  

• Alistair Black

  I agree with Arnon.  Testing is done at multiple stages through out the project.

   

  The only pronounced stage of testing is the feature testing.  I make my testers create test suites and test cases from the use cases.  They are not allowed to see screen mock ups at all.  I want them to be taking the initially defined functional requirements and use them to create tests from them.  That way we are sure the requirements have been implemented as they were described to the stakeholders.

   

  Beyond that testing is always going on.  TDD (unit testing), integration testing, testing for production. 

   

  How do I make sure the architecture designed is what has been implemented   If it works, and it works great, then we have done our job.  If the customer is happy, so are we.

  
  

• Lyn Perkins

  Thanks for the feedback Arnon.

  I guess one thing that may not be clear is that these patterns are only intended to be Architectural level patterns that propagate through the module level designs, and they are continually reviewed with every module developed using them. They are not written in stone that are just intended to be the guiding starting point and are most likely to be modified throughout the projects iterations by continuous feedback from the module designers. But they are intended to highlight how the Quality Attributes are enforced through out the project. They are in fact the resolution to any architectural level pain points identified during the architectural analysis and therefore are intended to relieve the design phase of having to worry about figuring out how to implement those pain point, and keeping consistency across the modules when implementing these parts of the application.

  
  

• anand_nalya

  That is cool. I would be doing the exact same thing as you if I was developing in the same context. So it sounds like we are on the same page just in slightly different storylines.

  
  

• rosnay

  Tad,

  It is an interesting direction using these patterns to demonstrate how quality attributes are met (I do that during Architecture evaluation based on scenarios I try to get formalized at earlier stages). I use what I call blue prints to show nominal scenarios e.g. nominal view from a user hitting the OK button on a form until a message goes out to the servicebus from the appropriate service agent. I try to highlight what things the software infrastructure does and what does an implementer needs to pay attention to - As I said this is documented after some effort has been done in designing and implementing such scenarios.

  I guess the point is what is the role of the SAD in the development process. As you've mentioned in another thread you need detailed documents to enable communications and establishing ground roles with offshore/offsite teams. While I, currently, work mostly with local teams and try to introduce agility (SCRUM-induced) into the projects and thus I try to keep the SAD at a "barely good enough" condition and use it mostly as a beacon on the architectural directions taken (for newcomers and maintainers).

  Arnon

  
  
  

• Tony Chun Tung Siu

  I cannot speak for Tad, but the way I see it there isn't really a "test phase" test is something that occurs all the time (before coding sometimes (TDD)).

  There is an acceptance test phase (I sometimes also have integration phases for multi-disciplinary projects) when you get to the final delivery of the project to a customer - however whether or not the architecture was followed at that stage is somewhat of a moot point. Assuming the architecture was good and wasn't followed and things somehow work - from the project's point of view this is a success. (It might prove to be a short-one when some hard-to-fix bugs occur or when a change request comes along etc.).

  In order to minimize these effects you should strive to work in short iterations and have get the product/project to a deliverable status at each iteration. This is a good practice from the architectural point of view and the project management one.

  Another thing is to try to stay involved even when the architecture is proclaimed to be ready (that's what the blog post I linked to in a previous answer talks about)

  Arnon

  
  
  
• Restrictive Development- Propagating Architectural Patterns