Thursday, February 18, 2021

2021-02-18 Thursday - Salt Survey - API Security Trends

  • 91% of organizations in the survey suffered an API-related problem last year.
  • More than half (54%) reported finding vulnerabilities in their APIs,
  • 46% pointed to authentication issues,
  • 20% described problems caused by bots and data scraping tools.
  • "The most common API security incident reported for 2020 was finding a vulnerability in a production API"

Sunday, February 14, 2021

2021-02-14 Sunday - Book Review - Salesforce Architect's Handbook, from Apress®

Your First, Best, Choice - for Quickly Understanding Salesforce From An Architect's Perspective.

image source:

 Salesforce Architect’s Handbook, A Comprehensive End-to-End Solutions Guide
Authors: Dipanker Jyoti, James A. Hutcherson

My Review

Full Disclosure: At my request, Susan McDermott, Executive Editor with Apress®, graciously provided me with a copy of this book to review.

As a knowledge foundation stone, this book is an excellent start for any developer, manager, or architect to begin their Salesforce learning journey.

The first thing you should know about my reaction to reading this book: Respect for the obvious effort that went into organizing the content, and the brevity and clarity of the writing.

There is a particular word that came to mind as I slowly worked my way through the chapters of this book. It is a word I reserve for writing that is of an exceptionally high quality. That word is “crisp”.  This is praise that I do not give lightly, or frequently.

The second word that comes to mind, when reviewing this book: Holistic.

This is not a book on Salesforce programming – nor on how to administer it. There are plenty of books available on those topics. No, this book – as its title states – has a focus – and it delivers.

This book is about understanding Salesforce capabilities, in their context, to enable an architect to design solutions. And it does that very well.

Salesforce is such a large topic to try to cover in a single book – of any reasonable length (this one is 383 pages, including the index). It would be easy for less talented authors to fill the pages with information that would drown the user. But not so in this book. There were keen eyes involved in crafting this book – a balance and focus is held – that guides the reader through that which is essential for an architect’s concerns.


  1. Salesforce Architecture
  2. The Art of Artifacts
  3. Salesforce Application Architecture
  4. Salesforce Data Architecture
  5. Salesforce Security Architecture
  6. Salesforce Integration Architecture
  7. Salesforce Identity Access Management Architecture
  8. Salesforce Mobile Architecture
  9. Salesforce Development and Deployment Lifecycle
  10. Appendix A: Salesforce Authorization Flows 
  11. Appendix B: Salesforce Integration Patterns 
  12. Appendix C: Salesforce Sample Artifacts

As a consultant – frequently engaged by organizations that have chosen the Salesforce platform as a key component in their Enterprise Architecture – I have been keeping my eye out for a good book to recommend to those that I mentor. This book will be at the top of my list to suggest, going forward.

This book is an excellent overview and introduction to Salesforce for architects – whether Enterprise Architects, Solution Architect, System Architects, Domain Architects, Integration Architect, Security Architects, or Managers – who lead engineering teams.

What I particularly liked:

  • Examples used for discussion and elaboration of concepts are meaningful, clear, concise.
  • The diagrams in the book are of an excellent quality.
  • The authors provide a balanced view – and consider the trade-offs, advantages, and disadvantages of different approaches to solution development.
  • Salesforce architecture concepts are introduced, and examples are used to discuss and  reinforce the reader’s understanding of the concept.
  • The why is explained, not just the what.
  • FUSIAOLA Analysis – and the example artifacts provided in the Appendix C.
  • Clarifying the distinction between shared and external objects – and the limitations of the latter.
  • Highlighting the thresholds at which data storage can impact performance.
  • The discussion on the Salesforce licensing model – and license types.
  • There are many good, general purpose, architecture practices – that elevate the value of the book beyond just focusing on Salesforce.
  • Chapter 4’s discussion on data architecture performance considerations
  • Chapter 7’s Identity Access Management discussion
  • Chapter 8’s discussion on the limitations of the new Salesforce App (Mobile) - which replaced  Salesforce1, and the mobile web experience, and the comparison between Salesforce App and Salesforce Mobile SDK capabilities.
  • Chapter 9’s coverage of SDLC and DevOps topics. Figure 9-2, on page-296  is a great metaphor. The discussion of the Salesforce Delivery Team roles and responsibility is well done – and will be useful for organization’s that are just beginning their adoption of Salesforce.
  • The coverage of Security Architecture concerns – including data encryption at rest, and in transit – as well as the excellent and concise coverage of Salesforce Authorization Flows in Appendix A.

Possible suggestions for inclusion in a future 2nd Edition:

  • A dedicated chapter to discuss Salesforce anti-patterns (what common mistakes are frequently seen).
  • A discussion on custom API versioning strategies (options supported, limitations, capabilities).
  • An expanded discussion on Salesforce support for event-driven architecture, pub/sub, messaging – and integration capabilities with other event/messaging technologies.
For any reader who urgently needs to get up-to-speed quickly - they may find Chapter 3 (or Chapters 5 and 6) to be worth the price of the book alone.

If you suddenly find yourself assigned to your very first Salesforce project – this is the first book you want to read.

Tuesday, February 09, 2021

2021-02-09 Tuesday - Open Policy Agent Graduates at CNCF

Open Policy Agent icon, source:


 In a hybrid cloud environment, one of the challenging aspects is maintaining a uniform and consistent set of policies - for security, run-time governance, etc. The current state of variability in how such policies are defined and managed - when comparing different platforms and vendor products - illustrates the incredibly challenging problem this entails.

The intent of Open Policy Agent seems to hold much hope for what I would like to see as a standard solution - the possibility for a truly plug-and-play strategy for defining policies - abstracted from the vendor-specific implementation details.

Open Policy Agent Graduates at CNCF

"OPA's goals are to decouple policy from the code, unify policy enforcement, and enable policy-as-code. OPA uses a DSL called Rego to describe its policies. An OPA engine can run as a library, sidecar or daemon with the application. OPA policies can be updated dynamically by polling a Bundle service API to download "bundles" - a collection of policies and data."
"OPA integrates with various systems including Kubernetes, Envoy, CoreDNS, Kafka and Helm. There is also first-class integration between OPA and Kubernetes now with the OPA Gatekeeper which provides Kubernetes-native CRDs for working with the policy library."

"CNCF hosts another policy engine called Kyverno - which uses JSON/YAML instead of a custom DSL."
Policy-based control for cloud native environments


Monday, February 08, 2021

2021-02-08 Monday - Information Architecture Abuse

 While this video is intended to humorously show the tension between developers and QA - it also works as a great illustration of an abuse of Information Architecture.

 Two of the comments posted on this YouTube video are noteworthy:

  • "user feedback would result in removal of all other holes."
  • "Who said it was a fail? If they buy and use it however they want while still being happy! I think that's a win."

My Commentary:

A counter-argument. Imagine a screen with a dozen data entry fields - and one is a comment box. Imagine the chaos that ensues - if the user happily and merrily just enters values into that - instead of some of the correct/intended fields.

Some of the worst "knots" I've seen in Information Architecture - involved reuse abuse of a comment field - with no consistency in how data is entered, encoded, labeled. 

Overloaded use of a field, while mixing the data types,  reusing the same field for multiple purposes, etc. - eventually leads to a Gordian Knot - of epic proportions....

Tuesday, February 02, 2021

2021-02-02 Tuesday - An Ocean is Made of Drops


Photo by zhang kaiyv on Unsplash   

You have a professional network.

There is latent power in the relationships that you have developed.

By connecting people, making introductions, referring opportunities - you weave the threads that may give someone hope, provide a spark, shine a light, open a door.

Use your power, for good.

Reach out.
Lift others up.
Give back.

Whether your action is appreciated or acknowledged - is not the important thing.

Though your action may only be a drop in an endless ocean.
Oceans are made up of such drops.


© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.