Can it be done with OutSystems?

Can it be done with OutSystems?

Hi Guys,

If you’ve been working with the OutSystems Platform for as long as I do I’m positive you have heard the famous quote “Can this be done in OutSystems?”.

As an OutSystems passionate dev I can say that my answer in 99% of the situations is yes (and it was long before I joined the company) but sometimes is a bit harder than to just use the out-of-the-box features the platform gives you.

So last year i got a request to implement a screen with the OutSystems platform that implemented the exact same look and feel as an existent VB6/Win32 application. It was a nice challenge but at the end of the day we had it done. This is a screenshoot of that screen (without any customer reference for privacy reasons).

So this is the time to publicly thank Cristiana for the help in doing this and share with the community a simple CSS file and a few images so in the future someone can save himself/herself a couple of hours.

And guys, when in doubt it will probably be possible with the OutSystems Platform.

This is what I'd call "ensuring user adoption by changing everything but the interface"! 
Talk about resistance to change... :)

My company has converted several major systems with a windows look and feel, but its not always about resistance to change as much as $$$$$'s!

Re-training 2000+ call centre agents costs a lot more than having the same look and feel!  :-)
Keith, you make a great point. I've been there (rolling out new systems to tuousands of people) but somehow I had forgotten how terrible that can be... thanks for reminding me! :)

However I would assume that, if you're rolling out a new system that replaces an existing one, you'll take the opportunity to take care of problems with the original system, improving usability, adding new functionality... so there will be so much new and different stuff that you'll always have to re-train people.

Therefore keeping the original look & feel doesn't feel like it will save much of thr re-training, don't you agree?


In my experience these conversions have always been for reasons of a technology switch.

Normally these systems have been stuck in time because the technology they were originally built with is no longer supported and they may indeed have issues that need to be fixed and also a backlog of end user change requests.

The need to change is most often an IT wish rather than a business wish. So the business is reluctant to re-train a significant number of people with their budget dollars "just because IT wants to change the technology" and they are also unwilling to get involved in a massive amount of testing, not just re-training.

So what we have normally done is rebuilt the system with the same look and feel and the same functionality which means almost no involvement from the business and with the great benefit that we can re-test it to do exactly what it does now side by side (press this button this happens ... in both places) means less need for complex test cases and competant testers can do it without too much documentation, almost like playing spot the difference :-) 

Added benefit both systems can co-exist so users can be migrated from one to the other in manageble blocks.

Once re-platformed, with minor to no re-training for the business, the backlog of business issues can be addressed in future releases, and the UI can be re-jigged as you go, quite often with simple CSS changes. Now the business is willing to pay as they are getting new stuff and they have to re-train anyway.

Just my experience.

Personally I have always wanted to re-build the systems we have converted but it's the Clients call. My client convincing rate to re-build is not that high maybe 1 in 4 but either way they have always been happy.


Great context! Thanks for sharing your experience Keith. What you're saying makes lots of sense. Btw, are there any particular technologies that you see this approach being used the most? From which technologies have your clients migrated from the most? And into which tech have they migrated to? Thanks
My company used to be experts with Forte (a 4GL OO Development technology from Forte Systems in the USA). Forte (later called UDS) was a proprietory technology which allowed companies to build very large systems while being relatively uncaring about what database, server or topology it was subsequently deployed to. It just did that for you. A really remarkable development tool for rapid (20:1 productivity over Java) enterprise class development. Because of its abilities and its cost it was primarily bought by large companies for large systems or COTS systems developers because they could sell to many environments from the same code base. It had the capability to develop very rich interfaces for Windows or the Web. 

Unfortunately Forte was bought by Sun Microsystems who then promptly End-Of-Life'd it!! Why we don't know. Not invented here perhaps. This then left some major companies world-wide with some major systems either developed themselves or bought from COTS vendors that were now relatively frozen in time as various platforms became unsupported over time by Sun. Large complex enterprise systems financial, government, utilities etc.,.

We built several of them ourselves including all of Purolator Couriers (Canada's largest Courier company) Customer systems: Call Centre, Dispatch, Pricing, Contract Management, Service Directory ..... 

Unlike OutSystems (advertised ability), Forte did not have the ability to detach the code, it was a proprietory language, so over the past 10yrs we have been involved in many Forte to Java conversions. Partly automated but also quite a lot of manual effort, in the USA, Canada, Australia and Europe. 

Big bang like-for-like conversions made that technology transition as fast as possible anf finacially viable as I described previously.

Not sure how we would have converted to OutSystems as we would need the ability to generate the code and suck it into the platform or build the integration layer for use by integration studio and do the front end in OutSystems I suppose.

Now OutSystems should enable us to achieve that same rapid development without the same risk of using a proprietory technology without OutSystems ability to detach the code one day.

The more you describe the more sense it makes.
Thanks again for sharing all this context. I truly find these interactions with the community one of the most valuable assets here! Txs