The Role of System Architecture in System Development

1. The Role of System Architecture in System Development Richard Taylor Feb 15 2006 INCOSE

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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