Jan 25 2008
Non-Technologists Don’t Think in Models
I find the concept of model-driven architecture very interesting as a way of improving the software development process. However, technologists push the concept of models beyond their useful limits when they attempt to use them as a communication tool to non-technical people.
“But I’m drawing pictures, shouldn’t that be easier to understand?!?!”
Yes, pictures communicate better than words, but the key here is that most people think in terms of “experiences” and not in terms of “models.” It’s like the Apple ad:
Mac: “It’d be kinda hard to capture a family vacation with a pie chart…”
PC: “Not true! For example, this light grey area could represent hang-out time.”
Visualization of an intended experience is far more effective in communicating a proposed software solution to most people than the visualization of an abstract representation of that solution. And yet, it seems as if the major thought leaders in software development are constantly trying to come up with new and better forms of abstract representation with the express purpose of communicating with the non-technical.
I can understand the appeal here. Models communicate more “accurately” downstream in the sense that there are fewer translation errors from the model to the code. However, it’s a moot point if they don’t get used.
As an alternative, don’t be afraid to hire translators and equip them properly. In many companies, this person often has the title of Business Analyst or User Experience (UX) professional, and what they are really doing is defining and designing software solutions based on understanding a variety of needs and goals. They can learn the modeling language to communicate with technologists, but they need other mechanisms to communicate with everyone else.
It’s those other mechanisms where a huge opportunity exists for innovation and improvement. Visualizing the experience through simulation is one proven method. What might others be?
I agree with this blog posting… to a point.
My company Canonic Corp specializes on modeling all aspects of information relevant to a software initiative, linking that information to provide unique insight, and most importantly making that information available to every stakeholder in a manner that they can understand.
Visualization is an outstanding tool to show stakeholders what a business system will look like, and what the flow will be. iRise does an excellent job at this. It’s easy and quick to use.
However, one huge problem with visualization-sans-requirements is that most business systems do something fairly complex once the user presses the “OK” button. It is essential to capture the requirements in great detail to prevent the all-too-common acceptance test result “I thought the screen would work differently when I saw the demo.”
iRise does a decent job of capturing the requirements that directly relate to a screen. If the application is heavily UI focused, this might be adequate. However, if there is significant back end processing or complex business processes behind the UI, that information will be captured elsewhere, typically in a Word document. That creates a disconnect.
Canonic believes that all information relevant to the project should ideally be captured in one place. Practically we tightly integrate a few sources of information. By having all information logically together, I can begin to answer questions like “what part of the system do I have to recode to support a given requirement”, “what requirement has no tests defined for it”, “how many new screens must I code to support a given requirement”, and “how many tests passed and failed for a given requirement”. In short, we create a 360 degree view of all information and can answer complex questions like these with a simple database query.
Modeling provides the ability to link all information together, from strategic objectives, to project features, to specific requirements, to use cases and test cases, UI definitions (iRise shines here), to web service or business object definitions, and including the database design.
The best way to create software is to model all relevant information, link it together to create transparency and insight, and present the model to each stakeholder in a manner that makes the most sense to them. iRise excels at visualizing the UI model to non-technical participants and is a great choice for that part of the overall solution.
Thanks for the comment! It makes sense to me that the tools you describe are effective at enabling technologists to better build software. However, I am suggesting that the statement “present the model to each stakeholder in a manner that makes the most sense to them” has some interesting challenges. If by “present the model” you mean present something that uses an experience to communicate rather than a model, I agree with you. If what you mean is that you are showing diagrams and text and click-through flows to stakeholders, you are missing a huge opportunity.
One of the most common misconceptions about experience visualizations is that they are only useful for discussions about the UI. Rather, discussing the user experience is what enables non-technologists to understand everything about the software, including those pieces that don’t have a UI. It gives them a frame of reference that they otherwise wouldn’t have. The details discussed are not limited by what is shown, but rather what is shown helps communicate whatever details are necessary to get across.