Quick-commerce has taken the world by storm! Move over traditional retailers, welcome to the new kids of quick-commerce and fast-fashion! The relatively stable global e-commerce landscape is getting disrupted by Chinese quick commerce companies like Shein, AliExpress, Temu or Tiktok. All of them leveraging agile and lean methodologies to deliver their products with unprecedented speed and efficiency.
Let’s look at how lean, agile and product management mindset is driving this digital transformation in retail.
With rapid advance in the technology world, it makes sense sometimes to rethink our objective and outline the roadmap instead of just following the new and shiny. Data Mesh might seem a relatively new concept, however what its creator Zhamak Dehghani has done is spell out in words the approach required to reach the strategic goal of being a data-driven organization.
Figure: Data Mesh domain product notation, adapted from Zhamak Dehghani
The technology world often sees upheavals when disparate concepts are put together to achieve different objectives, creating something which is much more than the sum of its parts. Delta Lake is one such concept, which has melded log and ACID, bringing transaction and atomicity concepts into the ETL-analytics-big.data field, creating a revolution of sorts.
The problem(s): Since traditional data warehousing, the design and modeling of analytics systems relied on denormalized tables, as analytics systems were considered separate from transactional systems. This started to change with the move to the cloud and availability of more real-time data. With the advent of big data technology like HDFS/Hadoop, additional constraints on updates and storage of relational datasets were added due to performance costs. The difficulty was particularly acute for cloud customers who faced additional latency compared to on-premises HDFS/Hadoop users.
GDPR compliance meant deleting or correcting customer data required massive table-wide updates for a few records, with increased probability of data corruption and consistency issues in case of crashed updates.
In my previous post, we saw how app registrations add identity configurations for applications on Azure AD. Just like a user, an application would also require access to resources like Microsoft Graph, which need authorization. The resource owner can grant(consent) or deny this authorization to the application.
There are mainly 2 access scenarios:
Delegated access - access on behalf of a signed-in user.
User is signed-into a client application, which access the resource on behalf of the user. This requires delegated permissions (also referred to as scopes). All scenarios involving user actions should use delegated access. Also, scopes should be limited using the principle of least-privilege. See also: the full list of Microsoft Graph permissions
App-only access - access without a user, as the application’s own identity. This scenario is when the application runs as a background service or daemon used for automation or backup, or the data can’t be scoped to a single user. The client app needs to be granted appropriate application roles of the resource app it’s calling to access the requested data. Application roles granted through consent are called application permissions.
For some time now, I’ve been working on security risk assessments of web applications. Modern identity management can be complex and often requires diving deep into the authentication flow and registration process to understand risk blocks in order to design appropriate controls and counter-measures. I hope to write a short series of posts to document the components and flows of this process, so that it can be my handy reference.
