Systems Engineering

KNOWLEDGE (THEORIES, IDEAS & CONCEPTS)

Through Professional/Personal Study Gained Through Experience

Engineering Interdisciplinary Approaches, Processes & Integrated Teaming, Modelling Formulation & Graphical Representation used to as create Systems that satisfy the needs of the customers, businesses, users and other stakeholders

Together with Responsibilities/Accountabilities

Creation of Service Design Packages (SDPs) in order to provide a System Engineering Interconnect between Requirements and Solutions. The primary purpose of Service Design Packages (SDPs) is to provide the service scope and boundary (Service Wrap). It will present a logical design of the service and its’ realisation, plus any dependents on or linked to other services. Business Standards are used as the benchmark that helps identify all the required services, and provides use cases (personas and postures) under which specific instance(s) of the high level service design can be developed. Bear in mind that there may be different solutions for the different deployed environments, but they will all need to work together at an enterprise level in order to achieve a single information environment and coherent passage of data across each of the services. The SDP provides a view of the organisational readiness assessment of a service towards to deployment into a go live environment, and this will include user benefit, business benefit, technical assessment and risks, organisational roles/skills/ competencies and training. The SDP will also serve to act as a repository for the service assumptions, dependencies, performance criteria KPIs & OLIs), transition criteria and acceptance criteria

The creation of complex connections of electromagnetic components and computer systems each of which is simple in their own right, but which together, have a capability or even intelligence to achieve complex objectives with minimal human interaction. Karl managed the development of a military CANbus (Controller Area Network) architecture that connected IT situational awareness systems with Combat System

Together With lessons Learnt

There is no on–size fits all life cycle model that works for complex system, however iterative and evolutionary approaches provide for high-effectiveness, high-assurance, resilience and additivity. With more and more complexity being introduced, model-based logical architectural system of systems approaches coupled with people in engineered and cyber solutions seems to be a way to help meet the future challenges
Unrealistic estimates lead to unrealistic budgets and unexecutable programmes, with cost driving outputs rather than outcome driven endpoints. Undisciplined initial definition and uncontrolled growth in system requirements means programmes spiral in terms of cost and schedule, because you can’t expect to know everything up front on complex systems or model all system behaviours (Planned, Enterprise, External & Emergent)

The development of modular (system families), supplier independent, evergreen (ability to swap out modules with minimal enterprise impact) systems approaches rather than through the selection and application of individual technologies to deliver customer/user needs rather than early fixed and frozen requirements, in order to allow for evolutionary learning, accommodating dynamic controlled changes and expanding the traditional ‘ilities’ (reliability, maintainability & availability) to now include robustness, flexibility and adaptability

Together with Any ‘So What’ Statements of Insights

The development and deployment of a significant number of communication and IT systems following a structured development process from concept, evaluations, development, production to operation for products, systems, systems-of-systems and services. Every system is unique and needs to be considered and thought about separately
Karl managed the development of a military CANbus (Controller Area Network) architecture that connected IT situational awareness systems with Combat Systems. Sometimes without documented ICDs, teams are forced into discovery phases and establishing envelop testing procedures to characterise and quantify interfaces

Karl managed the resolution of a particular difficult software bug that was initially impossible to replicate and characterised. After a few weeks it was detected that it only happened after certain tolerances were exceeded. It didn’t take long to find that a mathematical symbol had been correctly assigned to a routine and that it inadvertently triggered an incorrect behavioural response sending the system into chaotic events. Sometimes it is the smallest of errors that can trigger abnormal behaviours so ensure test cases cover breadth as well as depth