Back to home page: Economic Architecture

<aside> ⛔

This is a page under construction; the reader is expected to read with caution and imagination

</aside>

My emerging list of principles and constraints that are to be adhered to if one is to successfully develop and run an economic architecture.

• Minimise unilateral decision-making power
  • Limit the duration over which power is assigned
  • Limit the scope of power, separate power as required
• Maximise accountability
  • Cyber-Meta-Physical engineering design necessitates trade-offs the means market forces are not always achievable in practice
  • Markets are a good form of accountability, for as long as market forces continue to exist
  • Fastidious transparency is a valuable tool, particularly where market forces are absent
  • Open-sourcing is an excellent mechanism for designing in accountability and therefore earning trust
• Silos are an unavoidable feature, not a bug. Plan for their need to adapt and change over time
  • Natural constraints over actors’ ability to exchange information drive their existence
• Data and technology are adjacent concerns, but they are orthogonal and to be treated independently of each other
• Prefer to integrate data first, then standardise data (and technology) and only then start to create standards; standards should follow, not lead. Once you are started, cyclicly iterate between these refining these domains
• Where independently governed actors share an interest in a public (or private) matter, adopting the stance of ‘presumed sharing’ of all of the relevant human-readable and machine-readable information is essential for inclusive participation
  • Use of ‘presumed’ in this context is as per the context of the Ofgem Data Best Practice ‘presumed open’ data sharing
• Machines are - by definition - integral to the existence of any digitalised solution; treat your machines as any other user and represent their interests; advocate for their needs as they cannot speak the human tongue of true extrapolation
• As far as is practicable, atomise your delineations and definitions of design features to maximise your ability to control and gain flexibility over how your architectural system is operated and updated
  • Atomisation of investments ensures that large/long/complex (’infrastructure’) investments pose minimised risks that benefit from rapid feedback for course-correction
• Make your investment decisions informed by immediate (end-point) applications for your architecture and equally by the (input) capabilities that can reasonably be made available, even where (sufficient) use cases are not immediately identifiable for that capability
• ‘How’ to best deliver your architecture is inherently more complex than agreeing ‘what’ architecture to deliver. Allocate your effort and resourcing accordingly
  • Rule of thumb, spend 5-10% of resources on ‘what’ to do, and 90% of your time on ‘how’ to do it
  • Use your experience testing and prototyping ‘how’ to deliver to course-correct, ‘what’ you plan to do
• Adopt a stance of Continuous Discovery and Continuous Development
• Work with the intention of enabling computers to participate in the economy as much as human beings
• It’s not a legacy system, it’s your starting point. Leave your emotions and cynicism at the door. Review. Design. Plan. Deliver. Get on with it
• Set the responsibilities of ‘single-service providers’ (typically monopolistic service providers and public silos) to be to put capabilities to best use as a higher priority than delivering the best outcomes for a pre-define group of users (e.g. set the terms of reference of your energy regulator to be responsible for ensuring energy assets are put to best use and not for ensuring energy consumers are served). This will ensure that where market forces are absent, actors will work ‘with their arms open’ instead of as silos to an extent greater than is practically necessary. This is ‘Integration-by-design’ and is remidied by making updates to ToRs
• Know your constraints and how they are distinct from your objectives: ethics, security, privacy are constraints on design options; they are not dedicated objectives in of themselves