Category: executive

  • Data Strategy neu interpretiert für 2026ff

    Meine Rolle als Senior Data Strategist / Data Governance Architect interpretiere ich als strategischer Brückenbauer zwischen IT, Management und Fachbereichen. Meine Hauptaufgaben umfassen die ganzheitliche Analyse gewachsener, fragmentierter Datenlandschaften, die Entwicklung eines zukunftsfähigen Zielbildes samt Roadmap sowie den Aufbau von Data-Governance-Strukturen und Rollenmodellen (z. B. Data Owner und Data Steward).

    Profitieren Sie von meiner Erfahrung in diversen Projekten mit Bezug zu Unternehmensarchitektur, Datenstrategie und KI. Aktuelle Ergebnisse und weitere Vorhaben bei meinen Kunden aus den Branchen Automotive, Finance, und HealthCare weisen alle in dieselbe Richtung, wenn auch mit unterschiedlichem Grad des Fortschritts und Geschwindigkeit bei der Veränderbarkeit: Datenmanagement und KI sind untrennbar miteinander verbunden und gestalten als Fundament eine wirtschaftlich erfolgreiche Zukunft mit.

    Auswahl zugehöriger Projekthemen:

    • Bestandsaufnahme der Datenlandschaft in Form von Datenobjekten und Informationsflüssen zwischen Applikationen
    • Umsetzung von Data & AI Governance gekoppelt mit Daten- und KI-Architektur (IST vs SOLL) zur Planung und Harmonisierung aktueller Initiativen.
    • Demokratisierung der Geschäftsobjektmodellierung und Zugriff für alle Mitarbeiter durch Einführung einer Datenmanagementplattform (Business Object Navigator, eine Ontologie je Business Object).
    • Einführung EIA (Enterprise Information Architecture) mit unternehmensweitem Geschäftsobjektkatalog, Blueprints für umsetzende Anwendungen und rollenbasierter Governance (Data Owner = Product Owner, Data Steward / Data Architect).
    • Kollaborative Modellierung von Geschäftsobjekten für Produkt-Teams mit Abgleich konzeptioneller, fachlicher und physischer Sichten. Erreichung hoher und breiter Akzeptanz durch die Produkt-Teams bis hin zur selbstständigen Weiterentwicklung.
    • Erarbeitung von Lösungsanforderungen, Evaluierung Tool-Kandidaten (long List, short List), Auswahl, Pilotierung, Einführung, Ausbau im Bereich Unternehmensarchitektur und Data Management.

    Um dieses Profil in den Kontext des aktuellen Standes der Technik einzuordnen, müssen moderne Architekturparadigmen, die Integration von Künstlicher Intelligenz (KI) und aktuelle regulatorische Anforderungen berücksichtigt werden:

    Data Excellence 2026ff

    1. Moderne Zielarchitekturen: Data Fabric und Data Mesh Um historisch gewachsene Datensilos (sogenannte „Data Swamps“) aufzubrechen, setzt der aktuelle Stand der Technik auf die Kombination zweier komplementärer Ansätze:

    • Data Fabric (Die technologische Schicht): Hierbei handelt es sich um eine intelligente, plattformübergreifende Integrationsschicht, die Metadaten nutzt, um Daten unabhängig von ihrem physischen Speicherort nahtlos zu verbinden und Prozesse mithilfe von KI zu automatisieren.
    • Data Mesh (Das organisatorische Paradigma): Dieser dezentrale Ansatz verlagert die Datenverantwortung in die Fachbereiche (Domain-driven Ownership) und behandelt Daten als Produkte. Es erfordert eine Self-Service-Infrastruktur und eine föderierte Governance, bei der globale Standards gemeinsam definiert, aber lokal in den Domänen umgesetzt werden. Ein Data Strategist muss evaluieren, wie diese Konzepte im Unternehmen in logische Datenmodelle und strukturierte Datenflüsse übersetzt werden können.

    2. KI-Readiness und Agentic AI im Datenmanagement Der Einzug von KI stellt sowohl den größten Treiber als auch den größten Nutznießer einer modernen Datenstrategie dar.

    • AI-Ready Data: Eine Kernaufgabe des Governance-Architekten ist es, die Datenbestände für KI-Workloads zu qualifizieren. Dies bedeutet, eine extrem hohe Datenqualität sicherzustellen, Bias (Verzerrungen) in den Trainingsdaten zu vermeiden und eine lückenlose Dokumentation der Datenherkunft (Data Lineage) zu gewährleisten.
    • KI als Werkzeug (Agentic AI): Der Stand der Technik erlaubt es heute, KI-Technologien einzusetzen, um das Datenmanagement selbst zu professionalisieren. KI-Agenten können Aufgaben wie die automatisierte Datenklassifizierung, das Metadaten-Harvesting und die kontinuierliche Anomalie-Erkennung übernehmen, wodurch die Governance effizient und skalierbar wird.

    3. Strenge Regulatorik: EU AI Act und Data Act Die strategische Ausrichtung von Datenlandschaften wird massiv durch neue gesetzliche Rahmenbedingungen geprägt. Der EU AI Act fordert bei KI-Systemen eine strenge, risikobasierte Governance und Transparenz. Er verlangt hochwertige, fehlerfreie Datensätze sowie die Erklärbarkeit, welche Daten zu welchen KI-Entscheidungen geführt haben. Der Data Act zielt zudem auf die Förderung der Datenökonomie durch einen erleichterten Datenaustausch und die Vermeidung von Vendor-Lock-ins ab. Eine moderne Data-Governance-Strategie muss diese regulatorischen Leitplanken von Beginn an als Fundament (“Compliance by Design”) integrieren.

    4. Kultureller Wandel und Data Literacy Neben der Konzeption von Architekturen und der Evaluation von Lösungen (z. B. durch Mini-POCs) ist der Senior Data Strategist primär ein Change Manager. Technologische Transformationen scheitern häufig an fehlender Nutzerakzeptanz und verkrustetem Silodenken. Daher ist die Förderung einer ausgeprägten Datenkultur und „Data Literacy“ (Datenkompetenz) auf allen Ebenen unabdingbar. Der Architekt muss in Workshops moderieren, die Fachbereiche als „Co-Builder“ in die Strategie einbeziehen und den geschäftlichen Mehrwert (ROI) der Dateninitiativen gegenüber dem Management klar kommunizieren.

    Zusammenfassend erfordert das Profil des Senior Data Strategist / Data Governance Architect heute die Fähigkeit, das „Warum“ und „Wohin“ einer Datenstrategie mit den hochaktuellen Anforderungen von dezentralen Architekturen (Data Mesh), KI-Einsatz und europäischer Regulatorik in Einklang zu bringen und dies in ein pragmatisches, umsetzbares Zielbild zu übersetzen.

  • Classifying Language Models along Autonomy & Trust Levels

    The Problem

    Language models are everywhere now. People praise them, but also complain about responses—unreliable, hallucination, cannot let it work alone, and so on. These systems, capable of understanding and generating human-like text, are often called copilots—a term borrowed from aerospace or car racing. That term indicates their main expected role being support for the pilot.

    But how do we actually classify what these models can do? And more importantly, how much can we trust them?

    A Hybrid Classification Framework

    Drawing inspiration from the SAE levels of driving automation and grounded in human-computer interaction research on trust in automation, we propose a two-dimensional framework for classifying language models:

    1. Operational Autonomy – adapted from SAE Levels (0–5): What can the model do on its own?
    2. Cognitive Trust and Delegation – how much mental effort does the user expend, and how much responsibility is delegated?

    Each level in the chart below reflects both dimensions.

    LevelAutonomy DescriptionTrust/Delegation Role
    0 – Basic SupportPassive tools like spellcheckers; no real autonomyNo Trust: User must fully control and interpret everything
    1 – Assisted GenerationSuggests words or phrases (autocomplete); constant oversight neededSuggestive Aid: User supervises and approves each suggestion
    2 – Semi-Autonomous Text ProductionGenerates coherent content from prompts (emails, outlines); needs close supervisionCo-Creator: User relies in low-stakes tasks but reviews all outputs
    3 – Context-Aware AssistanceCan handle structured tasks (e.g., medical summaries); users remain alertDelegate: User lets go during routine tasks but monitors for failure
    4 – Fully Autonomous Within DomainsWorks independently in narrow contexts (e.g., customer service bot)Advisor: Trusted within scope; user rarely intervenes
    5 – General Language AgentHypothetical general-purpose assistant capable across domains without oversightAgent: Fully trusted to operate independently and responsibly

    Why SAE Levels Make Sense

    While not acting in the physical world, it makes perfect sense to compare language models to autonomous vehicles in terms of their capabilities and limitations. The SAE classification helps clarify expectations, safety considerations, and technological milestones.

    Let’s first briefly revisit what each SAE level entails for automobiles:

    • Level 0 (No Automation): The human driver does everything; no automation features assist with driving beyond basic warnings.
    • Level 1 (Driver Assistance): The vehicle offers assistance with either steering or acceleration/deceleration but requires constant oversight.
    • Level 2 (Partial Automation): The system can manage both steering and acceleration but still requires the human to monitor closely.
    • Level 3 (Conditional Automation): The vehicle handles all aspects of driving under specific conditions; the human must be ready to intervene if necessary.
    • Level 4 (High Automation): The car can operate independently within designated areas or conditions without human input.
    • Level 5 (Full Automation): Complete autonomy in all environments—no human intervention needed.

    Adapting Levels to Language Models

    Level 0: Basic Support

    At this foundational level, language models serve as simple tools—spell checkers or basic chatbots—that provide minimal assistance without any real understanding or autonomy. They do not generate original content on their own but act as aids for humans who make all decisions.

    Example: Elementary grammar correction programs that flag mistakes but don’t suggest nuanced rewrites.

    Level 1: Assisted Generation

    Moving up one step, some language models begin offering suggestions based on partial input. For example, autocomplete functions in email clients that predict next words or phrases fall into this category—they assist but require constant supervision from users who must review outputs before accepting them.

    Example: Gmail’s smart compose feature.

    Level 2: Semi-Autonomous Text Production

    At this stage, models can generate longer stretches of coherent text when given prompts—think about AI tools that draft emails or outline articles—but they still demand continuous oversight. Users need to supervise outputs actively because errors such as factual inaccuracies or inappropriate tone remain common pitfalls.

    Example: ChatGPT generating email drafts or article outlines.

    Level 3: Context-Aware Assistance

    Now we reach an intriguing analogy with conditional automation—where AI systems can handle complex tasks within certain constraints yet require humans to step back temporarily while remaining alert for potential issues. Large language models operating at this level might manage summarization tasks under specific domains (e.g., medical summaries) but could falter outside their trained scope.

    Example: Medical AI assistants that can summarize patient records but require doctor oversight.

    Level 4: Fully Autonomous Within Domains

    Imagine an AI-powered assistant capable of managing conversations entirely within predefined contexts—say customer service bots handling standard inquiries autonomously within specified industries—but unable beyond those limits without retraining or manual intervention.

    Example: Customer service chatbots for specific industries like banking or retail.

    Level 5: Fully Autonomous General Language Understanding

    Envisioning true “full autonomy” for language models means creating systems that understand context deeply across countless topics and produce accurate responses seamlessly everywhere—all without prompting from humans if desired. While such systems remain theoretical today, research aims toward developing general-purpose AI assistants capable not only of conversing fluently across domains but doing so responsibly without oversight.

    Example: Theoretical future AI systems that could operate across all domains without human oversight.

    Current State and Implications

    Now that we have a clear classification framework, let’s examine where we stand today and what this means for practical applications.

    What does this classification tell us about our current standing? Most contemporary large-scale language models sit somewhere around Levels 2 or early-Level 3—they generate impressive content when given prompts yet still struggle with consistency outside narrow contexts and require vigilant supervision by humans who evaluate accuracy critically.

    However, there’s an important limitation to the SAE analogy that we need to address.

    The Trust Dimension

    While the SAE levels offer a useful metaphor for understanding increasing autonomy, they aren’t a perfect fit for language models because:

    • Language models don’t act in the physical world themselves—humans interpret and act on their outputs
    • Risk and impact in NLP are mediated by human cognition and behavior, unlike the immediate physical risks of self-driving cars
    • Autonomy in NLP often deals more with semantic understanding, trustworthiness, context handling, and ethical alignment than sensor-actuator loops

    Therefore, I also propose a mapping of the SAE levels to trust levels taking into account cognitive load and responsibility:

    • Level 0: No trust: tool offers isolated corrections, requires full user oversight (spellcheck)
    • Level 1: Suggestive aid: user must review and approve every suggestion (autocomplete)
    • Level 2: Co-creator: user maintains active oversight, only defers in low-stakes contexts (drafting emails)
    • Level 3: Delegate: user maintains regular oversight with frequent spot checks and validation (10-20% review)
    • Level 4: Advisor: user maintains strategic oversight with periodic reviews (5-10% audit), especially for high-stakes outputs
    • Level 5: Agent: user maintains governance oversight with systematic audits (1-5% review) despite autonomous operation

    Practical Implications

    Classifying language models along SAE-like levels provides practical benefits:

    1. Common vocabulary for developers, researchers, policymakers, and end-users
    2. Realistic expectations about capabilities—the difference between tools assisting writing versus fully automating complex decision-making processes
    3. Regulatory guidance for ensuring safe deployment at each stage
    4. Effort per level is increasing, probably exponentially

    Design Priorities

    It’s vital not simply to categorize these technologies for academic interest but also because such clarity informs design priorities:

    • Should future efforts focus on improving reliability before granting more independence?
    • How do safety concerns evolve as we move up each level?
    • What ethical considerations arise when deploying increasingly autonomous NLP systems?

    Each incremental step toward higher levels demands careful consideration regarding:

    • Transparency: Can users understand when they’re interacting with an assistant versus an agent?
    • Accountability: Who bears responsibility if an AI-generated statement causes harm?

    Conclusion

    Applying SAE-level classifications offers more than just terminology—it provides a roadmap illustrating how far we’ve come and how much further we need to go in developing intelligent language systems capable not only of mimicking human conversation but doing so responsibly across diverse environments.

    Recognizing where current technology resides on this spectrum enables us all—from engineers designing smarter assistants to regulators crafting informed policies—to make conscious choices grounded in realistic assessments rather than hype or fear.

    As artificial intelligence continues its ascent along these levels—from rudimentary support towards full autonomy—the journey will demand ongoing collaboration among technologists, ethicists, policymakers, and ultimately society itself to ensure these powerful tools serve humanity’s best interests every step along the way.

    References

    SAE J3016™. “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles.” First published: 2014. Most recent version (as of 2024): SAE J3016_202104 (April 2021). 🔗 https://www.sae.org/standards/content/j3016_202104/

    Hoffman, R. R., Johnson, M., Bradshaw, J. M., & Underbrink, A. (2013). “Trust in automation.” IEEE Intelligent Systems, 28(1), 84–88. DOI: 10.1109/MIS.2013.24

  • Executive Summary: Application Lifecycle in EAM

    #architecture #clarity #velocity #direction

    Das Application Lifecycle Management (ALM) in LeanIX ist ein zentraler Bestandteil des Enterprise Architecture Managements (EAM). Es ermöglicht Unternehmen, den gesamten Lebenszyklus ihrer Anwendungen effektiv zu verwalten und zu optimieren. Dieser Prozess umfasst alle Phasen von der Planung und Entwicklung über den Betrieb bis hin zur Ablösung von Applikationen.

    LeanIX bietet als EAM-Tool umfangreiche Funktionen, um Application Owner bei der Verwaltung ihrer Anwendungen zu unterstützen. Es ermöglicht eine ganzheitliche Sicht auf die IT-Landschaft und hilft dabei, Abhängigkeiten, Risiken und Optimierungspotenziale zu identifizieren.

    In diesem Blog werden wir zunächst die Bedeutung des ALM für Application Owner erläutern und anschließend konkrete Verbesserungsvorschläge für die Umsetzung in LeanIX präsentieren. Ziel ist es, die Effizienz und Effektivität des Application Lifecycle Managements zu steigern und somit einen größeren Mehrwert für das Unternehmen zu schaffen.

    Sensibilisierung der Application Owner

    Um Application Owner, die mehrere Applikationen verantworten und der Meinung sind, dass sie LeanIX nicht benötigen, von der Wichtigkeit von EAM im allgemeines und des Tools im besonderen zu überzeugen, können folgende Testfragen mit Fokus auf Architektur, Prozesse und Daten gestellt werden:

    a) Architektur-bezogene Fragen:

    • Wie schnell können Sie herausfinden, welche Ihrer Applikationen von einer geplanten Infrastrukturänderung betroffen wären?
    • Welche Ihrer Applikationen nutzen veraltete Technologien und müssen in naher Zukunft modernisiert werden?

    b) Prozess-bezogene Fragen:

    • Wie würden Sie den Einfluss einer Ihrer Applikationen auf die gesamte Wertschöpfungskette des Unternehmens beschreiben?
    • Bei einem Ausfall einer Ihrer Applikationen: Wie schnell können Sie alle betroffenen Geschäftsprozesse identifizieren?

    c) Daten-bezogene Fragen:

    • Können Sie für jede Ihrer Applikationen die verarbeiteten Datenentitäten und deren Datenflüsse skizzieren?
    • Können Sie ad hoc angeben, welche Ihrer Applikationen personenbezogene Daten verarbeiten und wie diese geschützt werden?

    d) Übergreifende Fragen:

    • Wie schnell können Sie bei einer Audit-Anfrage alle relevanten Informationen zu Ihren Applikationen zusammenstellen?
    • Wie stellen Sie sicher, dass alle Stakeholder stets über den aktuellen Stand und geplante Änderungen Ihrer Applikationen informiert sind?

    Verbesserungsvorschläge für Application Lifecycle Management in LeanIX

    Um Application Owner bei der Pflege ihrer Applikationen in LeanIX zu unterstützen, die Unternehmensarchitektur stärker am Business auszurichten und den Zusammenhang zum Datenmanagement zu nutzen, schlage ich folgende konkrete Aktivitäten als Diskussionsgrundlage vor:

    1. Schulungen und Workshops für Application Owner:
      • Organisieren Sie regelmäßige Schulungen zu LeanIX und Best Practices
      • Führen Sie Workshops durch, die den Zusammenhang zwischen Applikationen, Geschäftsprozessen und Daten verdeutlichen
      • Erstellen Sie praxisnahe Leitfäden und Checklisten für die Pflege von Applikationen in LeanIX in einem leicht zugänglichen Werkzeug wie z. B. Confluence
      • Erstellen Sie LeanIX-Surveys, über die Application Owner relevante Informationen einfach durch Beantwortung zugeschnittener Fragenkataloge vornehmen können
    2. Prozessorientierte Modellierung in LeanIX:
      • Implementieren Sie eine prozessorientierte Sicht in LeanIX
      • Verknüpfen Sie Applikationen mit den unterstützten Geschäftsprozessen
      • Visualisieren Sie den Beitrag jeder Applikation zur Wertschöpfungskette
    3. Integration von Datenmanagement-Aspekten:
      • Erweitern Sie das LeanIX-Metamodell um relevante Datenmanagement-Attribute
      • Verknüpfen Sie Applikationen mit den von ihnen verarbeiteten Datenentitäten
      • Implementieren Sie Datenflussdiagramme, die den Zusammenhang zwischen Applikationen und Daten zeigen
    4. Automatisierung und Integration:
      • Implementieren Sie Schnittstellen zwischen LeanIX und anderen relevanten Tools (z.B. BPM, Data Management Platform)
      • Automatisieren Sie die Aktualisierung von Basis-Informationen in LeanIX
      • Erstellen Sie Dashboards, die den Pflegestatus und die Datenqualität visualisieren
    5. Governance und Anreize:
      • Etablieren Sie klare Verantwortlichkeiten und SLAs für die Pflege von Applikationsinformationen
      • Implementieren Sie ein Belohnungssystem für Application Owner, die ihre Daten aktuell halten
      • Führen Sie regelmäßige Reviews der Applikationslandschaft durch
    6. Daten-Governance Integration:
      • Verknüpfen Sie Daten-Governance-Rollen (z.B. Data Owner, Data Steward) mit den entsprechenden Applikationen in LeanIX
      • Implementieren Sie Attribute für Datenklassifizierung und Datenschutzanforderungen bei Applikationen
      • Erstellen Sie Reports, die Daten-Governance-Aspekte über die gesamte Applikationslandschaft hinweg zeigen
    7. Kontinuierliche Verbesserung:
      • Etablieren Sie einen regelmäßigen Feedback-Prozess mit Application Ownern
      • Analysieren Sie Nutzungsmuster in LeanIX, um Verbesserungspotenziale zu identifizieren
      • Passen Sie das Metamodell und die Prozesse basierend auf dem Feedback kontinuierlich an
  • Exploring AI’s Impact on Jobs: Task-Based Analysis

    DALL·E 2024-05-31 18.19.33 - A futuristic workspace with a systems engineer working on a computer. The engineer is surrounded by holographic interfaces displaying elements aligned
    AI Integration in Systems Engineering, produced using DALL-E, 2024-05-31

    In the landscape of rapid technological advancement, the intersection of Artificial Intelligence (AI) and job roles is a topic of intense discussion. As Salman Khan insightfully points out in his new book “Brave New Words,” people aren’t replaced by AI but by individuals who leverage AI more productively. This perspective, while intriguing, calls for a deeper exploration of how AI impacts various job roles in today’s market.

    Understanding AI’s Impact on Systems Engineering

    One fascinating approach to gauge AI’s influence on jobs is proposed by There’s an AI for That. The website offers an ‘Impact Index’ for various job roles, including Software Engineer, Systems Engineer, Mechanical Engineer, and thousands of others. This index is calculated based on the number of AI applications that support tasks related to these roles. While specific and limited, this approach provides a more concrete perspective than speculative opinions like ‘I believe AI will never …’ or ‘Everybody will loose their jobs’ that are vague beliefs at best and sometimes even cause unnecessary alarm.

    Breaking Down Job Roles into Tasks

    To truly understand AI’s impact on jobs, it’s essential to break them down into their constituent tasks. For each task, we must examine whether AI can already support it effectively, whether AI needs refinement or regulation, or whether AI is currently incapable of supporting the task.

    Sal Khan’s book serves as a real eye-opener in this context illuminating what can be achieved in one year if you go all in. E. g., the one-on-one AI tutor called ‘Khanmigo’ initially gone live along GPT-4 shall not give the final answers right away, but instead guide the student step by step (a so-called Socratic tutor). It can summarize the learning process and give valuable feedback to the teacher incl. recommendations. It can even identify weak spots the teacher might wish to focus on. And it assists the teacher in creating lesson plans saving a lot of time and freeing resources.

    Drawing inspiration from this work, one could investigate systems engineering in a similar vein and develop an ‘MBSEamigo’ analogous to ‘Khanmigo’. The core idea here is to redefine roles based on tasks. In situations where role definitions vary, the strategy would be to identify common denominators and refine roles down to the tasks.

    For instance, consider the role of a systems engineer. This job can be broken down into approximately 1,000 tasks. Each task can then be assessed for AI impact. Here’s a glimpse into some typical tasks and their AI impact:

    • Running Coach: AI Impact: 100% | AIs: 12
    • Codebase Q&A: AI Impact: 95% | AIs: 9
    • Problem Solving: AI Impact: 90% | AIs: 15
    • Diagrams: AI Impact: 50% | AIs: 12
    • Data Protection: AI Impact: 50% | AIs: 4
    • Conversations with Clients: AI Impact: 50% | AIs: 1
    • Audits: AI Impact: 5% | AIs: 1
    • 3D Images: AI Impact: 5% | AIs: 22

    A Closer Look at Key Tasks

    Running Coach (AI Impact: 100%)

    In systems engineering, optimizing processes and workflows is crucial. AI tools can act as running coaches, continuously analyzing and improving these processes with precision and speed. For example, AI can automate routine checks and suggest improvements, ensuring systems run smoothly and efficiently.

    Codebase Q&A (AI Impact: 95%)

    AI-driven tools like code analyzers and automated testing frameworks significantly enhance codebase management. They can identify bugs, suggest fixes, and predict potential issues before they become critical, thereby reducing downtime and increasing productivity.

    Problem Solving (AI Impact: 90%)

    AI excels in problem-solving by offering data-driven insights and predictive analytics. For systems engineers, this means quicker diagnosis of issues and more effective solutions. AI can simulate various scenarios to find the most optimal solutions, saving time and resources.

    Applying Foundational Engineering Principles

    Incorporating AI into systems engineering must align with foundational engineering principles. This means ensuring that AI tools are used to enhance precision, reliability, and efficiency. Systems engineers should focus on maintaining robustness and accuracy in their projects while leveraging AI to handle repetitive and data-intensive tasks.

    To do this:

    • Verification and Validation: Regularly test AI tools to ensure they produce reliable and accurate results.
    • System Integration: Seamlessly integrate AI into existing systems without disrupting core functionalities.
    • Continuous Improvement: Use AI for ongoing analysis and optimization of engineering processes.
    • Documentation and Transparency: Keep thorough documentation of AI’s role and decisions in the engineering process for transparency and traceability.

    The Future of Systems Engineering with AI

    The journey of AI in systems engineering is just beginning. By continually refining AI tools and expanding their capabilities, we can create more efficient, innovative, and secure systems.

    As highlighted in Engineering.com, AI has the potential to revolutionize engineering by automating complex tasks, predicting system behaviors, and providing advanced analytics. Currently, using tools requires understanding how to manipulate and connect various elements, which involves tedious tasks like moving the mouse around. This repetitive work, similar to past challenges in the CAD world, is expected to be minimized in the future.

    SElive also identifies potential AI use cases. This integration not only boosts productivity but also fosters innovation by enabling engineers to focus on more strategic and creative aspects of system development. One notable example is the Technology Summarizer, which employs AI algorithms to analyze and condense vast amounts of technical documentation. This tool helps engineers quickly grasp essential information, stay updated with the latest advancements, and make informed decisions without being bogged down by extensive reading.

    The upcoming book “AI Assisted MBSE with SysML by Doug Rosenberg, Tim Weilkiens (mbse4u.com))” explores the integration of Artificial Intelligence in Model-Based Systems Engineering (MBSE) using the Systems Modeling Language (SysML). It highlights how AI can automate and enhance various MBSE tasks and provides methodologies along a comprehensive, step-by-step design of a Scanning Electron Microscope.

    Final Thoughts

    The integration of AI in the job market isn’t about replacement but about redefining roles and tasks so AI can be leveraged for increased productivity. The key lies in understanding AI’s impact on individual tasks and adapting job roles accordingly. As AI continues to evolve, our approach to integrating it into our workflows must also adapt, ensuring we stay ahead in this dynamic field.

    I am convinced that we will see a net job effect again as we have been seeing with automation. To the younger generations: experts are still needed. Do not let social media make you panic! Anybody can get anything out of ChatGPT, but only the expert speaks the sophisticated language of a discipline achieving much better results that also need to be curated by the very same expert.

  • Domain-Specific Languages explained for Stakeholders

    Imagine you’re in a bustling professional kitchen. The heat, the noise, the coordinated chaos. This is a lot like software development, and you’re about to see why.

    Get your introduction to the concept and benefits of Domain-Specific Languages (DSLs). It’s quite a topic, but this culinary journey will make it, well, digestible.

    professional kitchen in a well-managed restaurant
    https://labs.openai.com/s/3mptF5d1dlDf7HmyqcgvCn1M

    5-minute read:
    Domain-Specific Languages explained for Stakeholders (mem.ai)

    Summary

    Amuse-Bouche (Software Development through Cooking): Welcome to the kitchen, where every role, from the head chef to the dishwasher, has a counterpart in a software development team.

    Appetizer (Recipes do change with Time): Just as orders in a kitchen can change based on customer feedback or ingredient availability, tasks in software development are also adjusted in response to feedback and constraints.

    Main Course (Managing Complexity for a growing Kitchen): As our kitchen grows, we need tools and techniques to manage the complexity. Imagine a Kitchen Modeling Language (KitchenML) that helps us coordinate all the moving parts.

    Dessert: Finally, let’s reflect on our journey. We’ve seen how a kitchen and a software development team can be similar, but also how they differ. One is physical and sequential, the other virtual and iterative.