DJ Adams

Blog posts tagged "architecture"

  1. Timeless principles, agnostic design and the power of CAP's abstractions

    The timeless principle of agnostic design, aka minimal assumptions, is strongly present in CAP. In this post I explain what this principle represents, based on the corresponding section of Daniel Hutzel's keynote at reCAP 2026.

  2. Book Overflow and two architectural patterns in CAP

    In this short post I note a couple of software architecture patterns that were mentioned in a recent Book Overflow episode, patterns that are clear and present in CAP.

  3. Shift left with CAP

    In this post I posit that shifting left in our CAP based solutions is something that we should be striving to do.

  4. TASC Notes - Part 4

    Notes on part 4 of The Art and Science of CAP, a mini series with Daniel Hutzel exploring the philosophy, the background, the technology history and layers that support and inform the SAP Cloud Application Programming Model.

  5. TASC Notes - Part 3

    Notes on part 3 of The Art and Science of CAP, a mini series with Daniel Hutzel exploring the philosophy, the background, the technology history and layers that support and inform the SAP Cloud Application Programming Model.

  6. TASC Notes - Part 2

    Notes on part 2 of The Art and Science of CAP, a mini series with Daniel Hutzel exploring the philosophy, the background, the technology history and layers that support and inform the SAP Cloud Application Programming Model.

  7. Five reasons to use CAP

    Five compelling reasons to embrace SAP's Cloud Application Programming Model, from its framework-first philosophy to its agnostic design principles.

  8. Separating concerns and focusing on the important stuff

    Thinking properly about what separation of concerns means in the context of CDS and CAP.

  9. Immutable layers, file deletion and image size in Docker

    Digging into how the immutability of Docker image layers means you have to think carefully about creating and deleting content when building an image.

  10. Unix tooling - join, don't extend

    Reading a 1984 paper by Pike and Kernighan helped crystallise an important axiom in Unix tool design about joining programs rather than extending them.

  11. CAP is important because it's not important

    Considering what CAP really is, what it gives us, and why its transparency is what makes it important.

  12. Monday morning thoughts: longevity and loose coupling

    I think about the importance of core technologies, and how the arrival of functions-as-a-service might be merely the next incarnation of an idea that's existed for a while.

  13. Monday morning thoughts: abstraction

    I think about abstraction, the power and facility it affords, and consider CDS as one example of a modern abstraction language.

  14. Balancing features with simplicity

    Considering the balance between features and simplicity, prompted by a ChromeOS forum thread.

  15. SOA scaffolding and development architects

    Reflecting on where SOA stands today and the role of development architects in service orientation.

  16. The past and future of SAP integration: guest Bluefin blog post

    I wrote a guest blog post on the Bluefin Solutions website, about the Project Gateway.

  17. Command lines of the future, and simplicity of integration

    Thinking about chat-style interfaces as command lines of the future and their implications for integration.

  18. Information vs Behaviour

    Architectures, axioms and ROA vs SOA.

  19. Twitter's success

    Thoughts on messaging, microblogging, and Twitter's success.

  20. An overcorrection too far?

    Norman Walsh gives up ‘wrestling his way through the arcana of WSDL’.

  21. Honest application requirements

    An unusual "user story".

  22. The integration irony of SAP's technology directions

    I’ve finally realised what it is that’s been bugging me about the new arena of SAP technology.

  23. Forget SOAP - build real web services with the ICF

    I don’t like getting into a lather when it comes to data and function integration. Rather than using SOAP, I prefer real web services, built with HTTP.

  24. Real Web Services with REST and ICF

    This piece has become somewhat famous (or infamous) in SAP tech circles, for the approach it took and the claims it made. I'm happy to say that REST won out and that those that tried to denounce me ... failed :-)

  25. For REST, read 'Architectural Style'

    In the swirling mass of memes surrounding web services it’s sometimes easy to forget that REST is an architectural style, an approach, rather than something that you install or debug.

  26. "Assaults on the Internet's end-to-end-architecture"

    What can and should we do about spam?

  27. "Web^H^H^HInternet Services"? Some Ramblings.

    I’ve been pondering the term “Web Services”. While I completely understand and agree with all the reasonings behind the term (the ‘original’ services were accessible via web clients, HTTP is the underlying and ubiquitous transport, blah blah blah), I’m wondering whether “Web Services” is the best term to use.

See all tags.