I’ve written some notes trying to understand and explain from a management perspective why service oriented architectures works, as a motivation to understand the Resin 4.0 architecture. To make the ideas concrete, the end of the post shows the bare-bones hello world example for an osgi/web-app service.

While services can improve application organization, they can also improve the programming team coordination. From a management perspective, services organize the application around staffing resources, and organize team communication. Since the PHBs often can’t keep track of the engineering details, services also let engineers explain to management what they’re working on.

Organizationally, services can improve team communication because each service defines a programming boundary between team members. Like a legal contract which defines the requirements and responsibilities between two businesses, a service clarifies the expectations of the service developers and service users. A manager can put both teams in a meeting, let them argue about the service definition, and then let them get back to work, confident that they know how they’ll communicate. A team consisting of Draco, Hermione, Luna and Harry, you could assign a service to each, put them in a room to define their service contracts (APIs), and manage progress based on the service contract. If Harry and Draco start arguing, you can pull out the service contract to resolve the problem and modify it if needed.

(more…)