TOGAF and the Architecture ‘Continuum’
The Open Group has a detailed set of frameworks and approaches for IT architecture (http://pubs.opengroup.org). These frameworks are for IT systems architecture design, development and deployment. They are not specific to Cloud Architectures, but can be used when building a de-novo Cloud solution, or migrating to a Cloud Platform and reforming your business and IT architectures. AWS’ CAF (Cloud Architecture Framework), is based on TOGAF for example.
TOGAF is a valuable tool for any architect, but given that it is a collaborative effort with 300 odd specialists contributing, you need to pick and choose what is relevant for your project. It should be added that many of the approaches and methods within TOGAF are unnecessarily opaque, academic and repetitive. In spite of that caveat, it is still a very useful tool for solution architects.
TOGAF’s Architecture Continuum
According to TOGAF every architecture (business, IS, technical), is a ‘Continuum’ from a beginning to the end. The main elements within the Continuum are:
This Continuum runs basically from ‘generic’ foundation principles and architectures, to the company-specific. Each one of the 4 elements mentioned above run within this Continuum.
For an architect looking to build an Organisation-specific architecture(s), the Continuum provides some useful ideas on how to achieve this:
This phase uses generic components, inter-relationships, principles and concepts to provide a foundation on top of which more specific architectures will be built. Components would include hardware, software, integration concepts, applications, databases and platforms. The foundation will include the main elements of your target operation model (IT and Business). Note that you will have to understand your current model and gaps in moving from the current to the future target model.
Common Systems Architectures
The purpose of a Common Systems Architecture is to provide a common platform in which there are common, reusable solutions across many domains. This would include the integration of services from the Foundation Architecture to create a unified architectural view.
Some examples of CSA’s would include:
Each ‘sub’-architecture is incomplete if we look at overall system functionality, but within its own domain or scope, it should provide a complete solution to that specific problem domain (security, manageability, networking, operations, etc.). This will mean that solutions implementing re-usable building blocks for the creation of functionally to complete operating states of the enterprise.
Common Systems Architectures also include:
IA’s may be relevant to act as a guide for the integration of common system components with industry specific components (eg in Telecoms, Banking etc). IA’s exist for quite a few domains including and could contain the following:
Organization-Specific Architectures can help the architect with the final deployment of solution components for an enterprise or extended network of connected enterprises (a building block component is one component eg a DB; whilst a solution component is the combination of building block components eg a DB, Web app, Front End).
To build Organization-Specific Architecture which customise more generic and foundation-architectures, the following are true: