Aligning technical infrastructure with business needs: Strategic use of hardware

Last time out I talked about the general concept of aligning technical infrastructure with business needs, using concepts from Udi Dahan’s Distributed Systems/SOA course , Scott Millett’s DDD book and relating them to one of my own little adventures.

This time around I’ll look at the options that opened up for my particular use case, and again I’ll refer to some of the theory from Udi’s course to help you build a mental model.Autonomous Components

If you’ve had the chance to attend or watch Udi’s course you will know that services (proper SOA ones) are composed of multiple business components (BCs) which themselves are composed of multiple autonomous components (ACs).

Importantly, you should think of autonomous components as individual use cases that are independently deployable. Ultimately, this gives you the flexibility of putting important use-cases on a really expensive box, whilst others can be given a more cost-effective home.

Without ACs, you have bigger applications combining use-cases that cannot be physically separated, which therefore must reside on the same hardware. If vertical scaling is cost-effective for you then there’s no reason to change anything.Back to our example

Back in the last post I talked about our team discussions which resulted in us unearthing a real diamond — the concept of priority customers. We were eventually told by the business that there is a 4 tier grading scheme. That’s quite some breakthrough considering we are currently spending equal amounts of time, money and general resource on all grades of customer.

Thinking back to Udi’s concepts, there is an obvious way we can address this — we can create multiple autonomous components. We could initially create two to keep it simple — 1 AC for the top priority (or priority 1 and 2) and another AC for the remaining priorities. Later we could create 1 for each tier, maybe.

After talking to the business more, we might find out that it makes sense to cluster or add redundancy to the high priority AC, while the standard priority AC can be given a lot less consideration. How much consideration? — talk to the business.

Just the start

Separating use-cases and provisioning hardware based on the needs of your business is only the first step, albeit incredibly important. It puts you in a position to be able to adjust more rapidly. Consider in our example some of these scenarios:

A customer becomes more important
The service offered to priority customers degrades to a harmful level (i.e. they might kill the relationship)
New customers are added and you don’t want to disrupt the level of service to existing customers

We can easily adjust the level of service offered on a per-customer basis by adjusting which AC a customer is serviced by, or which arrangement of hardware an AC is powered by.

When ACs are split like this, causing business concepts such as high and normal priority to be explicit, every bit of code added will have the question asked — should this be the same for normal and high priority customers. It has the potential to lead you back to the business asking more questions, and subsequently more breakthroughs.

An assumption made is that you know the level of service you are providing. It seems logical that in many cases you will be able to capture these metrics more easily, and at a more granular level, if you have your ACs split up. For instance, you can plan for future capacity based on hardware resource usage for important and priority customers separately — providing the business with more information as well.General Applicability

You don’t need to be doing SOA to benefit from the concept of autonomous components or the concept of aligning technical infrastructure with business needs. In fact, at a high-level, you can break it down into a few steps:

Talk to the business (using some of the techniques alluded to in the last post to dig up implicit business rules)
Align your code if possible (e.g. change just the logic — run certain jobs more frequently for priority customers)
Split your code into independently-deployable use cases (which conceptually may or may not be ACs)
Deploy your individual use-cases in a way that maximises hardware usage in-line with business needs