1. Architecture Design Rules in LedsystT
How it started
To be followed by a presentation of current status
Per-Georg Jönsson, Swedish Defence Materiel Administration,
Capabilities, Strategies and Future Systems
Competence area for Systems Engineering, Architecture and Configuration Management

2. FMA Short history (main objectives)
FMA Version milestone (M3)
2002 Financed by LedsystT Phase 1, 1+ developing FMA version milestone (M4, M5)
2003 Working with information and presentation materia based on FMA version 2.0 M5, evaluate
Test, adapt and implement FM A based concepts in LedsystT
NATO-NAF-FM AR analysis
FM A developing and implementation project established FMV/FM

3. The long and winding road
Architecture Program
Preparations and research
Delivery M3
Delivery M5
FM Ledsyst Phase 0
FM Ledsyst Phase 1
FM Ledsyst
1999
2000
2001
2002
Goal: 2010
Further development and practical usage outside Architecture development program
Other programs
Architecture Program
Framework investigation
Clarification
The NAF v 3 era
FM Ledsyst Phase 2
FM Ledsyst
2003
2004
2005
2006
Historic Review

4. The old FM A Enterprise Architecture version 2.0
24 main concepts
24 presentations
54 Whitepapers
lots of reference matrl

5. Holistic Architecture Description Perspectives (models (aspects) of the architecture)
System description view (system hierarchy)
What system elements are present at this system level in the internal information exchange model (IER)?
Organisation description view (Actor model)
What system elements are able to act and what roles do they act upon?
Business description view (Procedures)
How do actors in the system act (activities of the system) and the internal information exchange model (IER = Information Exchange Requirements)
Personnel description view
Rules diagram that controls the acting within the system
Information description view
Conceptual model (CM), Information model (IM), Information exchange model (IEM), Data model (DM), Data exchange model (DEM) and Storage model (SM) for each use case instance and additional models for each domain (CD = Cognitive behavioural domain, RD = Representation domain (Information domain), PD = Physical domain (technical models)
Technology description view
Technical component descriptions

6. i S O P K T I The Pyramid Model Business Viewpoint Doctrine
Process
Doctrine
Products
The material (real) world
Capability
Role
Organization
People
Competence
Knowledge base
Spec i
Information
Viewpoint O S P K T I
Business

7. LedsystT Most important used Concepts
Service Concept
Service Tiers (LOVNETP)
System Concept
System as a black box, with coupling to other systems
System as a white box containing other system (seamless break down in system of systems)
Systems of Systems Concept
Network centric concept
Design Rule Concept
Information Concepts
Modelling of systems using UML

8. Ex System view, White box

9. Service demonstrator 03 Autom/04 Spring
Designrules
Ver 2.0
MMI sit syst builder
Time Geodata
Sea Radar Torö
Nynäshamn
MMI presentation
UndE AA Radar
Gothenburg
Fusion mode
Land info SLB
Netcorrelation
SIM Federation
SIM Air FSR 890
SIM NBD
SIM Air Sea Strics

10. Design rules Based on standards Accounts for industry best practices
Derived by exploiting key competencies from Boeing, Ericsson, IBM and SAAB as well as Swedish and international research bodies
Will be open/public
exception information security implementation

11. The characteristics give a better understandig of what a design rule is
Design rule characteristics:
Packages knowledge in a reuseable form
Ensures that the requested properties are achieved (flexibility, interop…)
Provides value for a re-user, i.e. by
proposing a solution to a difficult problem
improving the quality of the resulting product
proposing a way of enabling the exploration of opportunities
May solve both high and low level problems. Value to the re-user is the most importand aspect.
The key differentiator between a design rule and a requirement is that the design rules defines a solution
Can satisfy one or more requirements
Can be part of a design rule package – DRP - for a problem domain

12. Nothing new…Designrules 1200, The holy Franciscus
The holy Franciscus, Il Poverollo,
“ A rule excludes permanent wiggling between different alternatives. It makes it possible to follow a defined line. It is not the amount of details, but abeyance to a few directives that is of importance. The directives shall be so short and clear that you immediately can recall them in your memory
“The rule should be practical, addressed directly to the sense and shall be personal. Not until you thoroughly have considered the rule, elaborated it carefully, have allowed it to mature and hardened it you should train yourself in being fateful to it”

13. Design rules are organized in a hierarchic structure
Design rules are grouped in a number of categories and levels of detail.
One initial detailed structure is the following:
Design
Development
NBD
Rules –
Method
Governance
Verification and validation
System concept
Services concept
System description
Rules –
Framework
Service description
System Design
Service Design
Business
Rules –
Design
Application
Information
Technical

14. Architecture experiences
Good start among designers for demonstrators
System and service thinking quickly adopted
Fairly good experience from model based approach and modeling
Very successful demonstrators
Slow start among architects
Architectural work suffered from front end problems of placing contracts and starting up the organization
Windows of opportunity for controlling with architecture is at the beginning
Uneven skills for architecture and modeling at the beginning, eg few with appropriate skills in modeling
Architects without sufficient power to control the development
Required input from mission domain largely lacking
Supporting Sw AFEA project was not financed
Understanding of how to use Design Rules took time to established
A lot of work was done without proper correlation and control
Restart based on NAF v2 summer 2005
Top down approach
To late to influence the rest of the project
Still a valid experience for the future and for the creation of principles and design rules