This question is not really specific to SOTI as it is more about Android Management concepts that apply across all EMMs. With that said, I'll try to give you the background and explain the SOTI specific tie-ins.

Early versions of Android were managed by a principal called Device Administrator which SOTI calls Android Plus. DA was great for the dedicated device use case but it had challenges for BYOD scenarios given the amount of power that the DA was granted. There were also challenges with consumers inadvertently granting the DA privilege to random potentially nefarious apps in the Play Store. 

Google then introduced a new concept for Android management called Android For Work (AFW) with Android L but it really didn't become mandatory as part of Android until Android M and beyond. AFW was eventually rebranded to Android Enterprise (AE), but you will still see references to AFW (eg. afw#mobicontrol) and the terms are still used somewhat interchangeably.

One of the core differentiators of AFW/AE over legacy Device Administrator is the ability to have different types of management to better suit the different use cases. DA only really offered comprehensive control over the device which was often seen as too intrusive in BYOD environments. AE on the other hand offers Device Owner / Work Managed/ Fully Managed, which is more akin to Device Administrator in addition to concepts like Profile Owner/ Work Profile that are better suited to BYOD and other scenarios. Rather than taking over full control of a device, an EMM can use AE to inflate a Work Profile and just manage the contents contained therein. 

This new distinction was a big win for corporate EMM environments with a lot of BYOD Android devices under management but it actually has been somewhat painful for the rugged device space that was already pretty well satisfied with the Device Administrator management scenario. SOTI has a heritage in managing rugged class, dedicated devices, and if that happens to be your space you may find Android Enterprise quite frustrating relative to the way that it used to be. But if you learn the history and understand the direction that Google is taking it then it will make a lot more sense to you why it has to be this way. Android Enterprise is also somewhat of a great equalizer between EMMs. Before AE each EMM provider kind of had their own way of doing things and so there was a mixed bag of capabilities on the market.This is why it is important that you learn the fundamentals of AE before then trying to apply those concepts to see how a specific EMM vendor like SOTI implemented them. Understanding what is generic to AE versus specific to an EMM will help you tremendously in the long run. Don't try to learn SOTI first and then AE second, do it the other way around. 

Another fundamental change to be aware of with Android Enterprise is that the enrollment method is incredibly important for dictating what management state that the device will end up in. Device Administrator had vulnerabilities in that consumers were unsuspectingly enabling it on their personal phones and also DA allowed for multiple DAs to be active at a time. Android Enterprise "solves" this problem by only allowing for one Device Owner (DO), and by requiring that DO to be activated from a Factory Default state. This means that the device needs to be enrolled under AEDO management fresh out of the box via a method like the DPC identifier (afw#mobicontrol), otherwise it will end up in a Work Profile (BYOD) management scenario that is built for different purposes. This means that you cannot take an Android device, download the SOTI agent manually from the Play Store, or sideload it, and then try to enroll into a SOTI server like you may have been able to with DA. Doing so will ALWAYS put the device into a Work Profile (BYOD) state. If AEDO is your desired management principal, which is likely if SOTI is your EMM of choice given the heritage there, then you must use one of the enrollment methods that produces that result. NFC, QR Code, DPC Identifier, and ZTE are the four core AE methods for DO enrollment. There are also some manufacturer specific options like StageNow for Zebra and Enterprise Provisioner for Honeywell that can streamline the process. If you don't follow one of the native AE or manufacturer provided mechanisms however then you will end up with a Work Profile device instead of a Work Managed device. Keep that in mind as I have seen a lot of confusion surrounding this concept and frustrations when someone accidentally enrolls as Work Profile and then can't manage the device as comprehensively as they would want. 

Over time Google has added more and more capability into AFW/AE while simultaneously deprecating functionality of DA. DA support eventually falls off in the latest versions of Android, so AE is an inevitability. 

Depending on the version of Android that your device is running, it may support both management concepts. DA deprecation has been on the horizon for many years now as Google has given us plenty of runway to migrate devices from DA to DO. Somewhat frustratingly SOTI & Zebra forced this migration to happen a little prematurely as they drew a line in the sand at Android 8.1 (Oreo) and only supported AE on those OS versions and beyond. This was a frustrating premature encounter with AEDO as the DA management API was still technically part of the Android OS, SOTI and Zebra together however did not make it accessible via a compatible agent so we were forced down the path of AE early using this combination. This was an interesting development as you could technically keep using DA on the same exact devices in other EMMs and could even use DA on other Android 8.1 devices from other manufacturers in SOTI.

To address your specific question, if your devices are running a minimum version of Android M then they support Android Enterprise. The specific set of AE management capabilities will vary based on the version as those capabilities are getting better over time. For example, the native AE Kiosk functionality has more configurability in later versions of Android (9+). 

If your devices are running Android M, N, or even O depending on the manufacturer (not Zebra!) then they kind of sit on the transition period between DA and DO and you can use either of the two management principals. With that said, if the devices will eventually be upgraded to a later version of Android that does not support DA then you will be much better off preemptively moving them to the AE management strategy so that they can stay under management through that future upgrade. If you otherwise were to manage a device under DA and it later got upgraded to say Android 11, then it would fall out of management and would have to be factory reset and then re-enrolled and completely reconfigured under AE. What a mess that would be. Bite the bullet and move to AE as soon as possible.

Here is a comparison of several common Zebra Android devices and where they fall on the AE spectrum for SOTI specifically that I have put together for reference.

There are other features of AE that I didn't specifically cover here like Managed Play app distribution, OEMConfig, Managed Configurations, etc, I recommend you continue your research on the topic. Jason Bayton's Blog is a tremendous resource for this kind of information: 

https://bayton.org/docs/enterprise-mobility/android/what-is-android-enterprise-and-why-is-it-used/

Google's official documentation on the subject. Remember that this is Google forcing this migration to AE and not the EMM providers. SOTI forced it a little early for Zebra devices specifically, but in general the inevitable migration to AE and deprecation of DA is Google's doing. 

https://developers.google.com/android/work/device-admin-deprecation

Hi Matt

I am very happy to receive a quite detailed answer from you. It helps me to increase my knowledge of Android Enterprise.
However, I have one question, how can I tell if a device can activate DO, except that the device can enter the DPC identifier "afw#mobicontrol" from a Factory Default state. I think Android 7.0(both phone and tablet) and above devices can all activate DO, is that correct?

Not all Android 7.x devices are compliant to Google's specifications for supporting Android Enterprise.  Also, some advanced AE features offered by Soti MobiControl are only available if corresponding OEM-specific Android-Enterprise plug-in is available and deployed onto the device.

Your mentioned site at "https://androidenterprisepartners.withgoogle.com/devices/" is a good place to check for compliant Android Enterprise Recommended (AER) devices.    Another good reference site is https://www.android.com/enterprise/device-catalog/.  However, do NOT assume any such site can always provide the most up-to-date list, nor should you assume the information there is 100% accurate.    Also,  each entry is associated with particular firmware version(s) tested, which may have minor variations for devices sold in different countries.    To be absolutely sure a particular device can be enrolled and function with required AE features,  the best way is to borrow a sample device to perform thorough tests before making purchase decision. This is recommended especially if a big purchase of large number of new devices is to be made.  

Hi Matt,
Thanks a lot for the detailed write up regarding the AE & AP, now gets more clarity on it. 
Now i am reviewing my devices enrollment mode based on the info you provided. 
In one above picture, you mentioned that for Android Pie and 2019, we have only AE and DA API marked as depreciated. 

But in my environment, i can see Honeywell CT60 devices running on Android 9.0 enrolled using OEM specific agent(not using afw#) from SOTI website and having lockdown mode enabled. When i look in the web console, it shows "Device Kind" & "Device Family" as Android Plus. It means it is not enrolled as AE, but DA, right ?.  How it works for Android 9.0 ?.  

Note: We use the OS upgrade given by Honeywell for upgrading the devices to 9.0 

Hi Raymond,
When i checked in those websites, i found that some of my devices that are running on Android 6,7, 8 are not lsited there. So does it mean that those devices should be enrolled as AP by using OEM specific agent to fully manage ? 
What if those devices gets upgraded to Android 9.0 or later ?. then we have to use AE even if the devices are not AE recommended by google ?

In one above picture, you mentioned that for Android Pie and 2019, we have only AE and DA API marked as depreciated. 

But in my environment, i can see Honeywell CT60 devices running on Android 9.0 enrolled using OEM specific agent(not using afw#) from SOTI website and having lockdown mode enabled. When i look in the web console, it shows "Device Kind" & "Device Family" as Android Plus. It means it is not enrolled as AE, but DA, right ?.  How it works for Android 9.0 ?.  

Note: We use the OS upgrade given by Honeywell for upgrading the devices to 9.0 

The DA API was marked for deprecation, and some of its features were removed, but its not removed completely in Android 9.0. This is covered in detail at the link I previously provided. Google has given a ton of runway (5 versions of Android) for IT admins to migrate their management strategy from DA to AE and now we're basically at the day of reckoning. You could run your Honeywell devices on 9.0 with DA forever if you want but if you want to eventually upgrade them to 10 and beyond you may be in trouble. 

https://developers.google.com/android/work/device-admin-deprecation