When a group of people come together for sensemaking about a situation, it’s pretty typical for someone to start sketching out boxes and lines to improve the clarity of the ideas. Amongst 2 or 3 people, this might be sketching on a napkin. Convening in an office usually suggests that a flip chart or a whiteboard will be used. These media have the advantage of expressiveness — effectively conveying ideas — with the challenge of replicable precision and subsequent intelligibility to people beyond the original participants. As the average business professional has become more adept with computer-based tools, presentation graphics — often as dreaded Powerpoint slides — are common. Although more advanced drawing tools (e.g. vector graphic editors) and specification languages (e.g. UML and SysML) are easily available, the gulf between “easy-to-use” office productivity tools and “rigourous” modeling tools has yet to be bridged.
Based on a legacy of collaborations with IBM Research, my colleague Ian Simmonds pointed out the upcoming workshop on “Flexible Modeling Tools” at Cascon 2009 — a short commute within the Toronto area — with the following description.
This workshop will explore why modeling tools are not used in many situations where they would be helpful and what can be done to make them more suitable.
For example, during the exploratory phases of design, it is more common to use white boards than modeling tools. During the early stages of requirements engineering, it is more common to use office tools. Yet in these examples, as in many other tasks, the advantages of modeling tools would be valuable – providing multiple views for visualization and convenience of manipulation, providing domain-specific assistance (e.g., “content assist”), ensuring consistency, etc. Why, then, are they not used? The many reasons include: learning curve, interaction medium, rigidity and lack of support for informality.
This workshop will bring together tool builders and people who have or might use tools for their software development activities to explore the barriers inherent in current modeling tools and what can be done to remove these barriers. It will also address what key research challenges remain.
The day-long workshop on November 2 should be more of a generative conversation, rather than an exposition of completed research. Contributions to the workshop are in the form of position papers. On my last visit to the UK, I had some discussions with Gary Metcalf and Jennifer Wilby on current research into an emerging science of service systems, as well as ongoing client work with municipalities in Canada. We wrote this up, and the position paper was accepted for the workshop.
Introducing modeling tools to non-technical business professionals: some cases with preliminary observations
daviding October 28th, 2009
Some months ago, Kelly Lyons recommended me as a panelist for a workshop at Cascon 2008 on “SOA Research Challenges: Current Progress and Future Challenges”, on the topic of Service Science, Management and Engineering. I found that Cascon workshops share existing knowledge and develop new knowledge — in contrast to paper presentations about completed work. The workshop was described in the following way:
This workshop will identify critical SOA research challenges that need to be addressed by the research community for SOA to fulfill its promise. The workshop will present a taxonomy of SOA research issues that will be used to frame the rest of the discussion. The workshop will focus on research needs that are currently causing the greatest pain for SOA practitioners. Topics will include “hard problems”, tooling issues, governance challenges, monitoring through the life cycle, and the longer-term evolution of SOA. The workshop will include presentations by practitioners and the research community in addressing critical unmet issues.
Most of the time, my research work and day job are only loosely coupled. In the Cascon context, my longer-horizon organizational and economic thinking was to be applied with more immediate question issues related to technology. I was given the following outline to as a suggestion for my talk:
- Overview of the topic, in this case SSME
- Why is it important to talk about this (rationale)
- How it relates to SOA
- What are current efforts in establishing this relationship
- Challenges and gaps. This could apply to SSME, SSME and SOA, and/or education/training for people developing service-oriented systems
I responded to the speaking opportunity with a new presentation. Some themes I’ve covered in previous talks, e.g. ICT capital, a new science of service systems, and T-shaped professionals. Some new ideas that I added were:
During the workshop, I wrote up a digest as I listened to the other panelists. Some things that I learned during the afternoon were:
daviding November 28th, 2008