Ben Chan ♦ Insightful. Innovator. Achiever.

Breaking Down Dev & O&M Silos in Multi-Vendor Modernization Programs: One of the biggest barriers I see in modernization is that O&M vendors maintaining legacy systems often resist modernization. Why? Because new systems could replace their work. But modernization can’t succeed in silos. Agencies need the knowledge and subject matter expertise of O&M vendors. Leaving them out introduces huge risks.   RECOMMENDATIONS FOR GOVERNMENT: 1) Contract inclusivity: Write explicit contract clauses requiring O&M vendors to support modernization efforts. Offer additional modernization task orders in contracts. 2) Fund SME support: Provide budget for O&M vendors to contribute to modernization—not just in hours, but in measurable outcomes like knowledge transfer, reduced onboarding time, integration support, and risk mitigation. 3) Unify contracts: Move away from segmented O&M vs. DME contracts. Adopt DevSecOps-style contracts where vendors support both ongoing operations and new feature development off a single product backlog. 4) Microservices strategy: As monolithic systems are decomposed into microservices, divide the work across multiple agile teams (potentially different vendors) to reduce risk, improve parallelism and increase velocity.   RECOMMENDATIONS FOR INDUSTRY: 1) Shift the mindset: Vendors must stop seeing modernization as a threat and start seeing it as an opportunity to contribute to the mission. In a crowded, commoditized GovCon IT market, vendors who collaborate stand out as trusted leaders to agency leadership. 2) Embrace stewardship: Even if you’re not the “modernization” contractor, support it by sharing your knowledge and expertise. If you are the modernization contractor, be empathetic, respectful and collaborate with the legacy teams. 3) Culture change: Industry needs a cultural shift–partnership, transparency, and inclusivity yield better outcomes than guarding turf. Invite other vendors to your sprint demos, provide visibility to your product backlog and be the change agent. Better outcomes translate into stronger agency relationships, increased contract longevity, and access to new opportunities.   TANGIBLE BENEFITS: 1) Better mission outcomes – Modernization succeeds faster when all vendors collaborate instead of competing. 2) Lower risk – Agencies reduce dependency on a few high value individual SMEs and achieve broader support coverage. 3) Greater value delivery – Unified DevSecOps models increases feature velocity while keeping operational costs flat and predictable.   Modernization is not a solo technical journey—it’s a cultural transformation. Agencies, business, IT, security, and vendors must inclusively work together to be successful.   👉 What changes do you think encourage collaboration between Dev and O&M teams?   #RajivsWeeklyTake #GovTech #DigitalTransformation #ITModernization #FederalIT #Technology #Collaboration #HUD #USDA #USPTO #VA #USDOT #DHS #HHS #Census #DepartmentOfEducation #FederalStudentAid Nginering  

14

2 Comments

Here's the thing about MQ vs Kafka that nobody talks about enough: They're "NOT" interchangeable. I learned this the hard way three years ago when our team tried using Kafka for something that should've been a straightforward MQ job. We spent weeks fighting with consumer groups and offset management when all we needed was reliable point-to-point messaging. 🤦‍♂️ So when should you actually use what? Use Message Queues (RabbitMQ, IBM MQ, ActiveMQ) when: ✅ You need guaranteed message delivery with acknowledgments ✅ Point-to-point or request-reply patterns are your primary use case ✅ Message priority matters (urgent messages first) ✅ You're dealing with transactional workflows Use Kafka when: ✅ You're building event streaming architectures ✅ Multiple consumers need to read the same data independently ✅ You need message replay (going back in time) ✅ High throughput is critical (millions of messages/sec) ✅ You're doing real-time analytics or event sourcing The honest trade-offs: ✅ MQ Pros: Simpler setup, better for complex routing, mature protocols ❌ MQ Cons: Harder to scale horizontally, messages are deleted after consumption ✅ Kafka Pros: Insane throughput, message persistence, built for distributed systems ❌ Kafka Cons: Steeper learning curve, overkill for simple use cases, more operational overhead Here's my rule of thumb: If you're asking "do I need Kafka?" you probably don't. Start with MQ. But if you're building something event-driven at scale? Kafka's your friend. What's been your experience? Ever regretted choosing one over the other? Follow me on LinkedIn: https://lnkd.in/dkeKb6cc #Kafka #MessageQueue #SystemDesign #SoftwareArchitecture #EventDrivenArchitecture #Microservices #DistributedSystems #TechLeadership #EngineeringBestPractices #ThePracticalArchitect

23

4 Comments

Why cloud cost is a leadership problem — not a tooling problem When cloud costs rise, teams reach for better tools. But cloud spend isn’t driven by dashboards or scripts. It’s driven by decisions: • Architecture direction • Risk tolerance • Speed vs efficiency • Incentives Tools execute decisions. Leaders own them. Teams with predictable cloud costs don’t optimize harder — they make trade-offs explicit early. This is a pattern we see repeatedly while building CrftInfrai. #Leadership #CloudCost #FinOps #Startups #CloudArchitecture #DecisionIntelligence

6

1 Comment

While GraphQL is a game-changer for complex, multi-client data fetching, it becomes an "architectural tax" when applied to simple CRUD apps or flat data structures where REST excels. To avoid performance and security debt, prioritize batching with DataLoaders, enforce query depth limits, and treat your schema as a stable product contract rather than a mirror of your database.

4

1 Comment

great post on the intersection of AI workloads and Open Container Initiative "The State of OCI Artifacts for AI/ML" https://lnkd.in/gbXZykMq

47

I attended a GovCIO event yesterday. A big topic was the importance of interoperability, and the ability to select and mix and match best-in-class technologies as part of a modular data system; also the need to avoid vendor lock-in. We agree. Part II of this series with Carahsoft. Learn how open, modular architectures are redefining how federal and enterprise data teams build scalable systems - from advanced analytics to AI deployment. If you're a data leader building for performance, flexibility, and long-term agility, this is for you. Register now: [https://lnkd.in/gq9q4xPz] If you missed Harvey Morrison and Ian Cook deliver Part I - drop me a message, or leave a comment and I'll see that we get you a recording. Voltron Data.

7

1 Comment

Running cloud workloads is one thing, running them well is another. 💡 This article from McKinsey outlines how site reliability engineering can help organizations maintain velocity without compromising on uptime or user experience. Read the article and message us if you want to talk about how SRE could support your cloud operations.

2

1 Comment