Digital Architecture fundamentals

As part of a recent project, I was asked to come up with some architecture fundamentals of a digital system (not just a one application system, but a more complex and integrated solution assumed to be for a larger organisation).

Here’s my list:

• The architecture of a system or integrated systems needs to align to (or fit into) the overall ‘As-Is’ and ‘To-Be’ enterprise architecture of your organisation.
  
• Those creating the architecture need to first understand the business goals (e.g. the customer experience and commercial aims) and the major applications that ‘the business’ are likely to need in the medium term or have signed longer-term contracts with.
  
• A loosely coupled architecture provides the flexibility to use best-of-breed solutions from a range of vendors. The opposite is that either through design or legacy system adoption, your architecture shackled to one key supplier who is then possibly also integrated directly to multiple other systems… this obviously creates a dependency upon this key supplier, making them harder to subsequent remove and replace. Adopting a loosely coupled architecture also means you are not tied to specific front-end software, allowing your organisation the flexibility to either buy or build (typically using agile product & developers) to create the best user experience possible.
  
• Where possible, create a single in-house database, that can be updated by any other integrated systems… ideally in real-time. You don’t have to store all data that exists in every other integrated systems in this central repository, just those that you may need to align other data to at some point in the future.
  Note: It is possible that this service could also be provided as another integrated system, but for overall speed, agility and ultimately data ownership you may find it best that this database sits within the boundary of your main architecture. However, this does come with additional considerations: there is an overhead in managing and administrating a significantly large database, plus the data model used needs to be sufficiently flexible and scale-able to handle a variety of requirements over time.