Summary
Design methodologies do not imply a waterfall-based development methodology. A Service Design Methodology can compliment an Agile approach.
| Table of Contents |
|---|
Agile Requires Planning
The Agile vs. Waterfall debate is often framed as an argument of extremes. People experienced in a variety of development methodologies understand that a tuned process is more nuanced than the this vs. that blog entries described.
...
Upfront planning is essential but the trick is to know what needs to be determined, how much detail needs to be known, and making sure that the plans evolve in response to experience gained from successive iterations. Mistakes will be made. It's better to make them fast and adjust than to follow out a predetermined plan through to absolute failure.
Solid Architectural Principles Rise Above Development Methodologies
Some architects oppose agile-based methodologies. These tend to be the architects who are more design oriented who distrust an iterative and/or distributed development environment without solid well-thought out blueprints to follow. Again, the issue is how much needs to be determined on the blueprint and what can be deferred to iterative cycles where experience and re-prioritzations dominate.
...
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.
Agile OSIDs
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 not wander into areas not needed valued by the your 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. Like development methodologies, the concept of interoperability is a bit more nuanced than yes/no.
...