June 2003 - Posts

System Testing
Tuesday, June 17, 2003 11:04 PM

In a project I have been designing and working on lately, we are almost about to finish system testing and enter UAT (user acceptance testing). Its nice to be able to see something you have designed really start to work as intended, but what I find most interesting right about now is that we are also about to do some performance testing. Its good to see your design doing what it was intended to do, but what can it *really* do when you put the "pedal to the metal"?

Its a big web application and has been designed with microsofts best practices in mind. Its extremely resilient and makes heavy use of remoting.

Side Note: I think remoting is a great technology and much under-rated in the web services hype. For a good remoting link, check out one of the remoting gods at http://www.ingorammer.com/RemotingFAQ/RemotingUseCases.html which goes a long way to explaining the right situations for remoting.

To continue, this app is a web based app and allows entry of home loan application for pocessing, validation, PDF creation and sending to processing centres. The information gathered can be quite huge (20 applicants, 10 real estate assets per applicant, 10 non real estate assets per applicant, multiple incomes per applicant, multiple securites per applicant etc. etc). A lot of this info is separated across different pages but not so much as to make the app too clunky. Some pages can weigh in quite heavily and although it is performing extremely well, its never really been "stressed to the max". I have high hopes for the app and think it will do quite well and I will post the performance figures here when its all done to let you know how it goes.

In terms of application progress, its gone very well, with the help of microsoft best practices. These best practices and pre-scriptive architectures are excellent sources of information for system design with performance, scalability, security and any other architecture buzzwords you can think of. I highly recommend them. Check em out at http://msdn.microsoft.com/practices/. They really do help in all aspects and prevent/avoid a lot of problems from the outset of application design.

I'll let you know how perf testing goes.


Monday, June 9, 2003 6:35 PM

Well, my first ever blog entry. I know I'm excited. First a bit of background.

I work for a large international corporation that provides IT services to other companies (typically fairly large ones). This can be project management, web site design, web applications, desktop applications, technical architecture roadmaps, consulting services, and a whole range of other related services.

As one of the main .Net people within my organisation, I carry a defacto evanglist role for .Net in general, whether I like it or not. Our organisation deals with ASP/ASP.NET/Java/J2EE/C/C++/Delphi and any other technology that will enable it to meet its client needs and/or requirements (and therefore make money).

With that in mind, it would be nice to emphatically state that .Net can meet the clients goals in each and every respect, that the architecture, performance, and features of .Net can not only meet the clients needs, but allow us, as solution providers, to exceed them. While this is certainly true in most cases, a client quite often gets immediately suspect when you zealously state that .Net will solve all their technical hurdles, and that their existing technical investments have either become obsolete and should be discarded, or that they should invest countless man hours and money deploying this new .Net technology throughout their organisation because of all the technical merits that it will garner now and in the future. Again, this may all be true, but people dont like to be bombarded with opinions, especially clients wanting their system/website/solution delivered. They want a solution to their problem in the cheapest and best way possible. I have seen a lot of projects go to different technologies and/or vendors because a solution provider was over enthusiastic about a particular technology or simply bad mouthed their existing technology in favour of an all encompassing new technology (in this case .Net).

Whats my point? Well, sometimes you have to lose a battle to win the war. Go with a clients demands on technology, and try to factor in .Net where possible, but not to extremes. An over zealous proponent can do as much harm as a really bad implementation/system for a technology. Integrate where you can, demonstrate that the part that is .Net is performing well, and has potential to perform better, but given the constraints of the system its integrating with, your options are limited. Show a client whats possible, but dont force the issue, know when to step back and allow things to proceed, perhaps not optimally for getting .Net into the picture, but in time, you can demonstrate the case.

Be a solution provider for your client, and provide a solution that meets their needs, budget and inclination. As fellow .Netters, we know that its a brilliant technology, but like politics and religion, you cant be too pushy or your technical arcguments wont mean a thing.

Hope my first blog hasn't bored you too much.


More Posts

This Blog