Mariusz Pultyn

EA Researcher Svyatoslav Kotusev has put a presentation online with his takedown of Enterprise Architecture framework #TOGAF. https://lnkd.in/e-qDSH3G Recognisable. We've been making comparable observations about TOGAF. His historical research on the origins I have always found very enlightening (and entertaining if you're in this field) and I'm glad this is now available in presentation form. I have used his analysis (from the appendix of his book) once also in an EA workshop-style setup (with attribution of course). That workshop was called "Enterprise Architecture without a formal framework", by the way. It is still true that there are consultants around selling this TOGAF illusion at some shallow level to executives and beginning digital architects. There is a good reason this works: the idea is as seductive as it is wrong. (Note: these days, as Svyatoslav observes too, TOGAF is so ambiguous that it's often 'not even wrong') What would be really good if people could simply download the whole story that is in the appendix of his book. That would enable spreading that analysis far and wide even more, and the full story is a good read. (Except where I think generally 'evil' is not really a big factor cf. Bonhoeffer and others: people promoting TOGAF tend to honestly believe in that stuff, is my impression. But that is a minor disagreement.) One of the nice things about TOGAF is that it is a nice shorthand for 'stay away'. E.g. if job descriptions ask for it, you know there is a good chance you'll end up in some sort of non-functional architecture setup based on a non-working planning approach for executives who have no clue (nor are interested in getting a clue). It's not 100% certain, job descriptions tend also to tick some meaningless boxes, leftovers carried forward for ages. (Appropriate, that observation, now that I think of it).

123

67 komentarzy

Here is how I do CI/CD for webMethods Integration Server. This approach has been battle-tested since 2008 and works for all scenarios I have seen so far. These are the steps: - All developers have their own environment and commit their changes into the VCS, usually multiple times per day. - The CI server (e.g. Jenkins) picks up those changes, builds the package, and runs the unit tests. - On success, a package ZIP file is created and uploaded to the binary repository (e.g. Nexus, Artifactory). You can also take GitHub here, but be aware that it is used in a fundamentally different role, compared to its usual VCS functionality. - On further test environments the package ZIP file is installed from the binary repository and tests are executed. These environments do not interact with the VCS, that is solely the job of the CI server. - Once all tests have been passed, the package ZIP file gets promoted from snapshot to official version (often called "release"). That can happen automatically for Continuous Deployment. Or you do it manually for additional control over the time of the update. - Once release status has been reached, you use the exact same package ZIP file to create a new container image, update your running VMs, or deliver a new version to your customers. All this usually with automation. The approach has the following advantages for me: - Conceptually simple with clear steps and responsibilities. - Tool-agnostic and flexible. - Compatible with standard approaches from e.g. the Java world. #webmethods #cicd #testing #integrationserver #onprem #sdlc

56

3 komentarze

⚡ MuleSoft was one of the first companies to make systems interoperable. It took API chaos of hundreds of unconnected apps and processes, and built a discipline around connectivity, reuse, and governance. That’s what made API-led connectivity the backbone of modern enterprise architecture. But that same chaos is back again. This time, it’s not APIs but agents. ❌ Agents built across vendors with no shared protocols. ❌ Data described differently across platforms. ❌ Workflows that overlap, conflict, and break compliance. And just like before, MuleSoft is stepping in. The answer is Agent Fabric. A lethal weapon for orchestration and governance. It’s a framework to register, broker, and visualize every agent across your ecosystem. While others are experimenting with copilots, MuleSoft is building the control plane for agents. Here’s why this moment is bigger than a product launch 👇 In the last month, we’ve seen the ecosystem shift: Snowflake, Salesforce, dbt Labs announced the Open Semantic Interchange (OSI) — a universal standard for data meaning.  Google’s A2A and Anthropic’s MCP are setting the first agent-to-agent protocols. The message is clear: The market is converging on interoperability. Everyone is racing to define how agents talk, how they share context, how they act responsibly.  And MuleSoft, the original interoperability leader, is perfectly positioned to lead again. Because while OSI defines meaning, and MCP/A2A define communication, Agent Fabric defines control. It’s MuleSoft doing what it always does, taking chaos and turning it into architecture. 👉 The first time, it was APIs. 👉 This time, it’s agents. History doesn’t repeat. In integration, it scales. #MuleSoft #AgentFabric #AIIntegration #AgenticEnterprise #APIledConnectivity MuleSoft Community Footnotes: MuleSoft Agent Governance” - September 2025, Salesforce “Snowflake, Salesforce, dbt Labs, and More, Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative” - September 2025, Snowflake Press Release “The Agentic Future Demands an Open Semantic Layer” - September 2025, Salesforce https://lnkd.in/eQZf2UbX? https://lnkd.in/e34-CSpn https://lnkd.in/eDATkUfB  

232

11 komentarzy