Summary
Techniques for managing projects and designing applications.
...
A successful service provider is one that encapsulates as much as possible to keep applications focused on the user experience. Service providers are much more than persistence. However, our customer-focused development processes often has a product owner conversing directly with a user interface programmer who helpfully solves a customer's problem outside the service environment. Too much of this makes the application investment a one-off special case that cannot be adapted to the needs of others without branching the code.
Uninteroperable Pseudo Services
Development of APIs above the service layer always seems like a good idea to mitigate the apparent complexity of the service environment, encapsulate business logic, improve overall performance, and to build "screens" quickly. This is a debated area but here are some observations:
- They are often training wheels: The first screen is built quickly from an application-oriented API, then the screen continues down a development path where the API begins to mimic the service capabailities without the interoperability considerations.
- Fixed mindsets: When an application depends an a number of services and capabilities, wrapping the orchestration in a single API creates an all-or-nothing proposition. This will vary a dynamic service environment where we'd like to see the application react to the service capabilities it has access to at any point in time rather than always toss its cookies when one thing isn't available.
- Poor user experiences: Service-related performance issues more often than not stem from interacting with too many services at once to bring together a bunch of indirectly related information. A higher level API could be used to orchestrate all this data into a single call from an application. However, users do not often use all this information and it throws up a lot of complexity in their faces all at once. Break this down into more user-friendly chunks and fewer calls will be required reducing the need to orchestrate above the service layer. Improve the user experience by reacting the users actions and get things when needed. Design the mobile application first!
- Too many agreements: The art in designing for interoperability is to reduce the number of agreements between a service consumer and a service provider. Too many agreements (e.g. too many Types in play) increases the need to encapsulate in a higher level API and reduces interoperability.