If you want to make enterprise integration needlessly complicated, follow these tips.
1. Model poorly
A poor model is always a nice way to make things more complicated than they should.
Examples: You can name thing badly. You can model everyting as strings (key, list, etc.). Or you can reuse overly generic abstractions in multiple contexts instead of defining one abstraction per context. Or you can expose a relational model instead of an entity model.
2. Use immature technologies
Whenever possible, use immature, non-standard, or inappropriate technologies to make the integration complicated.
Example: Don’t use XML but JSON. Its support in IDE is still weak, its semantics for the various numeric types is poor, it prevents proper code generation (for class-based language), and JSON-Schema is still a draft.
3. Assume the network is perfect
Assume the network is perfect. It has infinite bandwidth as well as zero latency. This is a classic for disaster. Ignore completely the reality of networking. If your interface is sound at the logical level, then it will be fine in production.
Examples: Don’t distinguish between the time of the event you model and the technical time when the message was sent or received–it doesn’t matter since latency is zero. Or send replies to individual requests on a topic and leave the burden of filtering out the irrelevant replies to the subscriber at the application level–it doesn’t matter since bandwith is infinite.
4. Make loads and updates asymmetric
It is common for an interface to publish updates on topics but also provide a mean for the consumer to load data upon startup. In such case, the system should work so that the same data are delivered to the consumer for loads and updates. To introduce subtle data inconsistencies, make it so that loads and updates don’t deliver the same data.
Example: If an entity has multiple status, do not publish all status changes per updates. This way, there is a discrepance between the data you obtain per load requests and per updates.
5. Make the system as stateful as possible
If you find a way to complicate state management, go for it.
Examples: Instead of publishing entities that are consistent, publish only the delta with what has changed. The consumer must carefully ensure that all deltas are applied in order. Or define requests that reference other requests, e.g. to implement paging. The provider will need to do some bookkeeping of the previous requests.
6. Leave the protocol vague
By defining the transport technology, the encoding, and the various messages that can go through your interface, most readers of the specification will have a good understanding of what the purpose of the interface is. So stop there. Don’t bother explaining the exact protocol with the assumptions about the order of messages or when a given message can be sent or not. This way, you leave the door open to non obvious misunderstandings.
Example: don’t specificy which requests can be used anytime and which should be used only occasionally after a restart or recovery.
7. Don’t properly version your interface
Your interface will need to change. Don’t provide proper versioning. This way, supporting multiple versions will be a pain.
Example: Use XML Namespaces, but don’t use it for versioning.
8. Redefine the semantics of data between versions
Do subtle changes to the meaning of the data, so that the semantics changes in a non obvious way.
Example: Redefine what “null” means for a certain attribute.
9. Don’t distinguish between endpoint and tenant
Your interface will be accessible through an endpoint that will probably be used from multiple consumer systems (“tenant”). Define SLA per endpoint, but not per tenant. This way you will need to deploy multiple endpoints to really guarantee SLA for specific consumers.
Example: provide a limit for the frequency of load requests at the endpoint-level, but independent of the consumer systems. If a consumer misbehaves, it will prevent all other consumers from loading data.
10. Ignore monitoring needs
Do not provide any meaningful way for the consumer to check whether the provider is healthy or not. Either the consumer will have to guess, or it will have to use feature not designed for monitoring to assess the system health.
Example: aggregate data from multiple decentralized subsystems and publish them via a centralized interface, but don’t provide any way for the consumer to figure out which subsystem is healthy or not.
More
- You can ignore a lot more NFRs besides monitoring (security, availability, etc. ) to make sure your interface sucks.
- You can fail at other things too! For instance, How to Fail with RUP .
- Also some good points here on how to create complexity generally: Narcissic Design
- Recommend read: API Practices If You Hate Your Customers
://ewernli 