Comments on: The D-I-D Approach to Scalability http://akfpartners.com/techblog/2009/08/31/the-d-i-d-approach-to-scalability/ The Scalability Blog Sun, 27 Nov 2011 04:02:26 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Wabb http://akfpartners.com/techblog/2009/08/31/the-d-i-d-approach-to-scalability/#comment-169 Wabb Fri, 29 Jan 2010 21:51:27 +0000 http://akfpartners.com/techblog/?p=422#comment-169 You got it Wade! You got it Wade!

]]> By: Wade Arnold http://akfpartners.com/techblog/2009/08/31/the-d-i-d-approach-to-scalability/#comment-168 Wade Arnold Thu, 21 Jan 2010 19:35:44 +0000 http://akfpartners.com/techblog/?p=422#comment-168 OK I had to re-read the article. Thanks! THink big, implement medium, and deploy small. D-I-D OK I had to re-read the article. Thanks! THink big, implement medium, and deploy small. D-I-D

]]> By: Wade Arnold http://akfpartners.com/techblog/2009/08/31/the-d-i-d-approach-to-scalability/#comment-167 Wade Arnold Thu, 21 Jan 2010 19:28:33 +0000 http://akfpartners.com/techblog/?p=422#comment-167 Is there a reason that you have Design Implement and Deploy as the labels of columns? Should labels not be The Scale Objective with a chart name of DID? Maybe I am missing something? Thanks for a great article! Is there a reason that you have Design Implement and Deploy as the labels of columns? Should labels not be The Scale Objective with a chart name of DID? Maybe I am missing something? Thanks for a great article!

]]> By: Kent Langley http://akfpartners.com/techblog/2009/08/31/the-d-i-d-approach-to-scalability/#comment-166 Kent Langley Wed, 02 Sep 2009 00:00:53 +0000 http://akfpartners.com/techblog/?p=422#comment-166 Excellent writeup. Thank you. This is almost exactly what I advocate day after day regarding planning for scalability. I like that you'd put a bit of a framework around it. Personally, I treat scalability concerns the same as any other "feature" in a project in a Agile Development context. It's brought up and discussed briefly in scrums, possibly handled in a followup meeting, and then either put on the backlog to be prioritized w/ everything else or worked on next if necessary. It's often very, very difficult to get some teams to think pro-actively about scalability AND agree to table it for later. I think this is because sometimes when you have these discussions people realize that they need to "fix" something and can't really help themselves. Of course, these days with cloud computing gaining so much traction and resources being available on-demand more than ever at a moments notice it's getting easier. But, if you don't architect for scalability at the outset you may find when you get the implementation and deployment phases that it's impossible to do what needs to be done. But, that's a whole other topic I suppose. Cheers! Excellent writeup. Thank you. This is almost exactly what I advocate day after day regarding planning for scalability. I like that you’d put a bit of a framework around it.

Personally, I treat scalability concerns the same as any other “feature” in a project in a Agile Development context. It’s brought up and discussed briefly in scrums, possibly handled in a followup meeting, and then either put on the backlog to be prioritized w/ everything else or worked on next if necessary.

It’s often very, very difficult to get some teams to think pro-actively about scalability AND agree to table it for later. I think this is because sometimes when you have these discussions people realize that they need to “fix” something and can’t really help themselves.

Of course, these days with cloud computing gaining so much traction and resources being available on-demand more than ever at a moments notice it’s getting easier. But, if you don’t architect for scalability at the outset you may find when you get the implementation and deployment phases that it’s impossible to do what needs to be done. But, that’s a whole other topic I suppose.

Cheers!

]]>