We are creating a hub & spoke operating model for our Reporting & Analytics developments. I'm looking for best practices to define what demand is delivered from within the hub, or federated out to the spoke? We're thinking a Red / Amber / Green scale of complexity, based on things like data size, resource availability/capability etc. Any thoughts?

In the context of Reporting & Analytics, here are some thoughts when you set up a hub & spoke model:

1. Don't make the Hub vs Spoke decision based on complexity / data size / resource availability. You should do it based on the breadth of business value OR business criticality. For example, if something is critical or essential for your business, even if it's simple, it needs to be served from the Hub. Similarly, if something is expected to be widely used and not limited to a single team, then it should be from the Hub. 

2. Federate only items that are very specific to a team or are of transient use to a spoke.

3. Developing the initial reporting & analytics is just half the value - ensuring that it's reliable & accurate everyday is what will drive value for users. So ensure that the responsibility of the Hub / Spoke does not end with just development, but includes ongoing monitoring & maintenance.  There are bound to be many job failures, changes in upstream systems etc. reasonably frequently and hence the Hub needs to own anything that it develops from End to End.
 
Additional Responsibilities of the Hub:
 a. Define guidelines / standards for reporting: This will ensure reasonable consistency irrespective of where the development happens.
 b. Maintain Inventory: Ensure that the Hub holds a full inventory of reports / analytics with key info such as Topic, tech platform used, Frequency etc. If possible make it open & treat it like a portal for all reports & analytics (that way spokes will want to be listed for easy access).
 c. Pre-check for duplication: Every time before any new development, ensure that both the Hub & Spoke refer existing asset inventory to avoid duplication. If a different spoke needs access to an existing report, it's a good candidate for promotion to Hub.
 d. Monitor for Promote, Demote, Retire: Create ongoing reports from the underlying tech platforms to monitor usage. Review quarterly usage to identify reports that should be promoted to Hub or demoted to Spoke or even retired

Happy wheeling !!

My gut reaction to this statement was 'don't do it!'.... 

However, reading peer comments and taking a moment - it can work if you really think about what business problems you are aiming to solve (with this model) - and putting the lead roles for each capability in the centre with a very strong set of Centres of Excellence type governance in place. 

My experience is that depending on the size/scale of your organisation, this model creates a lot of inefficiencies from a people, process, technology and even data perspective. The spokes can evolve to become their own businesses, with their own everything - and once you go down this path - very difficult to re-centralise. 

Ensuring that best practice, great data products are available and shared across the model isn't always easy  - but I do believe if you can set this up right from the start, with the right people with the right mindset (invested in the mission of your enterprise), then you can avoid a spoke turning into a silo... 

There are several good architecture designs for this but it depends on your infrastructure. Cloud vs on-premises vs hybrid for example. 
Most things that are whole-of-organisation services like printing, IDAM, etc will be centralised. 
In general
Hub Functionality:
The hub should handle core services like security, data governance, and potentially common semantic objects, providing a centralized point for resources and control.
Shared Services:
Minimize redundancy by offering shared services (e.g., cybersecurity, data governance) from the hub.
Centralized Logging:
Implement central logging and monitoring to gain a comprehensive view of the entire network's performance and security.
Transit Gateway:
Utilize a Transit Gateway to create a central hub for network traffic, facilitating communication between different spokes. 
Spokes:
They should contain location or domain specific services. Things like local storage if required or applications deployed for particular groups. If it is only used by a small sub group, it probably belongs in a spoke. 

We recently moved to hub and spoke. Our surprise was that our domain data experts werent as technology and data strong as we expected. Now we are building a strong training plan to support them. Doing it again I would design the target state and job description, do a learning needs analysis and when the analysts meet the target they move to spoke, until then leave it in the Hub. It sounds very "HR-y" I know