The role of system architecture in system development
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

The Role of System Architecture in System Development PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on
  • Presentation posted in: General

The Role of System Architecture in System Development. Richard Taylor Feb 15 2006. What is System Architecture?.

Download Presentation

The Role of System Architecture in System Development

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The role of system architecture in system development

The Role of System Architecture in System Development

Richard Taylor

Feb 15 2006

INCOSE


What is system architecture

What is System Architecture?

  • The partitioning of a system into components (hardware, software, people, procedures, data, communications) which satisfy the operational need and the technical requirements within established budget and schedule constraints and relates the components to each other.

  • The partitioning of a large, complex problem into a set of simpler problems.

  • The step between requirements specification and software/hardware design.

INCOSE


System development roles relationships

System Architecture

  • Partition problem space

  • Allocate data & function to partitions

  • Specify connectivity between partitions

Program Management

  • Select standards & protocols

  • Develop migration strategy

  • Interface with customer

  • Select S/W comp

  • Select H/W comp

  • Model

  • Infrastructure

  • Applications

  • Processors

  • Comm

  • Peripherals

  • Sizing

  • Perf

  • Avail

  • Manage cost

  • Manage risk

System Engineering

  • Monitor technical performance metrics

  • Manage schedule

  • Specify requirements

  • Manage processes/documents/reviews/interfaces

  • Coordinate human factors

  • Manage configurations/versions

  • Develop & manage test scenarios/plans

  • Funding

  • Personnel

  • Facilities

  • Support services

  • Acquire/manage resources

  • Manage customer relationship

Software Development

Hardware Development

  • Select software methodology

  • Develop software architecture

    • Software partitioning

    • Calling structure

    • Reuse plan

  • Design/develop DBs

  • Develop new software

  • Integrate COTS

  • Perform unit/string tests

  • Develop hardware architecture

    • Hardware partitioning

    • Connectivity

    • COTS components

    • Reuse plan

  • Develop hardware routings

  • Develop prototypes

  • Integrate COTS

  • Manufacture new hardware

System Development Roles & Relationships

INCOSE


System vs software architecture

System Vs. Software Architecture

  • Software architecture

    • Many notations

    • Module inventory

      • Top-level applications

      • Supporting modules – reuse plan

      • Component partitioning

      • COTS

    • Calling structure

      • Data passing

      • Control passing

  • System Architecture

    • Includes hardware, software, communication equipment, DBs, people, procedures

    • Reflects multiple instances of components

    • Reflects spatial characteristics

    • Is capable of being modeled for performance, capacity, availability

Focus is on how software is built

Focus is on how system executes

INCOSE


How does system architecture address non functional requirements

How Does System Architecture Address Non-Functional Requirements?

  • Identify threats to system performance and stability

  • Address threats by logically partitioning system into replicable, highly-autonomous components

INCOSE


Threats to system s ability to support mission

Threats to System’s Ability to Support Mission

  • External systems’ behavior

    • Availability

    • Response time

    • Data integrity

  • Internal system complexity

    • Control & data flow between subsystems

    • Performance & availability dependencies

    • Consistency of internal interfaces

  • Operator performance

    • Accuracy

    • Speed

    • Reliability/availability

INCOSE


More threats

More Threats

  • Technology Obsolescence

    • End-of life impacts

    • Major technology shifts

    • Loss of maintenance support

    • Standards & protocols

  • Reliability of system components

  • Disaster scenarios

  • Unexpected demands

    • Capacity

      • Transactions/messages

      • Network load

      • Database access

      • Application service

    • Environment

    • Geographic distribution

INCOSE


Bulletproofing techniques

Bulletproofing Techniques

  • Behavior of external systems

    • Ensure that system boundaries are optimal

      • Ensure consistent enterprise context

      • Maximize autonomy

      • Design proxy for external systems if boundaries cannot be optimized

    • Establish clean, simple interfaces

      • Insensitive to most changes to external systems

      • Never share databases

      • Be asynchronous, if possible

    • Encapsulate databases

    • Build in reduced function mode to accommodate outages

    • Exploit defaults/ fallbacks, where possible

    • Employ common protocols and standards

INCOSE


Bulletproofing techniques1

Bulletproofing Techniques

  • Internal system complexity

    • Partition into a manageable number of subsystems (3 to 10)

      • Ideally, one IPT per subsystem

      • 3 to 9 people per IPT.

    • Introduce segments (groups of subsystems), if necessary

    • Maximize autonomy of subsystems

    • Encapsulate databases within subsystems

    • Isolate infrastructure functions from applications

      • Interprocess communication/ Workflow management – separate subsystem

      • System management – separate subsystem

    • Support multiple instances

INCOSE


Bulletproofing techniques2

Bulletproofing Techniques

  • Operator performance

    • Minimize dependency

      • Simplify interface (minimize training & skill level)

      • Support “undo” function wherever possible

      • Take default action in absence of operator input, if possible

      • Avoid operator involvement in routine actions – e.g., system management handling of common failures

    • Support scalability – allow number of operators to vary widely

    • Enforce strong data typing in interface standards

    • Statistically sample operator input & reject poor quality data

INCOSE


Bulletproofing techniques3

Bulletproofing Techniques

  • Technology Obsolescence

    • Maintain generic architecture as the enduring representation of the system

    • Avoid dependency on a single supplier – always have a backup option

    • Minimize direct interfaces between components

      • Workflow management

      • Common message/control passing mechanisms

    • Avoid proprietary protocols

INCOSE


Bulletproofing techniques4

Bulletproofing Techniques

  • Reliability of system components

    • Build in scalability – support multiple instances of components performing the identical function

    • Avoid dependence on availability of one specific component instance

    • Avoid single points of failure

    • Support fallback/ critical function mode

  • Disaster scenarios

    • Use distributed sites to back each other up – buddy system

    • Design in checkpoints where operations can be restored

    • Periodically exercise disaster recovery – rotate your tires

INCOSE


Bulletproofing techniques5

Bulletproofing Techniques

  • Unexpected demands

    • Capacity

      • Build in scalability across the entire system

        • Sites

        • Subsystems

        • Application servers

        • Network services

        • Database access

        • Infrastructure

      • Exploit partitioning potential introduced in generic architecture

      • Build in margins

    • Environment

      • Anticipate during operational analysis phase

      • Handle like technology refreshment

INCOSE


Cost issues of bulletproofing

Cost Issues of Bulletproofing

  • Often viewed as prohibitively expensive during acquisition and early development phases

  • Do the analysis anyway

  • Build the flexibility into the generic architecture

  • Most of the cost isn’t borne until the instantiated and operational architectures are implemented

  • Help the customer do the risk analysis

    • Align with mission objectives

    • Align with customer’s risk tolerance

  • Allow for later bulletproofing if threat profile changes

INCOSE


Architectural heuristic

Architectural Heuristic

  • “When working on a problem, I never think about beauty. I think only of how to solve the problem. But when I have finished, if the solution is not beautiful, I know that it is wrong.”

Buckminster Fuller

INCOSE


  • Login