1. Open Systems and Open Architecture – the benefits case
Peter Henderson
University of Southampton
January 2009
A copy of this presentation is available at

2. Peter Henderson, University of Southampton
Outline
What does it mean to be an Open System?
What are the Costs, the Benefits?
Isn’t this just Open Source?
Some Examples
Is there any evidence that Benefits can be realised?
Plausible argument based on Process
Derived Architecture Principles
Open Architecture Description Issues
January 2009
Peter Henderson, University of Southampton

3. Peter Henderson, University of Southampton
Open Systems
Modular
Able to plug in new or replacement modules
Interfaces between modules subject to consensus agreement – not under sole control of system designers
Able to evolve system by evolving modules
Based on Established COTS infrastructure
January 2009
Peter Henderson, University of Southampton

4. Open Systems - Perceived Benefits
Reduced Whole Life Cost
Reduced Schedule for each Iterate
Reduced Incumbency, wider supplier base
Greater Potential for Innovation
Greater Resilience
More Rapid Capability Insertion
Potential for Evolution from Legacy
Opportunities for Test and Acceptance cost reductions
Potential for improved Interoperability
Potential to exploit COTS
Commonality across currently separate domains
Most practical approach to Systems of Systems
Note – many of these benefits already realised Open Source (see later)
January 2009
Peter Henderson, University of Southampton

5. Open Systems - Perceived Blockers
Industry’s Perception of its future business
Existing Incumbency
Inherent Complexity of Domain
Specific Domain Issues (Security, Safety)
Interoperability with Legacy Solutions
January 2009
Peter Henderson, University of Southampton

6. Why not just Open Source?
Many of the Benefits of Open Systems are realised already by Open Source
In an ideal world all software (and other system components) would be Open Source
Realistically, most suppliers of Domain Specific Applications will continue to have a business model based on IP embedded in software
But where their business is also based on selling into communities of interoperating systems
Hence the need for Open Interfaces and Open Standards
With significant remaining Architectural Issues that we address here
January 2009
Peter Henderson, University of Southampton

7. Generic Architecture COTS hardware and operating systems
Domain specific middleware
COTS middleware
COTS hardware and operating systems
Domain specific middleware
COTS middleware
Component Applications with Open Interfaces, plugged into a Commodity Infrastructure that supports their communication
January 2009
Peter Henderson, University of Southampton

8. Peter Henderson, University of Southampton
Applications Server
Module
Web Server
HTTP
Module
Application
Module
Each module exposes new functionality across HTTP interface
Interfaces (such as HTTP) need to be expandible to support this
Interfaces to modules Standard and Open
Interfaces to Applications Standard and Open
Application
January 2009
Peter Henderson, University of Southampton

9. Peter Henderson, University of Southampton
Data Grid
data source
data reduction
data presentation
Architecture is Recursive
Depends on Precisely defined Open Interfaces
in particular data flow and initiative
January 2009
Peter Henderson, University of Southampton

10. Peter Henderson, University of Southampton
Evidence
Earlier claims about Benefits of Openness over the Costs of Openness need to be supported
All I can do at this time is give a plausible argument based on the Development Process for a large modular system and consider the benefits of Openness in that context
January 2009
Peter Henderson, University of Southampton

11. Systems Development Process
Requirements W
Design
Existing System
Proposed Solution
ReArchitect W
Existing Architecture W W
Required New Architecture
Legacy Components
Available New Components
Buildable New components
ITA W
Red W shows where Work may be done and thus Cost incurred – all would be reduced in the case of an Open System EXCEPT ReArchitect, WHERE the existing system was far from Open (e.g there was no existing system OR it was not Open)
New System
January 2009
Peter Henderson, University of Southampton

12. Peter Henderson, University of Southampton
Cost of Work
Design
Reduced, why?
ReArchitect
Reduced, why? Exceptions
Legacy Components
Buildable Components
Integration, Test and Accept
January 2009
Peter Henderson, University of Southampton

13. Open Architecture Principles
Precise Interfaces, fully specified
Recursive Architectures
Governance of Architecture and Interfaces is Domain Specific
Size of Components chosen to enhance evolution
January 2009
Peter Henderson, University of Southampton

14. Open Architecture Description Issues (1)
Systems Engineers need diagrams and discipline to support their narrative
UML is a Software Modelling language that CAN be used for System Modelling
SysML is evidence of this, but is immature
Difficult to justify use of any other ADL for very large systems at this current time
My experience of the use of UML in industry is that it is Undisciplined and can be a problem as much as a solution
Disciplined use of UML requires adoption of a tight Metamodel against which consistent use can be judged in near real time
January 2009
Peter Henderson, University of Southampton

15. Open Architecture Description Issues (2)
Interface Description is key to maintaining Openness
Interface Description should be precise, but tractable
Thus it requires a degree of formality (e.g. APIs, XML, …) but formal methods are not cost effective at this time outside critical domains such as safety and security
Maintaining the Openness of the Interfaces is essential if the Benefits of Open Systems are to be realised
This requires an Architecture Governance organisation that owns the Architecture and the Specifications
Such a Governance organisation will probably be Domain specific (e.g. Automobile Vehicle Management Systems, Warship Combat Systems)
January 2009
Peter Henderson, University of Southampton

16. Peter Henderson, University of Southampton
Thank You
A copy of this presentation is available at
January 2009
Peter Henderson, University of Southampton