Difference between revisions of "SSE Meeting 32"

From Service Systems Engineering Group Wiki
Jump to: navigation, search
(Next Meeting)
(Actions)
 
(4 intermediate revisions by one user not shown)
Line 37: Line 37:
  
 
== Providing a better framework ==
 
== Providing a better framework ==
+
To bring work together a Enterprise Architecture could be used.
Considering MoDAF as an example Architecture
+
However instead of producing a new one, could we provide Service specific entities that could be used within existing Architecture frameworks.
we could modify.
+
  
== Start of lifecycle ==
+
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.
  - using Services to make money.
+
  
== Way Forward ==
+
However, there are perceived issues with the use of MoDAF that detract from following this line of work.  
The format and content of the ASEC paper was seen as a good way forward for general work.
+
  
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.
+
Discussions with the Architecture Working Group would be useful for this work.
  
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.
+
== 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.
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.
+
To pursue this would involve definitions of and understanding relationships between:
 
+
* the Business Strategy
== Methodology ==
+
* the Business Success
Work from last meeting is seen as a good basis for further work.
+
* the Business System/Service Solution
 
+
* the Business Case
* 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 Opportunity
* 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 Offering
* 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 Potential Customer
* 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 Potential Market
* Comparison was made with Product Service Systems (Tukker) which deals with a range of Services from Pure Service to Pure Product.
+
* the Customer Environment
* It was noted that the standard Service Oriented Architecture relating Business Model to Services provided by System Components fits into our wider
+
* the Existing Technical Environment
 
+
* the Potential Customer
== Dissemination ==
+
* the Existing Service Elements
+
* etc.
* How to get our finding intooo the wider community was discussed.  Favoured oprios are:
+
 
+
* Presentation to Bristol Local Group (and to other groups if they meet))
+
* Paper to IS (and ASEC if the current paper is accepted)
+
* 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 ==
 
   
 
   
 
12 November or 10 December 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 11: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.

Service Systems Engineering Group Wiki

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox