Martin Bishop

The value of EA is rarely in the Architecture Review Board. And none of your stakeholders will ever use the term “alignment.” Both standards and alignment are your job. Not theirs. When you are “doing” Enterprise Architecture, don’t explain your activities. Explain the results. Explain what you *hope* they will do with the results. Work with them to figure out how to fit *their* response to your results into *their* work processes. If they cannot use your results, either you are talking to the wrong person, or you are producing something useless. Architect, be useful.

129

41 Comments

Often making the leap from Solution Architect (SA) to Enterprise Architect (EA) can be a step too far. On paper, it looks like the natural next step and is still the most common step into Enterprise Architecture 📰 But in practice, the skills and mindset needed are very different. This is why the skill gap analysis was created; to support SA's looking to transition into Enterprise Architect roles. It takes investment, time and effort to develop these skills 📋 Here are 5 reasons why some Solution Architects don't always make great Enterprise Architects ⤵️ P.S Lack of exposure to governance is one of the most common reasons I have noticed when speaking to SA applicants. 📌

40

2 Comments

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 Comments

For anyone who has been following me for some time, you would know that I absolutely love the role of a Solutions Architect because of the flexibility we have in choosing the activities we would like to focus on. In one of my previous article, "The role of a Solutions Architect and how they spend their time," I broke down the different hats we wear and how time allocation shifts based on seniority level. In this week article, I dive deep into what I consider the most impactful activity Field Solutions Architects engage in - partnering strategically with Product teams to drive successful product launches and seamless customer implementations. While it's true that Solutions Architect is fundamentally a customer-facing role where we spend the majority of our time with customers, the most successful solutions architects I know understand a critical truth: significant time investment with product teams is what separates good from exceptional. In fact, when I was promoted to principal solutions architect, the centerpiece of my promotion document wasn't just customer wins - it was the strategic partnerships I built with service teams that directly contributed to launching multiple products. Read the full article here - https://lnkd.in/eqhHBRdG

61

5 Comments

⚡ 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  

245

11 Comments

Strategic Timing: 10 Critical Moments for Enterprise Architecture Assessment   Enterprise Architecture (EA) assessments deliver maximum business leverage when timed with leadership decision points. Below are the 10 moments when running an EA assessment is not just valuable, it’s strategic.   1. Upcoming Strategic-Planning Cycle When: 1–2 quarters before annual budgeting.
 Why: Align technology investment roadmaps with corporate priorities before funding locks.
Prerequisite: Consolidated current-state portfolio view (apps, infra, data, integrations).
 Example: Unilever ran EA assessments in Q2 ahead of Q4 budgets. Discovered gaps in e-commerce analytics, shifting $20M from on-prem upgrades to a composable Customer Data Platform (CDP).
 Outcome: 18% faster personalization, driving $55M incremental online sales.   2. Mergers, Acquisitions, or Divestitures When: During due diligence and 30–60 days post-close.
 Why: Identify integration risks and quick wins early.
 Prerequisite: Access to target entity’s architectural blueprints & contracts.
 Example: IBM’s Red Hat acquisition assessment exposed heavy AWS dependency. Post-close, 70% of workloads migrated to IBM Cloud, saving $12M annually and accelerating hybrid-cloud offerings.   3. Major Technology Refresh / End-of-Life When: 12–18 months before end-of-support.
 Why: Avoid rushed, costly migrations that replicate legacy flaws.
 Prerequisite: Dependency mapping for critical workloads.
 Example: Toyota’s SAP ECC to S/4HANA migration started 16 months pre-deadline. EA prioritized containerizing supply chain modules, reducing infra OPEX by 22% and avoiding $30M downtime risk.   4. Digital Transformation Launch When: 2–3 months before formal greenlight.
 Why: Set realistic scope, architecture guardrails, and prevent rework.
 Prerequisite: Defined transformation outcomes and KPIs.
 Example: Nike delayed its metaverse rollout after EA found weak integration between NFT platforms and loyalty systems. Six-month pause avoided $50M rework and enabled a unified omnichannel loyalty platform.   5. Significant Operational Disruption When: 2–4 weeks post-incident.
 Why: Fix root causes while executive focus is high.
 Prerequisite: Incident impact and recovery reports.
 Example: After British Airways’ 2017 outage, an EA sprint found single points of failure in 85% of systems. $100M redundancy investment cut outage risk by 65%.   6. Regulatory / Compliance Mandates When: ≥6 months before deadline.
 Why: Surface hidden risks — shadow IT, undocumented data flows, unvetted AI models.
Prerequisite: Current inventory of data flows and compliance posture.
 Example: Barclays’ EA assessment for EU DORA compliance found 14 unmonitored fintech APIs. Fixes avoided €75M potential fines and created a reusable third-party governance framework.   Continue in 1st and 2nd comments.   Transform Partner – Your Strategic Champion for Digital Transformation     Image Source: ITarch dot info

498

54 Comments