Summary

Techniques for managing projects and designing applications.

Case Studies

• The Case of the Picky Org Pick Lists

Themes

Application Uninteroperability

The traditional view of a service provider is that it manages persistence and everything else must be handled in an application. This often includes business logic. 

The goal of service design is to ease the pain in swapping either the application or implementation. If too many assumptions such as business logic and configuration get intertwined in the application or implementation code, this becomes impossible.

The kinds of things that should be factored out of the application code to promote interoperability include:

• rules: this takes the form of keying off of data values, filtering data, or transforming data
• side effects: the application invokes a service in response to some event in another service
• authorizations: the application performs its own authorizations 
• validations: the application maintains its own metadata outside the service about service managed data

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.