One possible reason why it is rare to see really good large enterprise software might be because there are different boundaries of separation on the user side vs the software architecture side. But in most products, the user-facing separation seems to be tied to the software architecture-related separation, or the other way round (software architecture separation follows from the understanding of user separation). And this leads to either too much rigidity in the way the system works (in case of the user-first design approach), or a software that is too complex to understand (in case of the software-first approach).

In an ideal world, both these aspects should be considered explicitly when designing a product, both from the user’s perspective and the builder’s point of view.

Many people have written about how various specific systems should be decoupled. These have typically been written after a fair bit of experience and learning things the hard way. To me, the main instances when decoupling two systems becomes an insight seems to be when the builder’s default instinct is to tightly integrate/couple the systems, but the users using the two components are completely different. The users might belong to different teams, and have totally different skills, priorities and/or objectives. This is actually where machines shine - where the heavy lifting to translate what each kind of user understands is done automatically.

Some examples

I guess this sounds a bit abstract - perhaps a few examples can help.

• metering should be decoupled from billing. I’d say this is a relatively new insight. Most legacy billing systems have these tightly coupled. Stripe billing is the only one out of the older ones that only recently decoupled these after its acquisition of Octane. The main reason these two systems should be decoupled is that, it is typically the developers or service providers (in non-software businesses) that meter usage, whereas some combination of sales, strategy, product and marketing that typically creates commercial agreements. To create bills, the default builder instinct is to build these into the same tightly coupled system, but doing this causes at least one of the stakeholders to do more than they care about. In most systems, developers draw the short stick and have to deeply understand their billing systems to integrate them. In many cases, developers end up actually having to build their own billing systems 🤦 (or a layer on top of it)
• entitlements should be decoupled from billing. It’s very similar here. Developers, service providers and end customers are users of entitlements, whereas sales & marketing are the ones creating contracts and assigning entitlements to customers. Tightly coupling these two systems results in developers having to understand the intricacies of their billing systems to do something so basic as managing entitlements. Or building their own 🤦.
• Metering and entitlements should also be decoupled because different customers could have different ways of interacting with entitlements based on their respective contractual terms. And the same kind of usage could affect entitlements differently for different customers. This is because although developers are the users of metering, in this context, sales and marketing are the people who decide how to determine what various entitlements should be, package the various entitlements and sell them. End customers are also users of these entitlements for transparency in understanding what they have purchased and what they have access to.
• Revenue accounting should be decoupled from billing. This could be a whole article in itself XD. From my understanding, this was one of the main challenges of Google’s internal financial operations automation. Here as well, the users of revenue accounting are accountants and are, in most companies, very different from people who manage billing
• Analytics should be decoupled from billing and accounting. The same thing applies here: different users are looking for insights compared to users who are business operators.

Why this happens

In the case where the software architecture happens first: Builders are great at building, but typically end up thinking in terms of functions (or apis), inputs & outputs. The problem is that this doesn’t necessarily relate to how users think and leads to problems with how software is built and structured. The more evolved this gets, the more dependent users become on documentation. And as time goes on, learning the documentation (which has now become a book) becomes so important that there are experts who need to specialize in said software to be able to use it (or, in slightly better cases, configure it). This results in needing training to use the software.

In the case where user research happens first and governs the direction of building, User research leads to product designs, which are then implemented into software. This, in most cases, leads to systems where any additional extensions require redesigns and extensive rearchitecting of the underlying software architecture because these weren’t considered when deciding on the direction of building.

The results of this

The result of the badly built separation of concerns is that the core software was easier to build, but the users have to do more in terms of time and effort, and in some cases significantly more to

• understand another stakeholder’s domain and objectives
• spend time on bridging the gap between the two stakeholders to get said software to be useful for them

This leads to a drain on resources in multiple customer companies, in terms of manpower, time and money. The strange thing is that the companies think that this is effort that is custom to them. Little do they realize that this is the same story across all customer companies.

This leads to an ever-expanding industry of “system integrators” creating customer-specific custom software that is typically not well-tested or maintained and causes endless frustration.

How to overcome this

This is just my simple opinion based on my experience, so please take this with a pinch of salt. I could be totally wrong here 🙂.

I think that both user personas on the design side, and software architecture on the building side should be determined together based on the product vision. Especially in products that cater to different kinds of users. Any one preceding the other results in the users suffering - either in terms of limitations in what the product can do long term, or in comprehending how to use the product.