Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Future proofing software

Options
  • 16-10-2009 8:42pm
    #1
    Registered Users Posts: 546 ✭✭✭


    Hi all,

    I am looking for direction with a project that I can see coming for me.

    We have some software packages that I would like to see converted to web software.i.e the cloud
    Currently the developers develop with .net and all software needs a dedicated PC to install onto and then users need to get the admin end loaded onto their PC's.

    My questions is how do I go about transforming software from this state to a web based software package.

    this is the future of our software package so the sooner we start the ball rolling the better

    any ideas appreciated


Comments

  • Registered Users Posts: 515 ✭✭✭NeverSayDie


    Well, as I'm sure you appreciate, that's an awfully broad and vague query.

    In general terms, assuming you plan to stick with .NET, start researching ASP.NET - that's how your app's new UI will be implemented, if it's going to be web-based. Language-wise, assuming it was VB.NET or C#, it can stay that way.

    The remainder of your app may or may not have to change much, depending on how well it was architected - if it's fairly n-tier based, with the data access and business stuff separated from the UI, it shouldn't be too bad. You'll mostly be changing how the UI works, but the backend could remain broadly the same.

    Depending on how the apps currently get the data they work on, there may be changes there too. If they were connecting to a remote database, they can still do that more or less, just in response to a web UI instead of a desktop based one. If they maintained some kind of local datastore, you'll need to refactor that so it fits around a shared DB - not hugely difficult, depending on the details and your level of experience with this kind of work.

    All the above is assuming there's no tricky stuff like hardware access going on in your apps. If there is, you've got an interesting problem on your hands (could still be solvable though).


  • Registered Users Posts: 546 ✭✭✭abakan


    Yes thank you for that. dosent sound like it should be to difficult to make the transition.

    the web interface would indead have to work with hardware in most cases. so the GPRS device would have to talk to the remote database. there are ways around that though. the device could work in batch mode.

    I feel this is the way forward for our software. I have been looking at the salesforce.com model and feel it is deffo the way forward.
    The web based model lets us demo software easier, administrator users, upgrade software easier, no problems with users installing other app on their server and affecting our software.

    It going to be a work in progress from here on


  • Registered Users Posts: 515 ✭✭✭NeverSayDie


    Unfortunately, the fact that you're hardware dependent will lose you some of those advantages - you'll probably still have to install and update client software on the users' PCs. That said, the majority of your app and most of its UI will still be on the server end, which is advantageous.

    You also won't have the OS-agnostic aspect of the web app, if you're hardware dependant - unlike something like SalesForce.com, which can be accessed from more or less anything with a web browser. Of course, if you have some user models for your app that don't involve hardware interaction, they can be implemented without any of those concerns.

    Re the hardware, I'd look into BHOs or ActiveX controls (for IE) or plugins/extensions for Firefox in terms of having your UI interact with it. You might get away with a Java applet for the purpose, depending on security and such like (applets generally have a lot less access to the user's computer than plugins can). It is doable - I've seen it done for card reader hardware for instance, but it's likely to be tricky enough. It's also going to be pretty browser specific - you may end up just supporting IE, or doing different combinations of your plugin for different browsers.


Advertisement