Ivan's Tech blog

It's been a while since my last post (work, life and holidays happened, among other things!), so I want to keep a lighter tone with this one (I think), at least it'll be less deeply technical than others. This post will be about Enterprise architecture with a bit of methodology (just a bit), not entirely about Technical architecture, although that will also be a part of it. First, some definitions from wikipedia and The Open group docs: Enterprise architecture (EA): Enterprise architecture is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy The Open Group: The Open Group is an industry consortium that seeks to "enable the achievement of business objectives" by developing "open, vendor-neutral technology standards and certifications" TOGAF: The Open Group Architecture Framework (TOGAF) is a framew

UPDATE: By popular demand, I want to note before I begin that the solution described here is not necessarily the optimal for the scenario presented below. It is meant to be an example of how all these tools can coexist in case they're part of an enterprise landscape. Especially with Salesforce's acquisition of Mulesoft, this very well might end up being the case for some enterprises. Toward the bottom of the post, there's a section with a few bullet points on what the solution could look like (including serverless options, of course), but it's a long post and I can appreciate that not everyone will get there! The title says it all! In this post, I'll walk through an example of how Docker, Kafka, Mulesoft, Platform Events and IoT Cloud could work together, to create a really powerful landscape for companies with IoT use cases. I thought of writing this one because integration of different systems is one of my biggest interests (alongside DevOps). I find that st

As an architect (Salesforce and Enterprise), one of my favourite things in the world are architecture principles. Principles define the foundation for the way your teams must work and the rules you want to have set in stone (they can't be broken without extensive and clear justification). They are mandatory, but they shouldn't be adversary, they need to be an agreement, a consensus that allows everyone involved to understand how things need to be done, and more importantly, why they need to be done. They have to believe it for the whole thing to work! I googled the definition of principle and this is what came out: "a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning." I like that very much. I want to focus on the way principles serve as a foundation for a system of belief, behaviour or for a chain of reasoning. They are what you need to build upon, when creating teams of people, n

OK, now that we've gone through what I believe to be good and not so good about DX and about DevOps in general (when it comes to Salesforce, that is), I think it's time to wrap the series up. For this purpose, I'll try to keep the series finale shorter and lighter than the previous posts and will focus only on what I see and what I want to see for the future of working with the DevOps culture in Salesforce implementations. Future of Salesforce and DevOps, as I see it I believe that the amount of people embracing the culture and the percentage of implementations that adopt it will certainly grow as the technology evolves (Salesforce DX and otherwise, even outside of Salesforce) In the not so distant future (hopefully), the Metadata API completeness (and robustness) will be almost there , allowing improved and more common use of DX globally When unlocked packages and "org shape" features become GA and robust , there will be a big growth in the ease of D

I have to admit I've been looking forward to this one, after going through the tools and usual lifecycles (and ranting about my views as well). This post is going to be dedicated to describe my experience, views and decision making process about Salesforce DX, including where and when to use it (or not). Keep in mind that this is all accurate only as of the date of the post creation (August 2018), and as far as I've used it and researched. I'll try to update this one or follow up on different posts in the future. As usual, please comment if there's something you believe I should add or update! If you want more of a detail about what DX is and some quick start instructions, there's a pretty good blog series on all things DX here: https://developer.salesforce.com/blogs/2018/02/getting-started-salesforce-dx-part-1-5.html . There's also the dev guides, of course. Let's get to it. As I mentioned lightly earlier in the series. After a long time of n