The “As a…” clause of the classic user story is easily forgotten. To build a feature, we must know what it is and why someone
would want it, but as developers we often abstract away the user. Building “the simplest thing that can possibly work” is usually a critical design tool, but without active attention to customer roles and workflows, it can lead to APIs that leak the implementation details of underlying technology or prioritize machine logic over human understanding.
We will use the Unified Job Interface Map feature in the OpenStack Data processing service (sahara)’s Liberty release as a case study in role-aware API design. In addition to demonstrating how this feature can improve communication between data processing developers and cluster operations engineers in your organization, we will examine:
- Why APIs in the OSS infrastructure and tools space are bound to leak implementation details at some level.
- Why the ideal of an API flow that is intuitive to any user from any entry point is likely a fool’s errand.
- Why multi-role customer flows mean that the “simplest thing that can possibly work” usually doesn't at handoff points between users.
- How domain-specific awareness of user roles allows smart choices about where to go ahead and leak implementation details and where to build a dam.
- How features to facilitate inter-role communication can quite often be built iteratively, on top of existing APIs.
Data processing users will leave this session with details on a powerful model for easing communication between development and operations in Sahara. OpenStack contributors will leave this session with a refreshed perspective on the importance of understanding not only the use case, or even “the user”, but the many roles within an OpenStack customer organization.