Service Oriented Methodology

In 1998, a few of us at Momentum (James Higginbotham, Mark Spitzer, Ed French) wrote a software development method that we called Reality(tm). The method borrowed from best practices of Booch, Rumbaugh, Jacobson, Coad-Yourdan and Schaler-Mellor. Later we incorporated UML and concepts from Extreme Programming. We also threw in platform specific (Java & .Net) best practice guides and reference architectures. The Reality method has served us on over 100 engagements. I'll admit that we haven't always follow it to the letter of the law, but the intent seems to find its way into all of the projects.

However, at the heart of Reality is an "object oriented" development cycle. We were so heavily influenced by the "object people" that many of the mandatory artifacts and diagrams are OO in nature. Anyone that remotely knows me, knows that for the last half-decade I've been exclusively focused on service oriented computing. And for the last half-decade I've been waiting for a "service oriented" method.

Well - we decided to bite the bullet and start knocking one out. We are currently calling the skunk-works project "Awesome!(tm)" (Advanced Web Service Oriented Method) but my marketing team is telling me, "the name has got to go". I'm open.

The Awesome! method revisits a handful of concepts:
- Service centric diagrams & modeling notation
- Service centric artifacts
- Service network artifacts
- "contract first" development lifecycle
- Service level agreements as a first order concept
- Business process 'binds' to service networks

We also have started a repository of best practices - however these seem to have a half-life of about 10 months.

In 2005, we expect a half dozen SO-methods to come out - we know, this isn't exactly a new concept. As others come out, we plan on learning and upgrading our own. We figure it will take about 3 or 4 years before the SO-Methods come together with a set of base features and common notation. We also believe that people will want more than the "Microsoft Method" - and that choice is good.

Unlike our Reality method, Awesome! will be made publicly available. We aren't quite ready to share it with the public yet but are eliciting ideas on what people want in an SO-Method (email me). After the straw-man is together, we'll drop it out for public review and begin the upgrade cycle. Let me know if you have an interest in being an active contributor.

Methods are repeatable processes. They enable companies to reduce risk around projects and to leverage resources by assigning them to well-defined tasks. As service oriented styles move into the enterprise, the use of SO-Methods to complement your existing methods (RUP/UML, etc.) will be common. We need to move SO from an art to a science (or at least a craft) - and soon.