Architecture Principles

From Glitchdata
Jump to navigation Jump to search

E.06 Cloud First

  • Tagline: Adopt; Adapt; Buy; Build
  • Statement: Take a cloud first approach to ensure efficient and effective delivery of business outcomes through use of commodity services and reuse of proven solutions (see E.01).

Rationale

  • Organisation has clearly stated its strategic direction to use cloud computing services for all new solutions, and to migrate existing solutions to cloud where practicable (with due consideration of risk and value for money).
  • To reduce costs and deliver solutions to meet business outcomes quickly:
    • direct re-use of existing capability within existing solutions or technologies is preferred;
    • followed by the adaptation of existing solutions or technologies to meet specific requirements;
    • followed by purchase of SaaS/COTS (commercial-off-the-shelf) products;
    • followed by commercial products that can be configured or used as components;
    • build bespoke solutions only when other options are not viable or available (e.g. to address unique business requirements).
    • When buying, integrated systems made up of components which work together are better than an array of best of breed point solutions which are not integrated. The use of open standards, methods and technologies reduces vendor lock-in and allows for simpler and more reliable integration, interoperability and portability of solution components.
  • With cloud computing services, the preference is to choose SaaS over PaaS over IaaS (see Cloud Decision Framework for details).

Implications

Widespread knowledge and usage of the Cloud Adoption principles as found in the Cloud Transformation Strategy;

  • Use the cloud decision framework to assist with adopt/adapt/buy/build considerations in conjunction with risk and total cost of ownership, and to guide the selection of the appropriate cloud delivery models and data management solutions applicable to each business context;
  • Note that "Buy" takes on a different meaning when considering cloud services. Any use of cloud resources involves "buying" them - paying a fee for usage. However, there is a difference between:

additional usage of a currently subscribed service - this will not require any additional procurement action, but may require some level of governance;

  • initial usage of a new cloud service provided by an existing cloud service provider - this may require procurement action, and should be subject to governance controls;

forming a new arrangement for the use of one or more services provided by a new cloud service provider - this will require both procurement and governance actions.

  • Need to balance the consideration of "adopt vs adapt vs buy vs build" in terms of:
    • fit-for-purpose;
    • strategic directions
    • Whole-of-Government procurement vehicles should be used where appropriate and applicable;
    • As much as possible avoid contracts that lock the agency into particular solutions and limit the ability to make decisions to improve the service, however noting that business likely benefits from vendor-propriety solutions (such as cloud vendor SaaS and PaaS), undertake appropriate mitigating activities in those cases;
  • When building a bespoke solution:
    • consider future opportunities for reuse and/or purchase of solution components;
    • look to build reusable components, services and APIs for future reuse opportunities, either internally or with other agencies.
    • Adopt component-based and service-oriented design practices that promote the reuse of components;
  • SaaS/COTS products should be preferred for generic business functions (as typically found under "Enterprise Management" and "Business Enablers" in the Business Capability Model e.g. resource management, content and information management, productivity tools, and application delivery tools);
  • SaaS/COTS products that provide reusable components and services are preferred;
  • SaaS/COTS products that are based on technologies and standards already adopted by are preferred;
  • For the adoption of a SaaS/COTS solution, must be prepared to re-engineer current business processes to utilise the product's standard processes and out-of-the box functionality, prior to any consideration of product configuration or customisation. Government policy requires agencies to use unmodified COTS products for Financial, Human Resource and Records Management solutions;

Open source solutions should be considered equally along with commercial solutions - Government policy mandates this, and open source solutions frequently offer superior value for money and support for standards and interoperability. However, only mature products with a proven track record should be seriously considered;

  • While there is a preference for the adoption of proven, market-tested solutions, there remains scope for the evaluation of immature or unproven emerging technologies where those may support business innovations or enable opportunities;
  • Develop and maintain architecture models and design patterns that promote reuse;
  • Need to develop and maintain a repository for models and patterns;
  • Need to develop a process to review, maintain and promote the use of models and patterns.
  • Staff will need to be trained to enable the adoption of cloud computing and related open standards, methods and technologies.
  • Type Enterprise Architecture
  • Version 0.2



Application Architecture Principles

A.01 Granular and Loosely Coupled

Tagline	Business solution components to be Granular and Loosely coupled.
Statement

Promote:

The SOA approach and longer-term integration opportunities; Critical thinking in achieving short term gains whilst considering long term goals; Deeper consideration for the alignment of business outcomes with underpinning ICT architecture; Getting an appropriate balance between granularity and reuse; APIs as the preferred mechanism for solution component integration and service consumption. 

Rationale

Granular and loosely coupled solution components provide flexibility in both accessibility and deployment implementations; Granular, reusable solution components are key to increased productivity, rapid solution development and deployment, and greater resilience and scalability; The adoption of a SOA architecture and approach, along with the use of a SOA toolset promotes and supports loosely coupled design. Implications Build services with responsive design methods using contemporary microservice and API technologies and design patterns; Solution architecture should consider the possibility of re-partitioning components in the future (getting the granularity right early through the use of analysis and design methods such as domain-driven design (DDD)); Managing a greater number of finer-grained services demands mature capabilities in design, integration, testing, deployment, automation, operations and governance; The use of single monolithic databases in conjunction with microservices is an anti-pattern; Adherence to SOA principles drives planning for both extensibility and scalability; Solutions can evolve to support evolving business requirements; Attention to extensibility facilitates functional scalability; The focus is on building government services that are simple, clear and fast, and emphasises the need to rigorously test all service components during development, and for end to end testing in an environment that replicates the live version; Drives solution design towards greater reuse (assemblage/integration of components as opposed to custom build). Type Application Architecture Version 0.3


Tagline Business solution components to be subject to continuous integration and deployment Statement Fully automated releases of changes to business systems in timeframes that meet business needs, rely on automated testing, containerisation and deployment tools Rationale Small changes can be deployed in an automated manner at timeframes that match the business' request for change. Small changes reduce the associated risk of change Automated releases into a continuous integration/ continuous deployment (CI/CD) environment do not require any business or ICT down time Implications Build containerised components Maximise code coverage of automated testing Design, build and release incremental changes Test automated release and rollback Consider the user experience in design of releases Update existing components to support CI/CD Register technical debt for existing components & technologies not suited to CI/CD Type Application Architecture Version 0.1




Related


Links

Retrieved from ‘https://wiki.glitchdata.com/index.php?title=Architecture_Principles&oldid=38820’