I would improve the license structure as, for some companies, it may seem a little bit expensive, depending on what they're doing. You have to be pretty smart about how you're using it. If you do a benchmark with operational costs, for big development departments, it's pretty good. However, it depends on how you're doing it. If you're using, if you develop an application such as like ERP applications or core backend applications, there's a lot of forms and more dependencies. If you're doing some, for example, extremely responsive applications for the web, it's not as good. it's better to use it for enterprise IT, enterprise for backend development, or middle and back-office development types of things such as Internal intranet and DMZ-level types of applications with heavy load and security. It's the only enterprise-level solution offered right now on the market, out of the big five, which can be used for advanced development capabilities. It's not for department-level applications. It's just for full-blown enterprise applications. There are some limitations in terms of building business objects, for example, business objects on VBS - basically, in the runtime environment. Right now I know how to access the data, and can use the REST API, and be able to communicate to the backend. However, if these business objects would be on-prem as well that would be ideal. It's not a limitation, it's just kind of good to have.
What is rapid application development? Rapid application development (RAD) is an agile software development approach that was created to replace the “Waterfall” method.
I would improve the license structure as, for some companies, it may seem a little bit expensive, depending on what they're doing. You have to be pretty smart about how you're using it. If you do a benchmark with operational costs, for big development departments, it's pretty good. However, it depends on how you're doing it. If you're using, if you develop an application such as like ERP applications or core backend applications, there's a lot of forms and more dependencies. If you're doing some, for example, extremely responsive applications for the web, it's not as good. it's better to use it for enterprise IT, enterprise for backend development, or middle and back-office development types of things such as Internal intranet and DMZ-level types of applications with heavy load and security. It's the only enterprise-level solution offered right now on the market, out of the big five, which can be used for advanced development capabilities. It's not for department-level applications. It's just for full-blown enterprise applications. There are some limitations in terms of building business objects, for example, business objects on VBS - basically, in the runtime environment. Right now I know how to access the data, and can use the REST API, and be able to communicate to the backend. However, if these business objects would be on-prem as well that would be ideal. It's not a limitation, it's just kind of good to have.