One of the key learnings from the book ‘Simple Architectures for Complex Enterprises’ is around partitioning of functions in order to simplify the overall architecture.
Partitioning in this sense is a mathematical term for splitting up the area in question into sections (partitions) such that any item is in one and only one partition, and that every item in a given partition shares the feature or features that define membership of that partition.
An example would be dividing store stock by price e.g. items at £5, items at £10 and items at £15. All items in the items at £5 partition would share the property of costing £5 and be found in only the £5 partition and no other partitions.
Partitions can be chosen arbitrarily as per the above example (which may be a valid way for a store to partition its good for stock taking or whatever), but in when talking about technical architectures for a business more thought needs to go into how to partition up the architecture to enable simplification, but also to create valid and usable partitions.
Within an architecture it transpires that the best way (or one of the best ways) to partition a system is to look at the functionality of components and then assess whether a components functionality is autonomous with regards to other components or synergistic. E.g. do the components in question have a mutual dependency on each other (if so they have a synergistic relationship), if they do not have this mutual dependency they can be considered autonomous of each other.
By separating an enterprise architecture up in this way we end up with a group of partitions where all components in each partition have synergistic relationships to each other, but components in separate partitions are autonomous in relation to each other.
In addition to being likely the best way to partition an architecture for simplicity while maintaining a manageable number of partitions, this method also translates well to the use of Service Orientated Architectures (SOA).