In the 1980s, I started working on information systems methodologies. I joined a BCS Working Group and started writing articles for a journal called Data Processing (which subsequently changed its name to Information and Software Technology). In 1986 I joined James Martin Associates (JMA).
My colleagues and I took part in several IFIP conferences including WG 8.1, WG 8.2 and WG 9.1, and I was a founder member and sometime committee member of WG 8.6.
Although the methodology debate has moved on, I believe many of the general principles I asserted at the time remain valid, so I thought it might be worth posting a few extracts here. These and other articles can be found on Academia and/or ResearchGate.
What are Methodologies Good For? (July 1985)
Around that time, there was a lot of attention to the question of
comparing methodologies, from both practitioners and academics. This paper describes a methodology as an abstract system, and identified criteria for evaluating and comparing methodologies. Among other things, I concluded that those developing and promoting methodologies for building systems often failed to apply their own systems principles to the methodologies themselves.
Methods of Maintenance (November 1985)
Most of the methodologies we were looking at in the 1980s were focused on building new systems - so called greenfield development. This article argued that these methodologies also needed to find a way to support systems maintenance, given that this was where most of the IT budgets were consumed, even if this meant a more piecemeal approach.
However, it wasn't until Christopher Alexander published his New Theory of Urban Design in 1987 that I started to understand some of the deeper arguments in favour of a more organic approach to systems. See my post on SOA and Holism (January 2009), which contains links to some of my more recent material.
Future of Information Systems Design Methodologies (February 1987)
This paper talks about how methodologies are developed, and how they must be adapted to accommodate changing technological state-of-the-art.
However, although the methodology should be technology-independent, this does not mean that it can stay unchanged while technology progresses around it. To be truly independent means keeping all options open, which means that the methodologists, if not the methodology users, must know what all the options are. This will be an active and continuous challenge for the methodology vendors. If they do not take the challenge seriously, their methodologies will develop distortion and bias, perhaps even steering designers towards those technical solutions that were fashionable when the methodology was first developed, and discriminating against newer and better technologies. A methodology works by simplifying the decisions that a designer has to make, but continual effort must be made to ensure that these simplifications remain valid.
More recently, I have referred to these simplifications as enabling prejudices. See for example my post From Sedimented Principles to Enabling Prejudices (March 2013)
I have also talked more generally about methodologies as representing a body of knowledge. See for example, Evolving the Enterprise Architecture Body of Knowledge (October 2012)
Demanding Higher Productivity - Remember the Human Factor (September 1986)
Implementing a Methodology (November 1987)
As a consultant working for JMA, I was faced with the challenge of getting large client organizations to adopt our methodology. While some people saw this primarily as a technical challenge (installing tools, etc.), I argued that the real challenges were more to do with people and organizations. I saw project managers whose position and power were challenged by new methods, and who had good reasons to resist our attempts to deliver higher productivity.
This led me to devote a lot of attention to questions of technology adoption - hence my involvement in IFIP WG 8.6. I developed a technology change management roadmap, which JMA (and later Texas Instruments) used for planning the adoption of its methodology and technology into some of its larger customers. Some years later at CBDI we developed an SOA Roadmap, along similar lines, in order to help large customers adopt and exploit SOA.
See also Understanding Technology (August 2009)
No comments:
Post a Comment