Why Ultimate  / for developers

In particular, the  rich data model means that you can develop an application by formulating it as  a unified whole in the directory terms or in the terms of documents. The directory  of goods is all-in-one: the data in the database, the forms for the list of  goods, the option of the individual record editing, the right to access it, and  so on.
Just compare it with  the SAP or Axapta data model – we have separate data conversion objects, separate tables with the data, separate authority rights and their  verification. There is a million of variants of how to present a standard list  of goods, and one must remember how to implement the same task in different  places.
When working with  a rich data model, it is always clear where and how to implement the directory. Certainly, you can still operate on the model used by the older fellows –   “if Monsieur knows his perversions”.

LINQ allows to  formulate the complex queries to the business objects. The language and its  compiler are actively developing.
The client application uses asynchronous extensions of the C# language, consequently increasing the user-friendliness.
The platform facilitates the development of asynchronous applications, automatically  generating the asynchronous wrappers to call the methods of the application  server, and notifying the developer of synchronous queries.
SAP uses the ABAP – the procedural language with OOP-elements. There are neither the functional  extensions, nor the asynchronicity support. The situation in 1C is absolutely  the same.
Things are slightly  better in Axapta – but only because there is something you can do in C# over  there.
The situation with the in-built X ++ Axapta language is the same – the procedural language with the OOP extensions.

The competitors use  the DBMS as a notebook.
An easy-to-imagine  comparison: some old ladies use the iPhone, given to them by their grandsons, to record phone numbers, but they would still call to their old companions  using a bakelite phone of a stone age era.
1C, SAP and Axapta  DO NOT use the basic features of any modern DBMS as triggers or stored  procedures. As they say, it is unbelievable-but true.
It is more than that.
Even the referential integrity is checked by the application itself, and not by the database although the latter can do it much better (like a disposable lighter is way  better fit for making fire than a tinder and a flint). Naturally, this approach makes it not just but incredibly easy to write a code that will destroy the  referential integrity (not EVEN mentioning the performance of the system) – which is why this happens with surprising regularity.
Actually, this is the example of how to remove tonsils via a colorectal maneuver; this is the  essence of the typical hereditary vestiges left from those prehistoric times, when the ancestors of our today's competitors were working with the equally squalid rudimental databases, or, like 1C – with the DBF files.

For each object the platform independently generates the necessary queries to create a database object. The system will prompt the options for the object creation, suitable for different cases of use – when the access is frequent, or when it is necessary  to record changes and other things.
Compare it with the SAP approach: it simply knows how to get back the rows of a table and save the back – even the access checks are on the application developer.
Axapta “boasts” the same situation, with a few exceptions.

SAP, Axapta and 1C use manual transaction control. That said, it is possible to  write a program that will save the object only partially. Such instances  regularly occur in actual practice.
For  example, there used to exist a certain Foo function that performed certain  actions and did the “commit” action at the end.
Then  it was decided to use this function from another function named Bar (so as not
to duplicate functionality). So, if an exception occurs in Bar after a Foo call, then the part of the actual work of the Bar function (what was done in Foo)  will remain in the database, and the rest will be "rolled back. "
The  result will be the data integrity loss.
To  discover the source of the awry data appearance is often a task of incredible  complexity. The sources can hide themselves for months, mysteriously floating around  guided by the moon phases, i. e. just existing in the form of the "slightly  incorrect data in the reports. "
Or not  that slightly.
And  they have to be edited after the discovery. This editing usually will be done
manually: one can only blanche at the sight of those hundreds, thousands and
millions of documents.

Immediately after the object is created by a developer, the platform will automatically generate  a form for the list of the objects’ records (with all the tools for the data sampling, the selection of columns, sorting, buttons for creating and deleting records, etc. ) and the record edit form (which, of course, will open from the list of records by double-clicking).
And you can immediately start describing the business logic and further stages.
The development of the complex screen forms can be done in parallel with adding the business logic content – by different developers.
None of our distinguished colleagues on the market does offer ready forms to the developers — they have to use their hands everywhere. The fastest way to do it with the editors’ help is by using Axapta and 1C (it doesn’t take long to distribute the component on the form, but it needs to be done, and it will take 15 minutes to create a most simple  directory), but the most fun happens, traditionally, in SAP: one must still write  a program there — to prepare the data, convey it into a grid, draw a shape, and  do other monkey business.

Ultimate Solid uses a distributed version control model — each developer makes changes in its branch (the analogue of a working copy or a local repository in other version control systems), and, upon the work completion, introduces the changes to the main branch (and periodically "tightens" the changes introduces by other developers).
A close model of work is implemented by Mercurial, Git, and a number of other industrial version control systems.
The application server can work with any of the selected versions (on any branch), whereby the end users can access the functionality by very small portions and with a high frequency of updates. Thus, the notorious continuous delivery — is the organic (and the main) development methodology for Ultimate Solid.
Let's see what the colleagues offer.
SAP, 1C and Axapta DO NOT have a version control system – in the sense that you can run the application server on the specified version. Axapta offers the possibility to upload/download a configuration, but it has about the same relation to the full-fledged version control as a barge with some field guns to a battleship.
This is naturally followed by the failure to make any development using a production system – in the absence of a version control system it becomes necessary to have at least 2 separate databases – the development and production systems. The always creative SAP PR specialists named this graceless curiosity a “three-mandate system landscape. " It is inspiring, that’s right! And, at the same time, we don’t have a damn clue. Just the thing for a naked king.
At the same time more or less flexible and reliable tools for the changes’ transportation are implemented only by SAP (one of those rare cases where the creation of the [excessively] gloomy Teutonic genius is somewhat ahead of its competitors).
Axapta ignores the need to transfer not only the data structure and the application code, but also the application data. Transfer with your hands, my dear comrades. The obvious consequence – the developers regularly forget to transfer, and transfer only when the users claim the errors. The similar situation is at 1C.
SAP supports the transfer of the application data, but (as usual)... If the "combat" system has a table containing, let’s say, four billion entries, the straight adding a mandatory field to this table will make almost any database experience a hang-up. Almost any administrator of a not-too-ancient DBMS knows how this can be done in several stages and without any problems for the users. However, SAP doesn’t know how to do that.

SAP and Axapta use  labeled files to solve a similar problem. Any text can be replaced by a label, and then the label can be transferred and used in the hand-manufactured forms.
Ultima  Businessware makes sure that the automatically generated forms of directories, documents and reports use the translated names directly, so the developer does  not need to get sick of using those labels.

What do our colleagues offer?
1C —   an integrated form editor with a limited set of components.
Axapta —   an integrated form editor with a limited set of components. A form can be drawn in the VisualStudio, too. However, due to the amount of the ridiculous restrictions imposed by Axapta, its use is actually impossible.
SAP – an integrated form editor with... you guessed it. There is a variant with using the SAP Portal, where you can draw in HTML, but such development s are scarce.
In all the cases the developer has to use a set of limited 20-30 components and has no access to any sophisticated components that are in the DevExpress and other modern libraries.

A developer does not need to know any details about the implementation of these protocols; it is sufficient to describe the functions to receive and return the corresponding objects in the DTO (Data transfer objects) graphical interface and to implement them in C#.  
The rest will be done by the platform.  
1C and Axapta implement the subject (Axapta – SOAP only) through the use of the enjoying the well deserved love of people  MS Internet Information Server. SAP has a separate specially trained component for this, and to understand the administration of this component will bring the same headache as the desire to get to the core of any other thing in SAP.

When developing the mobile applications, the proprietary (as opposed to the universal SOAP / REST) protocol of the interaction with the application server has a number of advantages – encryption, compression and binary serialization are used.  
Axapta makes you simply use the web services. This is inconvenient: the web services in Axapta are heavy, and there is no support for the development.
SAP SUDDENLY presented a platform for the development created by Sybase. Apparently, the rights for the free inherited junk that SAP got after buying the decaying Sybase zombie made the company just give something unworthy to its clients. However, that platform also suggests using the native development tools and communicating via web services.
The platform for the development on the target device was detected neither here, nor there. The comrades from 1C heroically ported  their own development environment  both on Apple and Android. We did not go too deep in the details, to be honest, but because of the way the this environment is constructed (which, apparently, is the consequence of the orientation at the qualification of a typical 1C programmer, the 1C mobile application interface for iOS will be similar to the 1C program, and not to the program for Apple devices. The same is true for Android.