Another Methodology?

This week in the UK we are running our first SOA Success Methodology workshop.  A somewhat grand name for some pointers on how to go about building a service oriented architecture.  Last week we had a train the trainer session with some bright guys from the US who came over to the UK to help get us up to speed on the content (thanks Mohamad). 

I like to think that a good methodology provides several things

• A repeatable way of working (key to gaining consistent results)




• A methodology is a "method of working" or a way of doing things that is repeated.


• A useful process for lifecycle managment




• A methodology provides guidance on what to focus during each stage of the cycle, providing a temporal guide on what to do next.


• Useful tools for use in the lifecycle.




• Artifacts produced by following the methodology should have value in their own right.  The corollary to this is that artifacts may be useful outside of the strict methodology outlines.

I guess the first two points are Methodology benefits with a big M (think of PRINCE or Extreme Programming), whilst the third point is more about methodology with a small m (think of Use Case analysis or CRC cards)

Obviously the SOA Success Methodology is geared around tools, techniques and processes to let you build large scale SOA architectures.  The principles can apply at the enterprise or the departmental level, although there are some subtle differences between the two.

The one day workshop is only a taster, it is cut down from a two day introductory course that can lead on to a longer engagement.  If you are in the UK why not register for a workshop, come along, participate and give us feedback.