Difference between revisions of "SSE Meeting 32"

From Service Systems Engineering Group Wiki
Jump to: navigation, search
(→‎What Process, Techniques, Models do we have? Which are useful when?)
(→‎Actions)
 
(9 intermediate revisions by one user not shown)
Line 12: Line 12:
  
 
==What Process, Techniques, Models do we have? Which are useful when?==
 
==What Process, Techniques, Models do we have? Which are useful when?==
 +
 
We have seen/studies/developed techniques - mostly to support analysis and design, but also to cover operation,
 
We have seen/studies/developed techniques - mostly to support analysis and design, but also to cover operation,
  
−
Paper for ASEC2018 NCS ILS,
+
Service-Centric Analysis
−
how to/where to split providers?
+
* as described in Paper for ASEC2018  
−
Apply Simon’s techniques/process to
+
** Covers analysis of need and specification for Services
−
Bus Service - good
+
** applied to Norway Military Vehicle service and logistics
−
Health Care – poor
+
** provides detailed analysis
−
Apply SOA model to Norway NCS ILS –
+
** not yet seen for how to/where to split providers?
−
doesn’t add/help
+
* Considered for applying to
−
Apply NECTISE Model NCS ILS – OK
+
** Bus Service - good
−
Apply NECTISE model to Health Care, University - OK
+
** Health Care – poor
  
−
== Providing a better framework ==
+
SOA model - as in TOGAF
−
   
+
* applied to many software services
−
Considering MoDAF as an example Architecture
+
** provides diagrams of how services are composed to provide business process  
−
we could modify. 
+
** Apply to Norway NCS ILS - doesn’t add/help
  
−
== Start of lifecycle ==
+
NECTISE Model -
−
- using Services to make money.
+
* structure of services to provide capability
 +
* mostly visual can be applied to:
 +
** NCS ILS – OK
 +
** Health Care, University - OK
  
−
== Way Forward ==
+
== Providing a better framework ==
−
The format and content of the ASEC paper was seen as a good way forward for general work.
+
To bring work together a Enterprise Architecture could be used.
 +
However instead of producing a new one, could we provide Service specific entities that could be used within existing Architecture frameworks.
  
−
Further work on 'What happened before, during and after the work in the paper will be useful in mapping out the process/lifecycle for development and use of services.
+
MoDAF already has Services and service oriented views.  These are for Software-based Services.  On examination they cover some of the work we have done on identifying and defining Service Entities.  We can provide updated Service entities and relationships too provide an enhanced Architecture Framework.
  
−
The Systems Engineering Handbook, SeBOK and ISO/IEC 15288 were considered for their contribution, but found to cover services as a way of maintaining a system in service, rather than providing a service.
+
However, there are perceived issues with the use of MoDAF that detract from following this line of work.  
  
−
Work on the Service-Centric and Product-Centric views of the system need to be extended and tested against various Case Studies to see where they are useful and where they are not.
+
Discussions with the Architecture Working Group would be useful for this work.
  
−
== Methodology ==
+
== Start of lifecycle ==
−
Work from last meeting is seen as a good basis for further work.
+
Discussions as to what was needed for Services ranged to why would a developer develop and provide a service solution to a customer rather than a system-based solution and why might a customer want a service-based solution rather than a system-based solution.
−
 
+
To pursue this would involve definitions of and understanding relationships between:
−
* Four different white-board briefs of our contribution were produced and discussed.  It was agreed that considering two views of the system - one service oriented and one system oriented could be used to cover the four different briefs, and provide  strong message.
+
* the Business Strategy
−
* It was agreed that the major contribution to be expressed in this paper is for the analysis of Services in terms of Context Diagrams, Stakeholder Analysis, Behaviour Analysis, Context Analysis and Structure Analysis are different if you take Service-Centric views against what you get if you take a System-Centric views.
+
* the Business Success
−
* The difference compared to Architecture Frameworks, that include Service views such as MoDAF, is that AFs are looking at services as system components, whereas we are looking at the enterprise or business from two views - one Service-Centric and one System-Centric.
+
* the Business System/Service Solution
−
* Hence for example a Service-Centric Stakeholder Analysis will be similar (and use the same or similar methods) to a System-Centric Stakeholder Analysis but focus on the Service aspects and provide a richer set of outputs.
+
* the Business Case
−
* Comparison was made with Product Service Systems (Tukker) which deals with a range of Services from Pure Service to Pure Product.
+
* the Business Opportunity
−
* It was noted that the standard Service Oriented Architecture relating Business Model to Services provided by System Components fits into our wider
+
* the Business Offering
−
 
+
* the Potential Customer
−
== Dissemination ==
+
* the Potential Market
−
+
* the Customer Environment
−
* How to get our finding intooo the wider community was discussed.  Favoured oprios are:
+
* the Existing Technical Environment
−
 
+
* the Potential Customer
−
* Presentation to Bristol Local Group (and to other groups if they meet))
+
* the Existing Service Elements
−
* Paper to IS (and ASEC if the current paper is accepted)
+
* etc.
−
* Guidance Document
+
−
* Z Guide
+
−
* Omega Guide
+
  
 
== Actions ==
 
== Actions ==
 
   
 
   
−
* SW – to extend vehicle service to link into earlier and later activities related to service and also to product development.
+
* JD to chase actions from last meeting
−
* NT to test ideas in work related to his day job.
+
* JD to look at early lifecycle entities and relatiionships
−
* JD to test ideas on other Case Studies
+
−
* AF to look at how the INCOSE UK In-service Systems engineering work was disseminated and how successful the different methods were..
+
−
 
+
−
*AC is hoping to take early retirement and may not be able to contribute further.
+
  
 
== Next Meeting ==
 
== Next Meeting ==
 
   
 
   
−
tbd November 2018, 10-30 to 14-30, Rolls Royce, Filton, Bristol.
+
12 November or 10 December 2018, 10-30 to 14-30, Rolls Royce, Filton, Bristol.

Latest revision as of 10:26, 28 September 2018

Contents

[edit] Attendees

John Davies, Iain Cardow, Sarwar Ahmad.

[edit] Overview

Discussions were wide ranging and covered:

  • What techniques we have and what service/systems can they apply to?
  • Can we better handle Services within an enterprise architecture?
  • Early life-cycle - how is the decision made to develop/deploy a service ?

[edit] What Process, Techniques, Models do we have? Which are useful when?

We have seen/studies/developed techniques - mostly to support analysis and design, but also to cover operation,

Service-Centric Analysis

  • as described in Paper for ASEC2018
    • Covers analysis of need and specification for Services
    • applied to Norway Military Vehicle service and logistics
    • provides detailed analysis
    • not yet seen for how to/where to split providers?
  • Considered for applying to
    • Bus Service - good
    • Health Care – poor

SOA model - as in TOGAF

  • applied to many software services
    • provides diagrams of how services are composed to provide business process
    • Apply to Norway NCS ILS - doesn’t add/help

NECTISE Model -

  • structure of services to provide capability
  • mostly visual can be applied to:
    • NCS ILS – OK
    • Health Care, University - OK

[edit] Providing a better framework

To bring work together a Enterprise Architecture could be used. However instead of producing a new one, could we provide Service specific entities that could be used within existing Architecture frameworks.

MoDAF already has Services and service oriented views. These are for Software-based Services. On examination they cover some of the work we have done on identifying and defining Service Entities. We can provide updated Service entities and relationships too provide an enhanced Architecture Framework.

However, there are perceived issues with the use of MoDAF that detract from following this line of work.

Discussions with the Architecture Working Group would be useful for this work.

[edit] Start of lifecycle

Discussions as to what was needed for Services ranged to why would a developer develop and provide a service solution to a customer rather than a system-based solution and why might a customer want a service-based solution rather than a system-based solution. To pursue this would involve definitions of and understanding relationships between:

  • the Business Strategy
  • the Business Success
  • the Business System/Service Solution
  • the Business Case
  • the Business Opportunity
  • the Business Offering
  • the Potential Customer
  • the Potential Market
  • the Customer Environment
  • the Existing Technical Environment
  • the Potential Customer
  • the Existing Service Elements
  • etc.

[edit] Actions

  • JD to chase actions from last meeting
  • JD to look at early lifecycle entities and relatiionships

[edit] Next Meeting

12 November or 10 December 2018, 10-30 to 14-30, Rolls Royce, Filton, Bristol.

Retrieved from ‘http://www.incosewiki.info/Service_Systems_Engineering/index.php?title=SSE_Meeting_32&oldid=287’

Service Systems Engineering Group Wiki

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox