For a customer of us, I will be asked to do some major maintenance on their business application. The application in question is one that handles the order process and production steering of a pallet manufacturing company. Their current application was built over 10 years ago in v8, migrated all the way up to 11.3 and consists of a mix of smartobjects and plain progress.
I will be visiting them tomorrow and then I'll ask what they have in mind, but I thought it would be good to collect some thoughts here on my opportunities. Should they ask for a total rebuild, should I then:
They will probably also want an app for the workers inside the factory.
I know there is not much info I can provide, but I'd love to hear some input on what would be wise to use. I already know that they want to keep working with OpenEdge and that they have one person that does some small maintenance on the code, so the final solution should be low-level enough for him to do some small things.
One of the main reasons why modernisation is so hard is that applications have been designed lazily with business logic and UI logic etc all mixed in the same code. So I would suggest that whatever solution you implement you ensure that everything is nicely split out so that in 10 years time a new modernisation project is a lot easier to achieve!
But then you probably already know that ;)
Not enough info to give much tips. In any case watch out for vendor-lockin with frameworks! And look further than the horizon psc provides (another lockin), there are f.e. more web frontends than kendo. You are not a psc presales-consultant nor do you have to make a loyal impression here.
https://inviqa.com/blog/8-tips-for-avoiding-vendor-lock-in (quick googleresult on avoid vendor lockin, there will be better links)
http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks
https://survivejs.com/blog/mobx-interview/#on-frameworks-vs-libraries
Thanks for the answers so far. @James: yes, seperation of BL and UI is one of the primary concerns, in years from now they should be able to replace the front end easily.
@[mention:5a647afc67ec4e118db4fd9337f8a264:e9ed411860ed4f2ba0265705b8793d05] not sure what you mean with not being a presales consultant. I would need to check my bank account, but I don't think I am paid by PSC ;)
With regard to frameworks: I am a bit divided on this; a framework like DWP makes life extremely easy for a developer, but there does not seem to be a lot of activity anymore. Besides, the inner parts are closed source, hence lock-in. OF-1 seems active, just as the SmartComponentLibrary, but I don't know how these rate on closed vs open sources.
And sure, there are more web frontends, but having one that works tightly with OE has its advantages. And my JavaScript skills are a bit rusty at best, so I am definitely not looking for a solution that requires heavy JS programming.
Patrick, closed source is not the criterium for vendor lockin. Moreover "we are pretty reluctant to use all-in frameworks. The first two years they serve you really well. But the third year they cannot longer keep up the pace with new technologies. The fourth year you spent refactoring just be able to adopt new technologies." (one of the links I sent). Good luck advising your customer.
|
```
The primary question is, is your client willing AND capable of developing all components of the new architecture, backend and frontend required to match the users’ needs along with developer productivity to match the required time to market themselves.
```
That might be the question on the openedge backend side. Allas, and that is one of the reasons why I'm not a fanboy of psc products and openedge framework vendors. On the web frontend side (and other backends) it is a different story. You can use libraries there, see the links I sent. The opinion I shared is not from some maniac that wants to program everything himself but from succesfull and in part big and well known enterprises.
Stefan, I sure read the link with the "we are pretty reluctant to use all-in frameworks" part and especially the part you cited got my attention since it is exactly what my fear is with frameworks. When I leave this customer, 1 or 2 years from now, I want to leave them in a state where they can build upon in the years to come. That means - for sure - separation of BL and UI and an application backbone, be it a framework or set of libraries, that they can use themselves.
Yes, but you said "a framework like DWP makes life extremely easy for a developer", therefore I quoted that.
Of course you should separate ui- and backend logic, that's self-evident and antique knowledge in this community.
There are some open source oe backend frameworks also (oo and so), I would have to search for them. Maybe you can ask f.e. Roland de Pijper about them. These should not be hard to maintain if you do not have too many special wishes. I have no idea about their soundness. There is also autoedge that is usable as starting point. I think M. Fechner has a monopoly on commercial oe frameworks since years. If you sell his framework you should demand a share. ;-)
Yuk, frameworks... You can get yourself (I mean that company you advise) into big trouble also if you don't want to learn js and want to do frontend work. See what happened to those who wanted a "short time to market" solution with angular 1.x. They are in *deep* trouble when they want to keep up with new developments, with lots of logic coupled to angular. Maybe hire a specialist? I would take web ui advisements from stakeholders here with a grain of salt. And of course: watch out for coupling front- and backend.
If separation of BL/UI is antique knowledge then why do people still not go down that route? There is no harm in reiterating it. I know Patrick knows this, but what about Joe Bloggs who comes across this thread through a Google search? We can't assume he/she does.
It's old news for regular posters on here, yes, but what proportion of active developers are active in the community?
/rant
Sometimes a framework does not always allow complete separation of BL and UI ...
That's _NOT_ what I would consider a framework for the 21st century ... but I may be alone with that PoV.
you're absolutely right , that's not what we want also, but frameworks of twenty years ago that are still used today are sadly not transformed in a few seconds ... that's why we had the talk in Antwerp :)
It might be a question of requirements not just the PoV ;)
> That's _NOT_ what I would consider a framework for the 21st century ... but I may be alone with that PoV.
I would not consider an oe backend framework one for the 21st century. But I may be alone with that PoV. :-)
> Which raises the question once more why you waste your time with us.
Rhetorical question from a vendor that is not interested in answers.
@agent_008_nl: you call it library we call it framework. You need some heavy-duty tools to build something big. Supporting Mike's question: Why do you still hang around us if what we choose to use as tool is so bad? Seems to me, that despite your dislike of PSC, you, too, find OE to be about the best "complete" development tool around to get real work done... :P
@Patrick Re: JS skills being rusty - if you can hire a JS specialist you'll save yourself a lot of headache. JS is the ultimate disgrace of human ingenuity - worse than the Trabant and the Hummer! :)
Re: Framework: It is my believe that it is not just important to have a tool that allows building a unit quickly, but also, that provides the means to build many units automatically in a way that they basically work, and where only few have to be customized. Secondly, it is important that changes to the data-model, as well as additional features are easily implemented.
I found Rollbase' idea about UI organization quite nice. Very easy to understand for users, very powerful with all the automatic linking of referenced IDs to actual records pointed to, and flexible for customizations. What Rollbase was missing (aside of simple things like transaction scoping, locking, a decent backend, and decent language to implement business-logic) is a way to build a full application quickly. It is extremely tedious to build all the UI components for all the tables manually - even though the process per unit is quickly, building 400 components for a 100 table DB takes forever and is extremely boring.
However, using their UI organization idea and implementing it in OE seemed a good approach to me. So I did. And you can too (if you want to duplicate the work, or approach it slightly different). It works beautifully, is easy to maintain, enhance, and customize, and is easy for users to learn.
In any case, I can not imagine anybody building a whole application from scratch without such a thing as a framework providing the plumbing plus a way to get components done quickly...
Good luck!
Thomas,
Some reading work on internet can learn you the difference between frameworks an libraries.
I'm a freelancer, not attached to anything, with 20 yrs progress experience. But I have experience with other languages also. I find at least erlang/elixir far far superior to oe for webdevelopment (backend). The appserver is really not such a superior thing if you take the time to take a look at f.e. erlang. The psc world is very narrow to my mind. If you take a dive in f.e. a pure functional language and things like the actor model, task-driven ui (as opposed to crud), the onion architecture, ddd and so much more you could see what I mean. This dive would be necessary tot get an idea what I mean, read wiki.c2.com/.
But it's not easy tot get freelancework with not too much experience. I will disappear from this scene when I get involved in other environments. I've seen oe by now, and I don't find psc products overall very interesting. Lot's of proprietary stuff, vendor lockin all over in products like corticon and oe bpm a least (open standards DMN1.1 / BPMN2.0 compliant? forget it). Not every bpms / rules engine is like that. And don't tell me they are the best anyway. But at least I can still make some money with it while the use of oe is diminishing more and more in Holland.
Regards, Stefan.
Expanding a bit about my remark about the appserver in my last message:
"The Application Server Is The Albatross Around The Neck Of Elasticity
Applications must be architected for elasticity to take advantage of clouds. As more application development professionals realize this, they will begin to see the shortcomings of the existing app-server centric architecture patterns." (go.forrester.com/.../)
For years already there is www.reactivemanifesto.org/
Reactive systems don’t use application servers.
That forrester article was written in 2011 - and the products the author decries are largely still around.
> That forrester article was written in 2011 - and the products the author decries are largely still around.
Yes, my grandpa is still around also.
Awareness of alternatives, better alternatives, does not hurt. ;-) Catweazle had a quiet, easy life also in his cave, till a certain moment...
I have no problem with there being better alternatives - my point back is that all too often perfectly functional technology has been prematurely declared obsolete because there's all these New Shiny Things that are going to take their place.
My point is that it is *not* perfect functional technology. Why not perfect you ask? Please follow the links I sent.
I did - history has already judged the forrester article as being wrong, and the "manifesto" article has all the markings of every other 'bright shiny thing' that's come down the pipe over the years.
History is judging over oe, it has issues. Not small ones. That's my experience. And it's use is diminishing. At least in my area.
That bright shiny thing exists already 30 years with erlang. It's ideas are learned from, see this manifesto and f.e. akka, microservices etc. The world moves on. But Tim sits quietly and trusting, locked-in in his cave.
"You should prefer core-language solutions to small abstractions to small helper libraries to general libraries to frameworks. Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years. Frameworks are at the far end of software complexity spectrum and you want to avoid them as much as possible. You should be fighting complexity and not embracing it. "
And another uncommented quote - leaving us uncertain if Stefan got an opinion on the subject of his own.
Or have you never met developers that prefer to focus on business solutions and not on technological challenges?
Do you really think it's helping to produce future proof business value when every developer in a team needs to invent his own reusable functionality (may it be based on copy and paste, templates, a library or a framework or call it whatsoever)?
Do you really believe mankind has achieved the most when every individual kept reinventing the wheel?
I'm not saying there are no bad frameworks. I know a few.
Us? Speak for yourself Mike. I agree with that article. You're a framework vendor / salesman, "we" ;-) know that by now.
All those hideous higher level languages, lock ins they are, assembler is all you ever need! And who wants operating systems anyway? All they contain is security issues. Assembler has survived everything, look at Dos, Win 3.x and 9x. Look at Forth, Fortran, Cobol,... where are those now? If all our logic is in assembler it'll survive everything, forever.
Now don't take this the wrong way, choose your frameworks wisely, if it's all or nothing it may not be what you want and sometimes wrapping it in some classes so that your own code doesn't use the framework/library directly may be desirable (in fact, it's a good test if the framework allows to be replaced with something else => no lock in, to try to wrap something around it and not expose it directly to your business logic.)
The fact that Mike's framework was designed with .NET GUI in mind, yet quickly allowed adding support for REST, web ui's and lately angular in a very lean way (it doesn't feel like a bolted on hack, but as if it was always there) proves that it doesn't cause the typical vendor lock in that can be seen in some earlier framework attempts.
Every developer should just buy your framework of course.
I'm sure Mike would love that... ;)
Are you saying we shouldn't write reusable code? It certainly sounds like it.
> All those hideous higher level languages, lock ins they are, assembler is all you ever need!
That is not a totally nonsensical remark. You could get userwishes during the time you maintain your application for which the language you use is not a good fit. I had one last month: realtime showing the progress of a running process (billing / invoice) in an openedge application. No, no band-aid with async appservercalls, not all customers have appservers. In another language I'm using this is not a problem (it has no appserver, it has multiple light-weight threads - up to hundreds of thousands, bidirectional communication via websockets easy). And I started building a bpms with a webinterface where soft-realtime communication is used a lot. For that other languages are suited, not openedge. Moreover for special uses cases services can be built in different languages. As you do when you call a C++ lib from oe f.e. Being aware of possibilities in other languages brings some freedom of choice. Tell me a about new enterprises in Holland that used that freedom to start a new application with openedge during the last five years. Also a longtime oe freelancer from Belgium told me last month no new projects start with openedge there .
I'm all in for reusable code and libraries. The advantages above all-in frameworks have been worded by others already (to start with read the link I already sent), moreover: "At Mendix we are pretty reluctant to use all-in frameworks. The first two years they serve you really well. But the third year they cannot longer keep up the pace with new technologies. The fourth year you spent refactoring just be able to adopt new technologies." survivejs.com/.../ or
tom.lokhorst.eu/.../why-libraries-are-better-than-frameworks
Wow, back to the religious war, as a post from Rom today explained it might be better not to stop talking about it (religion) but to embrace that and talk about it in a civil manner :)
>Sometimes it’s kinda hard to differentiate between a ‘components suite’ and a ‘all-in’ framework… the later can simply be just a collection of components that can be interchanged so how that could be any worst than using components from different vendors?
----
Agreed. For me a components suite is different from an all-in framework. I try to build applications as component suites. I look for suitable opensource components and integrate them. When building webinterfaces or serverside logic (elixir / phoenix).
> Stefan is clearly in a disadvantage here
No, this community has the disadvantage as the use of openedge is decreasing. At least in Holland, but I suspect worldwide. I don't care much about being the only one who dares to admit that.
You are very mistaken to think you are the only one admitting it. You are absolutely right. It's the same in the UK. The question is the way you deal with that fact.
One way is to keep bashing away at it, telling people how rubbish it is, etc and criticising those who still use it.
Another way is to work with the community to suggest ways to improve it, and to help those who are using it to use it better.
This is not an exhaustive list by any stretch.
But one of those approaches is a self-fulfilling prophecy. The other might just make a difference. And if it doesn't it'll be a good fun blast getting there. The OE community is the best community I've ever had the pleasure of working with and in.
I don’t think you’re the only one Stefan, most probably the fact that there are only few (if not none) new clients is somehow well known… but, guess what, sometimes the best customers are those that you already have and being a listed company with a somehow large user base puts PSC in position to rather cater for existing customers instead of chasing new ones.
The curious thing about claims that the user base is shrinking is that PSC keeps selling licenses ... lots of them.
But are those sales to existing end users/ISVs, or are they new ISVs?
What does that matter as long as they are new end-user customers?
Let's talk a bit like a CEO (important: of a large company) that I know who has OE apps in his portfolio, to see some causes of the decreasing oe demand.
Requirements for development have changed. Nowadays we have "agile SaaS players", and companies that want to transform in that direction. Legacy and complexity hinders them from growing and innovating faster and capturing more market opportunity and be more effective in delivering against the market and customer expectations. They want a short time to market; continuous delivery, microservices, container tech / serverless etc. make it possible. They want horizontal / vertical scaling possiblities, fault-tolerance, millisecond response times etc. (see f.e. https://www.lightbend.com/blog/reactive-microsystems-the-evolution-of-microservices-at-scale-free-oreilly-report-by-jonas-boner , the pdf you can download there is a great read ). Openedge cannot help much modernizing in this direction.
That ceo is not going to be impressed by the fact that you feel at home here. He has to do with his customers, his competitors etc. He wants to survive with his company. If psc has no good answers then it will simply be: so long psc. We've been good friends for a long time, but ... We are talking about business, not about a nice chat and a cup of tea.
I remember Tom Kincaid (he left psc so no point in mentioning this I find) asking me how to sell oe in the emea region. Strange.
---------------------------------------------------------
You are very mistaken to think you are the only one admitting it. You are absolutely right. It's the same in the UK. The question is the way you deal with that fact.
One way is to keep bashing away at it, telling people how rubbish it is, etc and criticising those who still use it.
Another way is to work with the community to suggest ways to improve it, and to help those who are using it to use it better.
This is not an exhaustive list by any stretch.
But one of those approaches is a self-fulfilling prophecy. The other might just make a difference. And if it doesn't it'll be a good fun blast getting there. The OE community is the best community I've ever had the pleasure of working with and in.
