ELCA Group’s Post

📢 JARVIS - 2/TBD In one of my last post, I introduced JARVIS. Today, let's explore its first module, ProcMap, the Process Mapper. ProcMap converts a user’s verbal description of their workflow into a Business Process Model (BPM) diagram. Although it appears straightforward, requiring only a few clicks, it was designed to address the challenges of manually understanding and visualizing complex business processes, which can be time-consuming and error-prone. It's also the first and only multi-swimlane BPMN converter, something that hasn't existed before. While this might not sound fancy, process engineering experts will understand its significance. ✨ Here's how it works: 1. The user provides their input in any language, and Whisper Medium converts it to an English transcript. 2. ProcMap analyzes this transcript to identify key business activities and resources. 3. It links activities to the relevant people and resources. If it encounters unclear information, it flags it for user feedback to resolve ambiguities. 4. Once all ambiguities are clarified, ProcMap creates a visual Business Process Model and Notation (BPMN) diagram that's easy to edit and understand. ✨ Behind the Scenes: 1. Participant Extraction: ProcMap uses dependency parsing to identify participants based on syntactic roles. It refines this with a multi-step validation process using hypernyms and keywords for semantic accuracy. 2. Relationship Extraction: The system extracts Subject-Verb-Object (SVO) structures to capture core sentence meaning. It accounts for passive voice and conjunctions while comparing SVOs against participants. 3. Alias Detection: Tokenization and word similarity algorithms identify aliases by comparing shared tokens, further enhanced by syntactic and semantic analysis for complex conditional phrases. In depth detail can be found in the following paper we wrote: https://lnkd.in/dTvMvv5A By blending speech-to-text conversion, data processing, and model generation, ProcMap ensures that the entire business process is captured accurately and efficiently, empowering organizations to optimize their workflows. Sara Qayyum - Fouzan Yaseen

Sema has just announced the latest release of standards for software teams using GenAI to code. These standards came about as a result of thorough external research on the benefits and risk mitigation for using such tools, input from the AI Advisory Council, and data analysis from Sema's propriety database of GenAI coding usage among leading software teams and investors. There is no change in the standards for blending GenAI code-- it remains critical for engineering teams using GenAI to take the LLM output and modify it. This addresses maintainability risk, security risk, IP risk, and exit risk. As with so much AI usage, "Humans in the Loop" are critical for responsible AI usage. What has changed is a significant increase in the recommended range for using GenAI tools-- now at 15-30% of new code, up from 5-20%. The evidence from the past six months is compelling that GenAI tools can make a significant, positive, impact on developer satisfaction and productivity. Therefore software organizations who aren't using GenAI at least at those levels are missing a significant opportunity. Interested in learning more? Contact us at ai@semasoftware.com. https://lnkd.in/eAFMJXny

Important news from Sema's Research team: we have released the newest standards for safe and effective GenAI tools usage for coding. The big change is that there is now a significant increase in the recommended range of GenAI usage, now at 15-30% of new code. The evidence is clear that GenAI can really help developers and the risks are mitigatable.

I just started a new course, "Introduction to Generative AI for Software Development," featuring Laurence Moroney. It begins with a conversation between Moroney and Andrew Ng about the future of software development in the era of generative AI. Something Moroney said struck home: > Sometimes, when we start building a system, we start at the whiteboard, and we start drawing all these boxes and arrows between them and thinking about the constraints. And given the idea that today we generate code, or we generate documentation, or we generate test cases and other things from a prompt, it might be very interesting that in the not too distant future, those system specification designs that we draw on, those boxes on a whiteboard could be the next prompt. And to be able to design systems off of those with multimodal models now being able to recognize imagery and being able to parse that kind of thing, that I can see that going back to that domain expertise, that when you have a domain expertise to solve a particular problem and you can draw the architecture of that, that architecture can be implicitly turned into code which would execute, and you may not even be interfacing that much with raw code unless you want to tweak and debug. It's like five years from now, that could be a way that software developers will be even more effective. And it's something that I'm looking forward to. Business Process Model and Notion (BPMN) diagrams are already used to orchestrate software execution (see Camunda and SpiffWorkflow). BPMN 2.0 XML files underpin the visual models we create with BPMN. It may be sooner than five years before we can create executable code from a well-constructed process model. It may be a good idea to learn BPMN. Here's a place to start: https://lnkd.in/gk75mydh

The scenario below provides a practical case study demonstrating how to implement the concepts from the video "Architects Live in the First Derivative" by Gregor Hohpe. -- A financial firm is modernizing by adopting AI, cloud-native architecture, and resilient systems to support informed decision-making and ensure that its systems are adaptable and resilient, 1. Enabling businesses with flexibility to make informed decisions The firm uses AI-driven analytics to process real-time data, providing insights into market trends, risk assessment, and customer behavior. It helps them make data-driven decisions quickly as conditions change. Adopting a cloud-native architecture enables it to scale resources dynamically, access analytics services, and deploy new financial products rapidly to respond to changing market conditions. 2. Prioritizing adaptability and responsiveness to change The firm prioritizes adaptability and responsiveness by adopting an API-first design and implementing Event-Driven Architecture (EDA). This approach facilitates integrating new services and third-party applications. It enables the firm to adapt its offerings without extensive rework, ensuring high responsiveness to various events and enabling the system to adapt to new information or conditions promptly. 3. Designing systems for overall performance and adaptability The firm designed its systems for overall performance and adaptability by structuring its software around its business domains using Domain-Driven Design (DDD) to align software architecture with business needs, ensuring adaptability and straightforward modifications as needs evolve. The firm has established CI/CD pipelines for rapid change adaptation and continuous delivery of new features. The system includes comprehensive observability and monitoring for real-time performance insights, allowing proactive issue detection and addressing to maintain overall performance and reliability. The firm practices chaos engineering to test the system's resilience, identify vulnerabilities, and ensure the architecture can adapt and maintain performance under adverse conditions. The architecture uses decoupling and modularization principles for easier scaling and maintenance. Implementation The architecture uses cloud services and AI for analytics. APIs enable integration, while EDA ensures event responsiveness. DDD aligns with business needs, and CI/CD enables rapid change adaptation. Observability tools monitor system health, and chaos engineering tests resilience. The modular, decoupled design supports scalability and maintainability. Outcome The financial services firm now operates a highly adaptable and responsive system that supports informed decision-making and rapid response to market changes. The architecture's emphasis on overall performance and adaptability ensures the firm competitiveness in the dynamic financial sector. The video is on YouTube. https://lnkd.in/dGQA7HBs #softwarearchitecture

When working on large systems, complexity can quickly become overwhelming. That’s where Domain-Driven Design (DDD) steps in. DDD helps structure your software around the business domain you’re solving problems for, making it easier to manage and scale. 🤘 HOW IT WORKS: 1. FOCUS ON THE BUSINESS: The first step in DDD is to fully understand the business problem. Instead of diving straight into the code or technical details, you work closely with domain experts to capture the real-world business logic and design your system based on that. 2. BOUNDED CONTEXTS: Large systems are split into smaller sections called "bounded contexts." Each of these sections handles a specific domain (like payment processing or customer management). This way, each part of the system is focused on its own business area, reducing complexity. Bounded contexts also help prevent different parts of the system from getting tangled up with each other. 3. UBIQUITOUS LANGUAGE: One of the key principles in DDD is using a shared language between developers and business experts. This means that everyone talks about the system using the same terms, ensuring everyone is aligned. This "ubiquitous language" becomes the core vocabulary for communication throughout the project. 🤘 WHY IT MATTERS: In large systems, it's easy to lose sight of the bigger picture. DDD helps keep the system focused on solving the right problems by aligning the software directly with the business needs. This makes it easier to maintain, extend, and scale over time, especially when teams grow or the system becomes more complex. By breaking the system into smaller, manageable pieces and using a shared language, DDD keeps everyone on the same page—from business stakeholders to developers—ensuring the project stays true to its goals. #DomainDrivenDesign #DDD #SoftwareArchitecture #SystemDesign #BoundedContexts #BusinessLogic #LargeSystems #TechStrategy #UbiquitousLanguage #SoftwareDevelopment

Outcomes are essential for Advisory. Our ITOps Tech. Advisory Services... Advises, Architects, Solutions, and Implements those solutions, removing the traditional gap between standalone Advisory and execution teams. Recent Advisory outcome wins, An Observability/AIOps Advisory led MVP recently saved one client over 1.4M in revenue downtime cost avoidance in three months time. (client outcome) A Generative AI for ITOps Advisory Assessment helped another client team discover 10 thousand hours a month of reoccurring productivity savings in ITOps utilizing a GenAI future state roadmap, dataplane strategy, and a value-aligned implementation plan. (Precursor business case to automation and augmentation outcome)

🚩Decision Intelligence should N🚫T become about #ai #llms #machinelearning and all fancy algorithms in data science. #DecisionIntelligence is a thinking framework that enables organizations to re-engineer business decisions, meaning to understand how they are made, and how outcomes are evaluated. It also enables organizations to realize how to improve business decisions and ensure they are aligned with business objectives. In this context, the business decision itself is not #data #businessrule #process and etc. A business decision is a business decision and should be treated and managed as a fundamental entity in organizations across the enterprise. How do you model a business decision? 💢There are many approaches to modeling business decisions. But acting as if they are a #BusinessProcess or #BusinessRule is not one of them. In this context, modeling is not just illustrating a business decision; it is producing an artifact representing the business decision that can be executed without extra steps of coding and programming. ✨Business decisions can be modeled in different ways, but the most effective ones are either using: 1️⃣ Decision Requirements Diagram or DRD - part of Decision Model and Notation (DMN) open standard which allows modeling of multi-step business decisions. This technique is mostly used for rule-driven decisions. 2️⃣ Decision Graph - A graph of decision unit components representing a multi-step, hierarchical, and situation-aware business decision enabling organizations to model complex transient and long-running decisions. This technique combines #rules #machinelearning #optimization and #data processing in a single unified decision model. Decision Graph is an advanced version of Decision Requirements Diagram that supports stateful and situation-aware decisions. 💣By modeling business decisions using DRD or DecisionGraph, you specify how decisions are made, and the models themselves become the live specifications and documentation of the decision-making scenario. (The ⚠️ caveat is that if you choose Decision Requirement Diagrams from the Decision Model and Notation (DMN) standard, they must be at Conformance Level 3; otherwise, they are not executable, just pretty pictures.) Learn more on how to model business decisions using DMN at 👇

Refactoring API Agents as Proc Workflows In my ongoing project, I've identified an opportunity to optimize the system by converting API agents into proc workflows. Proc workflows allow While the initial API workflow was an effective way to test and implement the design, I've found that proc workflows can streamline the process and reduce hard-coded elements. I'm focusing on creating general JSON api handling agents first, as this aligns with my current priorities in building ai agents that can pipeline results. In the future, supporting XML will only require minor adjustments, such as updating the message builder, building the header, and processing the XML result return. And it should be possible to have a general conversion agent that can convert between compatible formats. To allow agents access to information stored in the configuration file, I've added an accessor method to read information from the configuration file in a flexible way that is similar to how we already access data. This allows me to pass required data as input parameters to the agents. Last night, I also introduced recursion capabilities, enabling the evaluation of a workflow within another workflow. Both of these improvements were crucial for advancing the revised design approach. I anticipate that these changes will not only make the system more efficient and flexible but also reduce the codebase by approximately almost half.