Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

Service Design To The Rescue

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 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.

Agile OSIDs

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 not wander into areas not valued by your project.

...