Eric Swanson

🚀 Stop celebrating output. Start measuring outcomes 🚀 Many teams still equate “busy” with “impact.” But real progress isn’t measured by how many features we ship — it’s measured by the value we create and the problems we solve. When we focus on outcomes, we build with purpose, prioritize what truly matters, and create meaningful change for our users and our business. 👉 Read full article here: (https://lnkd.in/eh5KabrU) Let’s build value, not only features

13

1 Comment

It is interesting to see folks, and myself, going through programs like the APIsec Certified Practitioner. It highlights a discussion we've been having for years: what are APIs really? Kudos to APIsec University and individuals like Dan Barahona for pushing this conversation forward. The key takeaway? If your API is just a thinly veiled SELECT * from your database, you're not just doing it wrong, you're inviting disaster. APIs are interfaces. They are meant to be stable, well-defined points of interaction that deliver specific business capabilities. Think of them as products, not plumbing. When we treat them as mere technical extensions of our back-end systems, we fundamentally misunderstand their role and, more importantly, their attack surface. The OWASP API Top 10 is essentially a catalogue of what happens when this "API-as-a-product" thinking is ignored. It's not just about "security" as a checklist; it's about designing for security by understanding the purpose of the API and its consumers. So the next time you're designing or exposing an API, ask yourself Is this a robust, well-designed product interface, or am I just punching a hole through my firewall to my data tables? The answer to this question has massive implications. #APIDesign #APIStrategy #DigitalTransformation #Security #API

15

1 Comment

Yesterday, IBM dropped their new WebMethods Hybrid Integration, which brings some cool upgrades around unified API management and orchestration—now with AI to help out. This comes right in line with Gartner's prediction that API demand will jump by about 30% by 2026, mostly thanks to AI and tools using large language models (LLMs). It’s exciting to see how AI is really changing the way we use APIs and making them even more important moving forward.

35

3 Comments

Big news from Anthropic: Claude Sonnet 4.6 is here and it’s their most capable Sonnet model yet! Released: yesterday, Sonnet 4.6 comes with: • Coding (developers prefer it over Sonnet 4.5 ~70% of the time – and even over Opus 4.5 in many cases!) • Computer use (huge leap on OSWorld benchmarks, approaching human-level performance on real software tasks like spreadsheets and multi-tab forms) • Long-context reasoning with a 1M token context window (beta) • Agent planning, knowledge work, design, and more polished visual outputs Want to learn more? https://lnkd.in/dNVdGyns #anthropic #sonnet4.6 #llm

14

▶️ Concept Models (Pt 3): Concept Model enabling other artifacts - Example Due to interest from my previous post/presentation, this is the final part of a short series that will go into more detail on Concept Models and how they can fit in with a bigger picture. Pt 1 was defining what a Concept Model (CM) was. Pt 2 was Aligning Business Architecture & Data. 🎉 We have arrived!! Part 3 shows an example of a scoped Concept Model aligned to the same scope portion of the Info Concept Map, then aligned to two value streams which use these concepts as entrance and exit criteria for movement. (Graphic) - Use the Concept Model with business stakeholders for high level understanding of the scope of concepts and how they relate. - Validate the definitions, states and types of those concepts with the business stakeholders, which creates the Info Concept Map. - Map those concepts to your value streams to give them context and validate the states of the concepts/data you will need for tracking! - Use all 3 of these when you collaborate with data stakeholders to provide scope and context they can then use to do more detailed maps and models they need! 🌟 The beauty of using these artifacts when aligning business architecture to data is all of these concepts (the 'what') in context (the 'why') will give factual business meaning to the data needed for true business value! This is where the collaboration between these architecture domains begins! #businessarchitecture #businessanalysis

115

8 Comments

I was reading about Lee Robinson migrating cursor.com from a headless CMS back to raw code and Markdown. Estimated time: 1-2 weeks, probably with agency help. Actual time: 3 days, $260 in tokens, working with AI agents. While the speed he delivered it in is exciting, it's why he did it that is interesting to me. The CMS was preventing agents from helping. Content pulled over the network wasn't in the repo—agents couldn't grep it, couldn't edit it with a simple prompt. His line that stuck with me: "With AI and coding agents, the cost of an abstraction has never been higher." Here's the thing: agents work best in text, not UIs. My mind naturally goes to business automation tools. UI-first tools like Power Automate and Zapier weren't designed to be text-first. They grew up in an age where abstracting the text away from users was a design goal. Now that things have changed, they're faced with a challenge. When they bolt on code or agent interfaces, it's an abstraction on the abstraction. Which doesn't seem like a particularly good design pattern. If you're not using these tools yet, I wonder if they make sense today. If you are, is the UI first approach holding you back? https://leerob.com/agents

1

2 Comments

PSA reminder: Trunk-based development is not the goal. The goal is to deliver the latest change RIGHT NOW when required. - That requires continuous delivery - That requires continuous integration - That requires trunk-based development. MinimumCD.org

63

18 Comments

FABCON 2026 in Atlanta was nothing short of mesmerizing-where bold ideas, breakthrough tech, and real-world impact came together seamlessly. An electrifying blend of vision, innovation, and execution that set the tone for the future of data and AI. Now, it’s a wait-and-watch moment to see how much of it proves truly real, scalable, and competitively differentiated. ** AI Foundry: Fabric IQ is positioned as a capability that makes data AI-consumable for agents and AI apps via OneLake ** OneLake Transform transformations are applied on top of shortcut or mirrored data (zero‑copy, zero‑ETL), preserving the original source while exposing a transformed view in OneLake. New Connectors have been added (SharePoint in preview). ** Data and Catalog mirroring / zero copy options across open table formats from snowflake and Databricks into Fabric ** SAP Fabric and Salesforce Fabric version with zero copy and write back functionality ** Availability of CoPilot across various platforms within Fabric exclusively designed to support that platform only ** Fabric AI and Data Agents ** Zero ETL Data Mirroring onto Onelake from Azure data for PostgreSQL. Analytics on Operational workloads made simple. ** Building declarative AI Pipelines made simpler with dspy and pixeltable Thanks to Cognizant leadership for the opportunity. Rajesh SreepadaSatish Hegde FABCON & SQLCON - The Microsoft Fabric & SQL Community Conferences Microsoft Fabric

23

To mark the 41st anniversary of my journey in Information Technology, reflecting on the state of computing in the 1980s is essential, especially for younger generations to compare with state of computing today. Season 1: Computing 40+ Years Ago Introduction: In an era when computing was defined by limits rather than abundance, ambition was often overshadowed by constraints. The design of systems and the writing of code were driven by scarcity. Here’s a glimpse into what “limited computing” truly entailed. Episode 1: Hardware: Desktop PCs of the 1980s: - Operated under real constraints with CPUs at 4-12 MHz - Featured 64 KB-640 KB of RAM (1 MB felt generous) - Hard drives ranged from 5-40 MB (if available) - Utilized single-tasking operating systems like MS-DOS, running one program at a time - Every line of code was crucial, as memory leaks could crash systems - Inefficiency was immediately apparent By today’s standards, these machines seem tiny, but they were discipline-building by engineering standards. Mainframes of the 1980s: When One System Ran the Enterprise: - Offered 1-30 MIPS of processing power and 1-64 MB of shared memory - Supported hundreds of users on green-screen terminals - Managed batch jobs, transaction processing, and strict scheduling - Centralized operations where every workload competed for the same resources - Poorly written code had widespread impacts, not just isolated failures Mainframes enforced: - Capacity planning - Change control - System-level thinking They were not slow; they were meticulously engineered under constraints. Question: As computing resources have become abundant, have we gained capability, or have we quietly lost architectural discipline

6