Soft System Methods - A Critique

Here is a paper I completed on Soft Systems Methods. This was another Master's study unit that I really enjoyed as it covered aspects of modelling that is typically found in Management units.

http://www.chriskempster.com/data/Soft%20Systems%20Critique%20v7.doc

The paper covers three methods:
1) Soft Systems Methodology (SSM);
2) Strategic Options Development Analysis (SODA); and
3) Socio-Technical Analysis (STA).

I have applied each method to a small case study of which you will get a gist of in the paper. If you would like a copy of the case study then please email me (ckempste@iinet.net.au).

Each method observation includes industry and academic views to support or negate the author’s perceptions, and assist in the location of patterns in which to summarise each methods critique.

The analysis will also build the readers perception of the picture shown in the diagram below, suggesting that any sufficiently complex requirement will require the adoption of a multiple methods.

Agile Architectual Modelling

Scott W.Ambler is an interesting cowboy hat-wearing architect that has penned a large number of books covering application development agility, including agile modelling:

http://www.agilemodeling.com/essays/agileArchitecture.htm

Scott is the founder of Agile Unified Process (AUP), an interesting and pragmatic look at RUP and well worth the read if you are considering agile development processes/frameworks. I also recommend his Yahoo Groups page / email list which Scott actively partakes in (rather than other lackey)...

http://groups.yahoo.com/group/agileUP/

Technical Infrastructure Design Patterns

Hi there. I have long been an advocate of infrastructure patterns (or blueprints). They have been around for a while and covered by a range of well known authors, but funny enough I struggle to find technical architects that talk to them, both technically and with the client.

The infrastructure blueprints provide the high level implementation framework for a solution on which vendor software is applied [and the patterns possibly altered]. The framework can state minimums across application service tiers, i.e. a class one application may using pattern X and storage pattern Y in order to achieve the required availability; and form the basis of enterprise standards on which specific vendor software platforms (further standards) apply.

The patterns can also provide a road map for change, allowing complex technical implementations to be boxed as logical concepts whose change over time can be articulated with the business and their respective clients. As with any change, infrastructure and software pattern changes also drives capability maturity - the possible need to invest in skills to sustain the stability and benefits of the pattern in production.

The presentation is a little rushed; but not too disorganised :) comments welcome.

http://www.chriskempster.com/data/Technical%20Infrastructure%20Patterns.ppt

Observer Pattern - An Introduction

Here is a presentation covering the Observer GOF pattern I did some time ago.

http://www.chriskempster.com/data/Observer v3.ppt

SOA Anti-patterns

I completed a Master's study unit around 6 months ago on Design Patterns; this unit was particularly interesting in the fact that you could pick any topic you liked and research/analyse/deliver it depending on the learning experience you wanted to achieve. Of interest to me was the "dark side" of service orientated architecture, namely anti-patterns.

Rather than simply list a range of identified anti-patterns, the later part of the presentation asks the question - "are there patterns within the anti-patterns" ? the resounding answer is yes! with due planning and management you can not only sell the risks to management, but plan supporting policies and governance models to manage them.

Presentation can be found here http://www.chriskempster.com/data/Service Orientated Architecture (SOA) Patterns v2.ppt

Comments welcome.