Artifacts vs Business Results

I am often involved in looking at how people can improve their IT processes e.g. in areas of strategy, architect, governance and service delivery.

Firstly let me say I am fairly familiar with principles underlying OO analysis and design techniques having started using them in the mid 1990s (before UML, and before Java). Naturally when UML emerged as a defacto standard we moved to it; and to RUP which followed soon after. Having overseen many large projects using OO analysis and design techniques I think I have some understanding of what needs to achieved.

Now an apparent digression - Almost 30 years ago when I specialised in CAD and Mapping systems I used to have to explain to Architects, some of whom had been my tutors, the benefits of CAD. They pulled out beautiful water colours and asked if the CAD system could produce them. They had mastered the skills of producing these works of art over lifetime and were justifiably proud of them. At the time the answer was "no". Of course the CAD system could convey the essential information but the way in which conveyed it was different. And of course the cost to produce any ad-hoc view (plans, elevations, details etc.) or deal with changes using the CAD system was far lower. Also the CAD system could be interactively inspected, do counts etc. What these artisans failed to grasp was that what the client wanted as business not a water colour i.e. the business result was the building, the water colour artifacts were incidental.

I now encounter the same issue with people looking at various artifacts related to manual methods of solution design - the classic being the large SAD (seldom if ever read by anyone but the author) or in strategic area some large attractive diagrams manually created with many pretty colours. People seem to think the artifacts (e.g. SAD, Roadmaps etc.) are important per se. In my view they fail to focus on the business results to be achieved e.g. a transformation to be made, or a project delivered and really examine what information is required by whom, when, where and why.

I had a lot of sympathy for those being asked to move from water colours. While they required an experienced practioner and some time produce a result was aesthetically pleasing and communicated very well to many audiences i.e. technical and non-technical (if limited to a specific point of view e.g. plan, perspective, detail, elevation etc.) I have a lot less sympathy with IT people today wasting energy trying to replicate some arcane symbols (e.g. associated with modelling logic, processes, objects or data). These also require experienced practioner and some time produce. The result are neither pleasing nor particularly communicative to average person.