...
Large-scale projects are making more use of teams working in parallel to each other. One enterprise architect noted, "five teams iteratively developing five products in parallel." This argues for some blueprint from which to work.
Service -based development methodologies Design Methodologies such as the OSIDs provide some relief to this dilemma.
- Service Design Methodology favors separation along service boundaries. Services define such boundaries as interfaces and as such provide a natural breakdown that can be developed in smaller chunks.
- As technological choices such as application frameworks, ORMs, rules engines, identity management, etc. changes through the course of a project, changes can be prioritized and implemented on a service by service basis. Change gets a lot less scary when an entire project doesn't need to be redone all at once.
- If the impacted service providers are determined on a feature by feature basis, these boundaries can be used as collision avoidance ina distributed development environment.
However, service contract changes can have significant impact on a project. It is important not to jiggle service contracts on an incremental basis and rely on service contracts as the stable point in a system.
Service contracts need to evolve much more slowly which means they need to incorporate much more than is called for and there's a reasonable level of confidence that they will hold up. OSIDs are an out-of-the-box suite of service contracts where many interoperability issues have already been incorporated into its design. OSIDs provide a solid blueprint for how to approach a development project and do so incrementally.
If OSIDs define more functionality and interoperability than most of us need, how do we not spend resources developing unimportant stuff? OSIDs are broken down into small clusters of compliance (OsidSessions) that can be broken off and implemented one piece at a time. It usually requires a guiding hand to make sure that developers don't wander into areas not needed by the project.
How can OSIDs possibly define everything I need? It doesn't. OSIDs define the integration issues around many service domains along with some common data in these service domains. All of the "objects" are extensible in such a way that methods and data may be added outside its core specification. There's plenty of room to add your own stuff and have interoperability through the core specifications.