{"id":1392,"date":"2026-02-25T10:40:49","date_gmt":"2026-02-25T10:40:49","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/"},"modified":"2026-02-25T10:40:49","modified_gmt":"2026-02-25T10:40:49","slug":"lightweight-vs-formal-uml","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/","title":{"rendered":"The Right Level of Modeling: Lightweight vs. Formal UML"},"content":{"rendered":"<p>Most teams don\u2019t fail because they don\u2019t know UML\u2014they fail because they apply it at the wrong level. I\u2019ve seen startups waste weeks documenting every class interaction in a system that never shipped. I\u2019ve also seen enterprises misinterpret a sketch as a design contract, leading to costly rework. The real decision isn\u2019t between using UML or not\u2014it\u2019s about using the right kind of UML for the context.<\/p>\n<p>UML modeling approaches aren\u2019t one-size-fits-all. What works for a microservices team in a rapid iteration cycle might cripple a regulated financial system requiring audit trails. The key is understanding your project\u2019s constraints, audience, and lifecycle stage.<\/p>\n<p>This chapter walks you through how to assess when to use lightweight UML for quick alignment, and when to invest in formal UML diagrams for rigorous design and compliance. You\u2019ll learn to balance speed, clarity, and precision\u2014without over-engineering or under-documenting.<\/p>\n<h2>Understanding the Two Ends of the UML Spectrum<\/h2>\n<h3>What Is Lightweight UML?<\/h3>\n<p>Lightweight UML isn\u2019t a formal subset\u2014it\u2019s a mindset. It means using UML notation pragmatically: quick sketches, minimal notation, focus on communication, not perfection.<\/p>\n<p>It\u2019s when you draw a class diagram on a whiteboard during a sprint planning session. Or sketch a sequence diagram to explain a new API interaction in a Slack thread. These aren\u2019t deliverables. They\u2019re tools for thinking and alignment.<\/p>\n<p>Some common traits of lightweight UML:<\/p>\n<ul>\n<li>Created with pen and paper, a digital whiteboard, or a simple diagram tool.<\/li>\n<li>Designed for internal team discussion, not external stakeholders.<\/li>\n<li>May omit multiplicities, constraints, or detailed attributes.<\/li>\n<li>Versioned informally\u2014often deleted after the meeting.<\/li>\n<li>Used to surface assumptions, clarify flows, or guide implementation.<\/li>\n<\/ul>\n<h3>What Are Formal UML Diagrams?<\/h3>\n<p>Formal UML diagrams are more than visualizations\u2014they\u2019re precise, documented artifacts. They\u2019re built in dedicated modeling tools like Visual Paradigm, comply with UML standards (OMG), and serve as legal or technical contracts.<\/p>\n<p>These are the diagrams that accompany a software release, are reviewed by QA and architecture boards, and referenced in training materials or audit logs. They\u2019re used when consistency, traceability, and precision matter.<\/p>\n<p>Key characteristics:<\/p>\n<ul>\n<li>Generated in a modeling tool with proper syntax and validation.<\/li>\n<li>Version-controlled, with change logs and approval workflows.<\/li>\n<li>Include full notation: inheritance, multiplicities, constraints, visibility.<\/li>\n<li>Linked to requirements, code, and test cases via traceability matrices.<\/li>\n<li>Used across teams, departments, or even organizations.<\/li>\n<\/ul>\n<h2>When to Use Lightweight UML<\/h2>\n<p>Lightweight UML shines in early discovery and fast-moving teams. It\u2019s not a fallback\u2014it\u2019s a deliberate choice.<\/p>\n<p>Here are situations where lightweight UML is not just acceptable, but optimal:<\/p>\n<h3>1. Sprint Planning and Ideation<\/h3>\n<p>When the team is brainstorming features, a 5-minute sketch on a whiteboard can clarify whether a user story needs a new service or just a state change in an existing one.<\/p>\n<p>You\u2019re not modeling behavior yet\u2014you\u2019re exploring possibilities. A simple class diagram with three components is enough to agree on scope.<\/p>\n<h3>2. Cross-Functional Team Alignment<\/h3>\n<p>When developers, product managers, and UX designers aren\u2019t fluent in full UML, lightweight UML bridges the gap.<\/p>\n<p>Use a use case sketch to communicate workflow. Draw a sequence diagram to illustrate a user login flow. The goal isn\u2019t correctness\u2014it\u2019s shared understanding.<\/p>\n<h3>3. Rapid Prototyping and Proof-of-Concepts<\/h3>\n<p>When you\u2019re testing a new architecture or validating an idea, spending hours on formal notation is a waste of time.<\/p>\n<p>Lightweight UML lets you explore structure and behavior quickly. You can build a prototype, test it, and iterate before formalizing anything.<\/p>\n<p>Remember: prototypes don\u2019t need to be perfect\u2014they just need to be useful.<\/p>\n<h2>When to Use Formal UML Diagrams<\/h2>\n<p>Formal UML diagrams are not about complexity\u2014they\u2019re about accountability. They exist where ambiguity is not an option.<\/p>\n<h3>1. Regulatory or Compliance-Critical Systems<\/h3>\n<p>Financial, healthcare, and aerospace systems often require documentation for audits. In these cases, a diagram must be verifiable, traceable, and stable.<\/p>\n<p>A formal UML class diagram isn\u2019t just a sketch\u2014it\u2019s part of a larger system specification. It must show relationships, constraints, and behavior in full compliance with standards.<\/p>\n<h3>2. Large-Scale, Multi-Team Projects<\/h3>\n<p>When multiple teams are building interconnected services, alignment is non-negotiable. A lightweight sketch might be misinterpreted across teams.<\/p>\n<p>Formal UML diagrams, version-controlled and shared via a central repository, ensure consistency. A deployment diagram with accurate node types and communication paths prevents integration failures.<\/p>\n<h3>3. Legacy System Modernization<\/h3>\n<p>Reverse-engineering an old monolith? You need formal UML diagrams to understand the actual structure, not assumptions.<\/p>\n<p>These diagrams become the foundation for refactoring. They help answer: Which components are tightly coupled? What are the real dependencies? Who owns the data flow?<\/p>\n<h3>4. Technical Documentation and Training<\/h3>\n<p>When you&#8217;re training new engineers, formal diagrams are essential. A standardized, validated diagram ensures everyone sees the same system structure.<\/p>\n<p>Compare this to a hand-drawn sketch that changes every week. One team sees a class named \u201cOrderService,\u201d another sees it as \u201cBillingEngine.\u201d That\u2019s a recipe for confusion.<\/p>\n<h2>Decision Framework: Lightweight vs Formal UML<\/h2>\n<p>To help you decide, consider this decision matrix:<\/p>\n<table>\n<tbody>\n<tr>\n<th>Factor<\/th>\n<th>Lightweight UML<\/th>\n<th>Formal UML<\/th>\n<\/tr>\n<tr>\n<td>Project Stage<\/td>\n<td>Ideation, early design, spike<\/td>\n<td>Planning, review, release<\/td>\n<\/tr>\n<tr>\n<td>Team Size<\/td>\n<td>Small (2\u20135), co-located<\/td>\n<td>Large, distributed<\/td>\n<\/tr>\n<tr>\n<td>Stakeholders<\/td>\n<td>Internal team only<\/td>\n<td>Regulators, auditors, cross-functional teams<\/td>\n<\/tr>\n<tr>\n<td>Longevity<\/td>\n<td>Short-term, ephemeral<\/td>\n<td>Long-term, versioned<\/td>\n<\/tr>\n<tr>\n<td>Change Frequency<\/td>\n<td>High (daily)<\/td>\n<td>Low (after review)<\/td>\n<\/tr>\n<tr>\n<td>Traceability Needs<\/td>\n<td>None<\/td>\n<td>High (linked to requirements, code)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Ask yourself: Does this diagram need to be referenced in a year? Will someone outside the team need to understand it? Is it part of a compliance process? If yes, move toward formal UML.<\/p>\n<p>If the answer is no, lightweight UML is likely sufficient.<\/p>\n<h2>Practical Tips for Effective Modeling<\/h2>\n<p>Here are five principles I\u2019ve seen work consistently across dozens of teams:<\/p>\n<ol>\n<li><strong>Start lightweight, then formalize.<\/strong> Begin with a sketch to explore, then invest in formal diagrams only when precision is needed.<\/li>\n<li><strong>Use the right tool for the job.<\/strong> A whiteboard is better for ideation. Visual Paradigm is better for compliance.<\/li>\n<li><strong>Document the intent, not just the structure.<\/strong> A note explaining \u201cThis class handles payment validation\u201d is more valuable than perfect notation.<\/li>\n<li><strong>Don\u2019t over-model for clarity.<\/strong> A diagram with 50 classes and 100 relationships is not better\u2014unless it\u2019s necessary.<\/li>\n<li><strong>Review the purpose, not the diagram.<\/strong> Ask: \u201cWho will use this? What will they need to do with it?\u201d<\/li>\n<\/ol>\n<h2>Bottom Line: Context Is the Ultimate Guide<\/h2>\n<p>There\u2019s no \u201cbest\u201d approach. The best UML modeling approach is the one that fits your context.<\/p>\n<p>Lightweight UML is for exploration. Formal UML is for execution. The most effective teams don\u2019t choose one or the other\u2014they use both, at the right time, for the right reason.<\/p>\n<p>Don\u2019t let the pressure to \u201cdo it right\u201d stop you from doing it fast. And don\u2019t let speed compromise the integrity of what matters. The goal isn\u2019t to draw every line perfectly\u2014it\u2019s to build systems that work, evolve, and serve their users.<\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>When should I avoid using formal UML diagrams?<\/h3>\n<p>Avoid formal UML when the audience is internal, the timeline is short, or the system is still experimental. Over-documentation at this stage slows down progress and creates maintenance overhead.<\/p>\n<h3>Can I use lightweight UML in a regulated industry?<\/h3>\n<p>Yes\u2014but only for internal communication. You can sketch ideas in meetings, but final documentation must still meet compliance standards. Lightweight UML is a tool for thinking, not a replacement for audit-ready diagrams.<\/p>\n<h3>How do I know when a sketch is \u201cgood enough\u201d?<\/h3>\n<p>A sketch is good enough when it enables agreement, eliminates misunderstandings, and guides implementation without requiring rework. If the team can point to it and say \u201cThat\u2019s how we\u2019re doing this,\u201d it\u2019s working.<\/p>\n<h3>Is lightweight UML less professional than formal UML?<\/h3>\n<p>No. The professionalism lies in choosing the right tool for the situation. Using formal diagrams in a prototype is less professional than using a sketch. The key is intentionality\u2014not the level of detail.<\/p>\n<h3>Can I convert lightweight UML to formal UML later?<\/h3>\n<p>Yes\u2014this is common in agile environments. Use the sketch as a foundation. Then, refine it in a modeling tool with validation, versioning, and traceability features. Just don\u2019t delay the conversion until it\u2019s too late.<\/p>\n<h3>What\u2019s the biggest mistake teams make with UML modeling approaches?<\/h3>\n<p>Forcing formal UML on everything. It creates unnecessary overhead, delays decision-making, and demotivates teams. The reverse\u2014never formalizing\u2014also fails: when system complexity grows, a sketch becomes a liability.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Most teams don\u2019t fail because they don\u2019t know UML\u2014they fail because they apply it at the wrong level. I\u2019ve seen startups waste weeks documenting every class interaction in a system that never shipped. I\u2019ve also seen enterprises misinterpret a sketch as a design contract, leading to costly rework. The real decision isn\u2019t between using UML [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":1390,"menu_order":1,"template":"","meta":{"_acf_changed":false,"inline_featured_image":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"doc_tag":[],"class_list":["post-1392","docs","type-docs","status-publish","hentry"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Lightweight vs Formal UML: Choosing the Right Modeling Approach<\/title>\n<meta name=\"description\" content=\"Learn when to use lightweight UML sketching vs formal UML diagrams. Practical guidance for teams on choosing the right UML modeling approaches for real-world software design.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/\" \/>\n<meta property=\"og:locale\" content=\"id_ID\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Lightweight vs Formal UML: Choosing the Right Modeling Approach\" \/>\n<meta property=\"og:description\" content=\"Learn when to use lightweight UML sketching vs formal UML diagrams. Practical guidance for teams on choosing the right UML modeling approaches for real-world software design.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/\" \/>\n<meta property=\"og:site_name\" content=\"Visual Paradigm Skills Indonesia\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Estimasi waktu membaca\" \/>\n\t<meta name=\"twitter:data1\" content=\"7 menit\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/\",\"name\":\"Lightweight vs Formal UML: Choosing the Right Modeling Approach\",\"isPartOf\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#website\"},\"datePublished\":\"2026-02-25T10:40:49+00:00\",\"description\":\"Learn when to use lightweight UML sketching vs formal UML diagrams. Practical guidance for teams on choosing the right UML modeling approaches for real-world software design.\",\"breadcrumb\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/#breadcrumb\"},\"inLanguage\":\"id\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/skills.visual-paradigm.com\/id\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Real-World UML: Case Studies in Software Design\",\"item\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Foundations of Practical UML\",\"item\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"The Right Level of Modeling: Lightweight vs. Formal UML\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#website\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/\",\"name\":\"Visual Paradigm Skills Indonesia\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/skills.visual-paradigm.com\/id\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"id\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#organization\",\"name\":\"Visual Paradigm Skills Indonesia\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"id\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg\",\"contentUrl\":\"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg\",\"width\":70,\"height\":70,\"caption\":\"Visual Paradigm Skills Indonesia\"},\"image\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Lightweight vs Formal UML: Choosing the Right Modeling Approach","description":"Learn when to use lightweight UML sketching vs formal UML diagrams. Practical guidance for teams on choosing the right UML modeling approaches for real-world software design.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/","og_locale":"id_ID","og_type":"article","og_title":"Lightweight vs Formal UML: Choosing the Right Modeling Approach","og_description":"Learn when to use lightweight UML sketching vs formal UML diagrams. Practical guidance for teams on choosing the right UML modeling approaches for real-world software design.","og_url":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/","og_site_name":"Visual Paradigm Skills Indonesia","twitter_card":"summary_large_image","twitter_misc":{"Estimasi waktu membaca":"7 menit"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/","url":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/","name":"Lightweight vs Formal UML: Choosing the Right Modeling Approach","isPartOf":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/#website"},"datePublished":"2026-02-25T10:40:49+00:00","description":"Learn when to use lightweight UML sketching vs formal UML diagrams. Practical guidance for teams on choosing the right UML modeling approaches for real-world software design.","breadcrumb":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/#breadcrumb"},"inLanguage":"id","potentialAction":[{"@type":"ReadAction","target":["https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/lightweight-vs-formal-uml\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/skills.visual-paradigm.com\/id\/"},{"@type":"ListItem","position":2,"name":"Real-World UML: Case Studies in Software Design","item":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/"},{"@type":"ListItem","position":3,"name":"Foundations of Practical UML","item":"https:\/\/skills.visual-paradigm.com\/id\/docs\/real-world-uml-case-studies-software-design\/foundations-of-practical-uml\/"},{"@type":"ListItem","position":4,"name":"The Right Level of Modeling: Lightweight vs. Formal UML"}]},{"@type":"WebSite","@id":"https:\/\/skills.visual-paradigm.com\/id\/#website","url":"https:\/\/skills.visual-paradigm.com\/id\/","name":"Visual Paradigm Skills Indonesia","description":"","publisher":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/skills.visual-paradigm.com\/id\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"id"},{"@type":"Organization","@id":"https:\/\/skills.visual-paradigm.com\/id\/#organization","name":"Visual Paradigm Skills Indonesia","url":"https:\/\/skills.visual-paradigm.com\/id\/","logo":{"@type":"ImageObject","inLanguage":"id","@id":"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/","url":"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg","contentUrl":"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg","width":70,"height":70,"caption":"Visual Paradigm Skills Indonesia"},"image":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs\/1392","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":0,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs\/1392\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs\/1390"}],"wp:attachment":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/media?parent=1392"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/doc_tag?post=1392"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}