Monday, January 9, 2023

The Metaverse versus The Immersive Web

Bold Prediction

Much like the mobile versus web spectrum, VR/XR is having a similar problem. On one side there are "native apps". These are written to be deployed on the device, often belaboured by app store policies and confusion, and are not generally "runnable" without installing them. On the other end are the "mobile web apps". These just use html/js and can be run from a browser on modern days, with things like PWA, they are often indistinquishable from "native apps" and have the added benefit of running without going through an "app store".

In the VR/XR world, we face a similar problem...Oculus, being the first platform with any degree of consumer success, has a ton of mind share around "native apps", however, there is a web standard (WebXR) that has been creeping into browsers everywhere called WebXR which is enabling the ability to run "native-like" immersive experience.

This is significant because currently, most of the focus is on building "Metaverses", or, as far as I can tell...basically "not really great replications of real life using native apps". The alternative, however, is something called "The Immersive Web", which is using the internet and WebXR technology to extend VR/XR experiences into the internet (or visa versa depending on your point of view).

I believe the "immersive web" has jumped past what most folks are focusing on (i.e. Metaverse) and is going to overtake mindshare over the next year or so. To this end, there are a number of frameworks to simplify working with VR in the browser, but there's a clear winner from a developer productivity perspective.

This winner is A-Frame.

While the site may not be much to look at the ease and simplicity it enables to build 3d experiences that run in the oculus browser and accessible in the device is unrivaled. While bablylonjs and other tools seem focused on nuts and bolts of 3d devlopment (like threejs), A-Frame is focused on enabling devlopers to quickly use existing tools and knowledge to rapidly deploy and easily maintain VR experiences that live on the web.

It may appear from looking at the site that it is not maintained, but I can assure you it is actively maintained (hitting 1.4 a month ago and having 1.4.1 quickly released thereafter) and has a deep and rich history as well as a number of applications released in the wild (including a beat saber replica). If you're a web developer and wanting to get into VR and immersive experiences and be able to build upon knowledge you already have, you really should check it out.

Thursday, January 5, 2023

Why Digital Transformations Falter

A key reason many so called "Digital Transformations" falter after a short period is that the initial shift from disjointed process and task oriented technology attitude to a holistic human centric posture yields enourmace gains in a very short period of time. Unfortunately, this usually comes with a side effect of painfully illustrating blind spots and gaps which are often misattributed to the shift. It can be exceedingly difficult to illustrate a "before" and "after" picture if, in the case of the blind men and the elephant, you are now able to SEE the elephant and are now trying to explain the difference between the world of the blind men, and the world of the seeing. Too often, businesses (in particular) take the gains as an obvious effect from a shift, but then stall because they now realize problems that "seem" new, but are actually just now finally visible.

Tuesday, August 23, 2022

The Real Value of MACH Platforms

In the spirit of The Agile Alliance, a small group of SAAS platform providers formed The MACH Alliance. I won't reiterate what they stand for, feel free to follow the link. What I want to briefly (I hope) call out is, for folks building a digital solution, "what's in it for them?".

You're thinking about the wrong thing

I find many folks, especially if they are technology focused, get hung up on the technical architecture surrounding MACH solutions. This "can" be valueable, but I find most orgnaizations that are focused on, say, "selling things other than software" don't really need THEIR solution to be MACH compliant and the principles behind a MACH solution are overhead. As a software consultant, I've run across a small but growing number of clients that say they want a "MACH Compliant" solution. Personally, unless you're building a platforms that is intentionally a set of APIs for other folks to use, pay for, and you manage, this is looking at the wrong dimension.

The Real Value

The real value propositions behind most platforms in this space are:
  • Openness: These platforms are intentionally designed to be integrated in an open manner. This means that you don't need "secret API docs" or "proprietary software tooling" to use thier software. They are all API addressable and rely on passing messages of a known format either with REST/GraphQL APIs or dropping messages into queues/event streams and listening for responses. This greatly reduces the need for SI partners with super specialized knowledge to use the platforms and instead opens the gateway to your consulting partners crafting a solution around your particular business opportunities.
  • Interoperability: While many legacy platforms have ways to integrate with other platforms, they are often coupled with baggage and very proprietary protocols, APIs, and even licensing problems that inhibit interoperability. MACH platforms are designed to work with other systems and "if there isn't an API to do it, there's a API/hook to expose an event that allows you to integrate another solution.
  • Pay for what you need: Legacy platforms tend to charge you for the engineering/support of components you might not even need. A vast number of clients use legacy platforms and pay for their internal Order Management, Search, Content Management solutions, but then pay for "yet another platform" to actually fulfill those functions. In contrast, MACH commerce platforms don't even attempt to give you a content management platform, they are focused on transactional processing and order capture (for the most part), leaving other functions to be something you can integrate with their platform.
  • Do One Thing Well: Generally speaking, MACH platforms are really really good at one thing. Similar to the previous bullets, you aren't paying for Contentful to have an order capture, payment gateway, or catalog management're just paying for content management and/or digital asset management. The reality is, most platforms (especially large platforms recently attempting to become SAAS/Cloud tools) are a conglomoration of tools that have been retrofitted to work together, but this integration isn't really suited to any single business case except "selling software". This leads to a situation where folks try to buy "a one size fits all" solution, not realizing most of these solutions are "one size fits none".

The promise behind the MACH brand

I want to reiterate, the promise behind the MACH brand isn't technical in nature, but it is that you are buying a discrete set of functionality without the downside of paying for work, rework, or falling into a proprietary money pit that many legacy platforms can (without careful and thoughtful up front work) often become. Yes, you can still dig yourself into a hole with MACH platforms, but the overall negative impact of any single platform is mitigated by the inherent scope limitations that any single platforms consciously builds into their offering. The real value proposition is that you are empowered to use the best tool for particular problem domains and only need to invest in solving problems that are strategic to your business objectives.

Saturday, July 9, 2022

feature switch it

note, this post was sitting in drafts for a few years ago and suddenly has become top of mind again

in my post about git branching problems, I neglected to inform/expand on the "real" problem.

Namely, Delaying integration is bad(tm)

The History

Waaaay back in the olden days, when folks used tools like RCS,cvs, and svn...branching was...well downright difficult. Or rather, reintegrating the branches and/or cherry picking single commits without making things super complicated was very difficult. In those days, many folks adopted "trunk based development"...which meant...everybody worked on the trunk, and if you had conflicting changed you had to deal with it...RIGHT NOW. Moreover it made things like long running divergent branches a wicked problem when trying to bring back into the most people just "didn't do it".

Then Linus Torvalds Changed Things

Well, in fairness, distributed VCS tools had been around a while, but he sorta made "sharing divergent ideas and development paths" easier, or at least more cost effective. This was great for the linux kernel team and many folks relatively quickly adopted his new version control tool named git. git is a great tool, don't get me wrong, but I feel many of the problems it solved are not necessarily problems that a well run/organized software delivery organization has.

Gitflow Killed Git For Me

Some time back in the early 2010's, Vincent Driessen came up with gitflow which, to a very specific context...made a lot of sense. However, I feel he and his post have had the value of the concept victimized by the effectiveness of it getting mindshare without context. At the end of the day, for web applications and continuous delivery models...gitflow is "very often harmful" (Vincent actually added an addendum to that effect a few years ago). For packaged software running for different clients with different featuresets/chipsets/architectures...I could be convinced of it's value (as I can imagine it, but I don't work in that kinda space so I don't have real experience to draw from).

But Back to My Point

At the end of the day, maintaining multiple codebases is HARD...sorry I mean REALLY HARD and not a problem you want to take on if you don't have to. For folks trying to do continuous delivery of software as a service or other api addressible solutions (think MACH architectures as an example), why would you even think about doing this? "maybe" I could imagine a team that has client specific SaaS solutions that they want to maintain "kinda" parity with, but other than that, most of the clients I work with are actually hampered by trying to solve a problem they don't have by overcomplicating thier branching strategy.

"There is only the next release"

I say this, because that's generally what a branch should represent...which is to say "only the mainline matters". If you're branching every feature, every project, every release, every're creating a maintenance and discoverability absolute nightmare. If there is incomplete work that shouldn't be released, you have a "software design problem", not a "branching strategy problem", and you should seriously start to consider "how can I design this new feature so that the code can go into the next release...even if it's not 100% complete...without breaking existing functionality.

Why I bring up feature switching

One approach to solving the previously mentioned problem is to include feature switches. This enables you to (at runtime ideally) switch new or existing functionality on or off based on an external configuration. This means if "add to cart and get reminder email if the cart isn't checked out in 20 minutes" feature isn't ready for production at the next release off the need to design up front for a switch that says "enableReminderAfter20Minutes" that by default is "off" and can be switched "On" in any environment at any time. Not only does this help fix the branching problem, but it also fixes the "proliferation of environments" problem that happens when you start arguing about "but the branch with the reminder needs to be in QA tomorrow" and the "branch without it needs to be in QA for 1 hour" to verify a potential problem in production. Instead of spinning up two environments, you just switch the feature off for 1 hour, verify what you need to verify, then switch it back on. Of course, you can always have another environment set up for long running breakfix activities or other things of that nature...but the environments all run the same code, just with different configurations. Put another way, eject these problems from the source code control context and into the environment/configuration management context. For further reading, I would suggest Gitflow considered harmful as well as Feature Toggles.

Friday, March 18, 2022

Experiential Commerce

I was building myself a diagram and stumbled across something in my library that I had totally forgotten about. At the time I had called it the "commerce triad" and realized there was a term in there that I think has a lot of relevance now. The term was "experiential commerce" and at it's root means roughly "meeting the customer where they are and enabling them to interact and transact with your brand while they're doing something else". I thought I'd share a rough sketch of what it means before I yet again forget about it.


Wednesday, February 23, 2022

On Software Technical Debt

What is technical debt?

Some examples of technical debt are:

  • Code that has error scenarios and will fail in certain scenarios in a way that is undesireable.
  • Code that doesn't perform as well as desired or (like above) performs well for some percentage of use cases, but other degenerate cases will not work as well as desired.
  • Software written in a way that requires undesireable manual workarounds or processes.
  • Software that is difficult to read, is undocumented, or otherwise makes maintenance more difficult that necessary.

Why does it happen?

In my experience, good developer incur technical debt in order to achieve some other business objective that has higher value than the debt incurred. For example...if I spend 5 minutes to write some hacky/difficult to read code that fails 1 out 100 times, but that enables my business to reap thousands of dollars of revenue, I might be inclined to "just do it". Of course, in my oh so humble opinion, I have the tools (experience, value mindset...whatever) to make these decisions and/or have an objective discussion around "should I spend 3 weeks writing the perfect solution...or spend 5 minutes writing a hacky workaround that I will have to rewrite 10 times to get "right"?

In addition to that reason, there is the "it's new, I'm inexperienced with the problem space, I don't know the programming language, ... "fill in the blank" reason that can cause it too. As an example, I know little to nothing about the Go programming language...but there is a specific thing I need to do (with some minor customization) that is relatively easy in "go". So I can implement this in 10 minutes, not realizing that I will overspend in the future with days or weeks of "something went wrong that I don't 100% understand.

How can you avoid it?

The way many many many folks avoid this problem is to slow down and only use tools they are very familiar with. As an example, many shops will "standardize" on a language/framework/saas tool in an effort to economise on "number of ways things can go wrong" but then they lose the opportunity to use a language/framework/tool that solves a particular problem in a much more economical way. This is usually done under the mantle of "standards" and "best practices" but it is usually only a crutch for newcomers to get familiar with the patterns already in use.

When is it good?

Going back to "Why does it happen?", it's good when you can reason about the leverage you gain from incurring the debt. Thinking in financial terms, many folks are totally OK taking on a mortgage for a place to live now, versus living in a cardboard box for 20 years so they can purchase thier very own home at that point. In the same token, taking on some debt now to solve an immediate problem is almost always a good idea. The rub is, however, you need to know the "interest rate" on that debt. Using the "home" metaphor, getting a mortgage on a house now that has a 50% APR, might not be a good idea (unless you're flipping and can make that back) and the same applies for code. If you're spending all your time servicing your debt, it's time to pay it down...if you're gaining leverage from your debt, you can pay it down if you want...but your money might better be spent elsewhere.

Thursday, February 10, 2022

B2B, B2C, B2B2C oh my!

Online Commerce

In the olden days, digital commerce had a "dividing line"... Businesses that sell to other businesses (B2B) and businesses that sell directly to consumers (B2C). In the recent decade or so, another model has emerged which are businesses that a) sell to both b) partner with other companies for portions of the solution.

B2B - generally B2B solutions are geared around selling large quantities (or very specialized/custom products) wholesale to customers who either a) use the products in the course of doing their business (think a robot supplier for an automaker). or b) resell the products to consumers in a retail setting (think a manufacturer who make soap and sells it to retailers).

Often what happens is that folks don't differentiate the nuance on what B2B actually means. For example, if a manufacturer sells a multi-million dollar tool to another manufacterer/service provider (think robots, earth moving equipment, airplane avionics testing gear) etc, these are generally relatively rare sales that have a tendency to have a long lead time.

However, there is another large group of B2B companies that sell high volume commodity items to consumers (think soap, toothpaste, dogfood, generally consumer packaged goods). These brands have an interesting opportunnity to sell both to retail outlets, but also directly to customers. Conversly, retailers (think big box retail, gas stations, drug stores) also have an opportunity to sell products they don't necessarily stock in thier stores to consumers and have "someone else" fulfill the product (think drop shipping/outsourced fulfillment models).

B2C, on the other hand, are companies/brands that sell and target end consumers of their product. Sometimes they actually manufacture the product, but generally they are focusing on merchandising, marketing, and fulfillment not manufacturing. These companies are the "customers" for pure B2B companies and historically have owned the consumer relationship. This is largely (IMHO) an artifact of the historical relationship where wholesalers sold bulk products they manufacture (build a great brand/product) versus creating an environment to foster sales to consumers (build a great storefront and place for consumers to discover products).

More commonly, there is a new model that is actually "both"'s called B2B2C (business to business to consumer). What's really interesting about this is it's expansion of scope beyond a single transaction and the endorsement that "it takes a village" to support a customer. What's more interesting is that when you talk to folks about what B2B2C and/or strategies, this is almost universal confusion.

This confusion arises because depending on your core business, what B2B2C looks like can be very different. Some examples:

  • I am a manufacturer of toilet paper, I run advertisements, have billboards, and sell pallets or trailers of products. Typically one order is for thousands, if not millions of units of product. I actually have never interacted directly with a customer...except for the time we accidentally produced TP with poison ivy in it...OMG that was difficult. I now want to sell directly to my end customers and provide them with reliable delivery options and customizable products. I've partnered with a large retail chain to actually ship product from the store nearest my customer to supply reliable delivery, but also partner with a company that takes a graphic that a customer supplies and prints it on toilet paper. I own the customer relationship and collect all the money and handle customer service, but I rely on two different partners for two different ways a customer wants to interact with me.
  • I'm a large retailer, I want an endless shelf of product, but my brick and mortar stores/distribution centers have limited capacity. Because of this, I partner with many manufacturers to get their products on my digital shelf. I rely on them to fulfill products that aren't stocked in my store, but also can sell thier products in my retail digital storefront and fulfill from my (often cheaper) wholesale product inventory sitting on my shelves.

As you can see, these two archetypical businesses have very different focus, but are arguably both within the B2B2C ecosystem. The important development is "who owns the customer relationship". Historically, retailers owned this relationship and would rely on wholesalers to supply product, but more and more the lines get blurred because there is a very low barrier to entry.

My core point is that B2B2C is not a monolithic "way of doing business" but more a philisophical understanding that there are many players in a particular retail transaction and and acknowledgement that it is often wise to let each player play to the strength they have in a particular part of the customer shopping/purchase experience, rather than try to do "everything".

The Metaverse versus The Immersive Web

Bold Prediction Much like the mobile versus web spectrum, VR/XR is having a similar problem. On one side there are "native apps&qu...