Talk:SSE Meeting 2

Notes taken during afternoon discussions: 15th July 2013 – ADF

1. The discussion started off after lunch with the goal of trying to characterise and scope the service-orientated problem space.

2. Although World Views (Weltanschauungen) were mentioned a number of times during the discussion, nothing definite was decided by way of action on this front. ATJ comment 1: There was a vague action to wait for Duncan Kemp to be available to take advantage of his expertise/experience in this area.

3. Instead, a focus emerged that was on trying to compile a set of Case Studies (although the term actually used more than ‘Case Studies was ‘Use Cases’) which would capture how service-orientated things were done. See para. 11 below for more on this. It remains to be seen if, when and how the Weltanschauung aspect should be dealt with. ATJ Comment 2: My recollection of the discussion on the relationship between case histories and use cases differs from Andrew’s. The case histories are to be thought of as raw service examples captured in their ‘native’ formats, to be transformed by the group into more rigorous (formally-defined) use cases, using both existing SysEng methodologies and the characteristics to be developed by the group, and hence subject to systematic analysis, comparisons and viable conclusions (and hopefully advice). See also paras 8 and 11 below.

4. The purpose of creating a set of Use Cases would be to try and identify how SE process and thinking change when you move from product-orientated thinking to service-orientated thinking.

5. The discussion then moved on to how to generate appropriate/useful variety from the set of Use Cases.

6. One suggestion was to reflect the following views in the sample of use Cases:

• Procurer/customer
• Supplier
• User

7. Another suggestion (thanks to John Davies) was to identify a number of context variables and then try and find examples representing as many combinations of context variables as possible. Possible context variables could be:

• Length of contract
• User community
• Extent of geographical dispersion
• Pure product v. pure service

What might be other context variables?

8. Yet another suggestion for populating the set of examples was simply to ask the members of the SSE WG to supply them from their own experience. A good balance between procurer/customer examples and suppliers would be an important goal. If there was insufficient procurer/customer representation, suppliers could always supply examples from within their own organisation in which they bought in system functionality as services, rather than products (eg in Thales: Asset Management or even IT would be examples – thanks Glenn Panter).

9. Pete Smith suggested collecting samples which reflected pure product at one extreme and pure service at the other extreme, and possible instances of the continuum between the poles.

10. An even more powerful set of examples would be to collect examples that used to be pure product and which subsequently have moved in the service-orientated direction (eg RR?).

ATJ Comment 3: BAES’ transformation of the Harrier business model from Capability Development to Service orientated during its final years could also be worth study.

11. Back to the point made in para. 3, ‘Use Cases’ was, I think, chosen because it implies more structure than ‘Case Study’, which could end up just being a free text description. ‘Use Cases’ may not be the best term for what we are talking about here, but maybe we can use it as short-hand until a better term springs to mind. Anyway, what we do mean by the term is a structured was of describing each of the example Case Studies in our collection.

12. ADF raised the following point: what should each Use Case contain? A template needs to be defined which can be used to characterise each example. In other words we need to define the scope of what the Use Cases are telling us.

13. Once we have a set of Use Case examples, we would examine them to see how SE is done differently in a service world compared to a product world.

14. It will probably be wise if those present reflect on the discussions held during this session of the meeting. A lot of ideas were being generated, and we were under time pressure to decide on a way forward before everybody left to get on the motorway or catch their train. I suggest therefore, everyone considers the ideas expressed in this note, and adds to it their own recollections, thoughts and amendments/corrections. That way an agreed plan can be formulated. If, on the other hand, on reflection people have reservations about what is proposed and have alternative ideas, these too should be considered at this time.

15. For the record, here is the list of tasks coming out of the above way forward – a slightly modified view of the list Tony put up on the screen, which dovetails with the above notes:

1. Define possible characterisation variables of each example (see para. 7)

2. Define contents of a Use Case (see para. 12)

3. Create Use Cases based on real examples (either by canvassing WG members, or by varying the variables) (see paras 6 to 10)

4. Review characterisations (see para. 7)

5. Review Use Case template (see para. 12)

6. Conduct literature search for terminology and methodology (in enterprise methods?). Did Rachel Freeman offer to do this?

7. Get useful stuff out of Use Cases, develop suitable approaches to SSE (ie bring it all together) and demonstrate approaches by application to use cases (see para. 13)

8. Think about what questions could be addressed by doing a World View analysis of the service topic (eg supplier, user, & procurer perspectives, but what else?)

ATJ comment 4: I suggest that we retain the original list of tasks until the remaining attendees have had an opportunity to contribute to both notes and narrative; it is after all what we all signed up to at the meeting, and it would be advantageous to encourage the sense of shared ownership .

Comments welcome.

Andrew Farncombe