The more that I understand about software architecture, the more that i think it applies to companies. That is, every company is an information system. A company takes requests from customers, passes those requests to business units, that satisfy the requirements of the request using different internal, or external services,. to produce a service, or product, as requested by our client.
I have no doubt that I’m not the first person to notice this, in fact Domain Driven Design focuses heavily on ensuring that the software systems built for a company reflect the company itself.
Conway’s Law also points out how closely the software created by a company matches the company’s communication structures.
I’m pointing to the opposite though, that companies are information systems, and can be looked at in much the same way as multi-threaded, multi process, or even microservice based, systems.
Once you take this mindset to a company, you can start applying some classic patterns to it. I’ve already alluded to a microservice system, but lets start with the basics.
Start with Designing Multi threaded applications. These three patterns are going to be used and repeated and combined many many times, just like the software.
An example company, that does catalogue sales, will have a Pipeline, where calls will be received by the sales team from customers making requests for some products. The calls will be noted down, then passed to a procurement team that will pick the products from the warehouse, pack them, then send them out to the customer.
The first stop, the sales team answering calls, we need many, many people answering those phones. so the pipeline starts when calls are received by a VoIP or PBX system that fans calls out to the people answering, many Peers.
Sounds very similar to a Load Balancer that is passing requests to many API services already doesn’t it.
As said before the call takers note down the details of the request and pass that information to the appropriate procurement team for fulfilment. There can be many teams that fulfil requests.
So we are again going to employ a Peer model. All the peers see the request, and one of the peers that can fulfil it grabs the request Event driven architecture anyone?
As it turns out the we’ll employ a Boss Worker model in the fulfilment peers. The peers themselves will send requests to different parts of different warehouses asking for various things as required by the initial customer request.
These peers are the bosses, and they will wait for responses from the downstream workers on the fulfilment. Precisely what models are used by those downstream services is left as an exercise for the reader. One thing, though, is that if the fulfilment peer is isolated from the exact details that each downstream service requires, then some decoupling can occur, and that is starting to look a lot like Hexagonal Architecture.
Once the customer’s request has been picked and packed, it’s ready to be transported to the customer.
As I write this, I struggle to think of a business that isn’t, at its core, an information system. Whether a massive warehousing company, like Amazon, or Walmart (where the retail stores are the fulfilment peers, with local caches), or a neighbourhood Car Mechanic.