As the subject goes; once a software architect puts down the high level design and approach to a software that is to be developed from scratch, how does the team ensure that it is implemented successfully? To my mind the following things will need to be done

  • Proper understanding of requirements
  • Setting down coding practices and guidelines
  • Regular code reviews to ensure the guidelines are being adhered to
  • Revisiting the requirements phase and making necessary changes to design based on client inputs if there are any changes to requirements
  • Proper documentation of what is being done in code
  • Proper documentation of requirements and changes to them
  • Last but not the least, implementing the design via object oriented code where appropriate

Did I miss anything?

Would love to hear any mistakes that you have learned from in your project experiences. What went wrong, what could have been done better.

Thanks for taking the time..

  • 1
    Coding practices and guidelines are likely to be adhered to much more if you get them from the team doing the implementation. Involve their opinions since they're the ones who will have to live with it. Decide whether you want "The Right Way", quality over consistency, or the "New Jersey" approach, consistency over quality. Sep 20, 2012 at 14:20
  • Be consistent. You'll need time to see what works for you and what doesn't.
    – superM
    Sep 20, 2012 at 15:19
  • -ve markers please leave a comment so I can frame my questions better next time:) I've seen many other questions here that don't "fit" the format but have got some good responses to it.
    – user20358
    Sep 21, 2012 at 8:03

2 Answers 2


From your list: "Implement the design via object oriented code" Absolutely no. You implement the design with the best tool that can be used for that specific problem. It that means using a functional programming language so be it. Otherwise OO is a hammer for the screws of your project.


  • Involve the user (very important). In fact, all stakeholders.
  • Release early, Release often.
  • A branching strategy
  • Unit test, Integration test, any kind of testing
  • sorry about that. what I meant was, where appropriate. Obviously you wont be able to apply OOP in ETL. My bad, will correct it. Thanks for pointing it out :)
    – user20358
    Sep 20, 2012 at 14:08

Determining if a project was implemented successfully is pretty easy - does it meet the business requirements and are the support costs low?

Everything else (OOP, testing, documentation, guideline adherence, etc) are means to those ends.

They're mighty important and incredibly useful means to the ends, but that doesn't make them the solution. As an architect you can follow all the rules and still fail spectacularly if you lose focus.

I was going to add this as a 2nd answer, but I guess not.

2 way communication is probably the most important tool an architect has. An isolated software architect who issues edicts but doesn't solicit and listen to feedback from the team (& from the business) is going to be ignored.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.