Do you ever have the feeling that you are missing something obvious?

The present

It seems to me that the current orthodoxy is that an OData service should be developed for each UI5 app.  In other words, each app should only have to call one service.  I think we should question whether that is the best approach.

Of course, a UI5 app can use many OData models, so long as each one has a unique name within the app.

In my opinion, when developing OData services (e.g. using Netweaver Gateway or HCI OData Provisioning), we should think of the big picture.  We shouldn't be too focused on the bespoke Fiori-style app we happen to be developing that day.  In a few years time we may have a large number of Fiori apps, both standard and bespoke.  There may be many other consumers of our OData services both internal (e.g. our own company website or intranet) and external (e.g. customer or supplier systems).

Why not take an 'API' approach, and think of our OData services as a way of interacting with the entities in our back end system?  Why not organise the services in such a way as to make it easy to navigate for any UI developer working with any technology? For example we could have a service for customers, one for inventory and one for employees. It seems to me that this would be much more in line with the RESTful architecture.  Just because we are using an SAP technology, such as Gateway, to deliver our services, it doesn't mean we should only consider SAP UI-technologies as consumers.  A big plus of the modern web-architecture is that the UI-layer is completely de-coupled from the data-provider and I think we should take advantage of that.

The future

If we (SAP and customers) carry on developing new services at a rapid rate, within a few years I fear we will have a large number of overlapping services.  It will be so hard to find one to use that developers will simply create another brand new service rather than trying to sort through that long list.  There will be much duplication of logic.

Each published service represents a responsibility (does it work as it should?) and a vulnerability (could it facilitate malicious activity?).  This isn't new (the same can be said for a remote-enabled function module) but surely a very large number of services makes it harder to manage these risks.

Pros & Cons

This is my take on the pros and cons of the one-service-per app model:

• Robust, as development of a service for app #2 does not affect app #1.  This helps us get an app live very quickly, and may fit in better with an agile methodology(?).  This appeals to those who found the ESOA (Enterprise Service-Orientated Architecture) approach difficult to manage in practice
• Re-usability can be introduced via 'Concrete classes', as described by Leigh Mason hereMaking your SAP Gateway work smarter not harderand also Service Inclusion
• Data provider classes are quite small and manageable as there are only a few entities in each service
• The service can be optimised for the app.  However, this can probably be achieved in a generic service by using features such as $select to specify the fields required.  Also, there is nothing to say that the 'customer' service must only have one, generic 'customer' entity
• An external 'API' productcould perhaps be used to unify and present the services provided by Gateway (and other OData providers too)
  
• Will lead in time to a large number of overlapping services.  It will be hard for a UI-developer to find what they need
• Likely there will be a lot of duplication of logic (across services), leading to greater effort and reduced maintainability.  How many times will an employee entity be required, for example, in order to provide employee names?
• Services are designed for individual apps on one particular platform (UI5/Fiori) and might not be suitable for future apps or other UI platforms

What do you think?  What do you do?

So, is there an obvious point that I am missing?  Are there advantages of the one-service-per-app approach that I have missed?  Am I wrong to call one-service-per-app the orthodoxy?

What is the strategy in your organisation (or at your clients) for OData services? I look forward to your comments.