Charity
We have started an affiliate organisation as a contribution towards Charity for a much needed requirement to train up the aspiring under-privileged and indigent youth in South Africa and Africa.
Check it out – you can find all the information at https://train44ir.org
Information & Data
I happened upon a really great Data Fabric model done by Alan McSweeney and thought it would be useful to have this Data Fabric Framework in modelled Archimate 3.0.
Alan kindly sent me the original to look at in more detail and be able to cut and paste quicker. He gave me permission to convert it and even collaborate on making it it better in the process.
This is a high level view of the various components necessary for a holistic Data Fabric framework. We have a more detailed model for each of these component packages in each of the sections below.
This model is the A0 sized page that contains all the information needed. Each of the packages in this model, are modelled separately in the sections below with the same names as the fabric component name.
These are the range of external parties that supply data to and access data from the enterprise.
These are the set of applications and data interface and exchange points provided specifically to External Interacting Parties to allow them supply data to and access data from the enterprise. These can be hosted internally or externally or a mix of both.
These are applications and sets of data created by the enterprise to be externally facing where external parties can access information and interact with the enterprise.
These are third-party applications (such as social media platforms) that contain information about the enterprise or that are used by the enterprise to present information to or interact with
External Interacting Parties or where the enterprise is referred to, affecting the perception or brand of the enterprise.
Sources of remote data measurements.
These are devices connected with services offered by the enterprise (such as ATMs and Kiosks).
This is the set of facilities for handling data supplied to the enterprise including validation and transformation including a possible integration or service bus. This can be hosted internally or externally or a mix of both.
This represents the set of line of business applications deployed on enterprise owned and managed infrastructure used by business functions to operate their business processes.
This represents the set of line of business applications deployed on external infrastructure used by business functions to operate their business processes This includes cloud facilities such as external data storage and XaaS facilities and an integration service to connect external data to internal data
These are applications used by individual users to view and author documents.
Operational Data Stores – These are the various operational data stores used by the Line of Business Applications. Unstructured Data Stores – This provides structured access to documents and information including externally hosted applications providing these facilities.
These are the various operational data stores used by the Line of Business Applications used by Line of Business Applications Hosted Outside the Organisation.
These are facilities to create and manage master data and data extracted from operational data to create a data warehouse and data extracts for reporting and analysis. This includes an extract, transformation and load facility These can be hosted internally or externally or a mix of both.
This represents the set of facilities to extract operational data from business applications, create, store and manage reference and master data, create and store enduring data and analyse the data including reporting, visualisation, mining and modelling. These can be hosted internally or externally or a mix of both.
These are facilities to create and manage master data and data extracted from operational data to create a data warehouse and data extracts for reporting and analysis. This includes an extract, transformation and load facility These can be hosted internally or externally or a mix of both.
You are free to download the printable versions in .PDF form. We may have more discussion and refine these models. Of course we also welcome comments and recommendations for improving these models as well.
Data Fabric Architecture (High Level) PDF. (A3 or A2 size)
Data Fabric Architecture (More Detailed Level) PDF. (A1 or A0 size)
Cloud Openstack
This blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Orchestration in Archimate – Part 9.
Ceilometer project is for monitoring and collecting data regarding to resource usage in the cloud infrastructure.
Mission: Ceilometer is to provide an infrastructure to collect any information needed regarding OpenStack projects. It was designed so that rating engines could use this single source to transform events into billable items which we label as “metering”. As the project started to come to life, collecting an increasing number of meters across multiple projects, the OpenStack community started to realize that a secondary goal could be added to Ceilometer: become a standard way to meter, regardless of the purpose of the collection. This data can then be pushed to any set of targets using provided publishers mentioned in Publishers section.
If you divide a billing process into a 3 step process, as is commonly done in the telco industry, the steps are:
Ceilometer’s initial goal was, and still is, strictly limited to step one ‘Metering’. This is a choice made from the beginning not to go into rating or billing, as the variety of possibilities seemed too large for the project to ever deliver a solution that would fit everyone’s needs, from private to public clouds. Ceilometer is a component of the Telemetry project. Its data can be used to provide customer billing, resource tracking, and alarming capabilities across all OpenStack core components.
Previously, ceilometer used mysql as for backend storage. Currently, it is passed off to another Application Collaboration called gnocchi that does the backend job using mongodb. Ceilometer also has a Command Line Interface (CLI).
Each of Ceilometer’s services are designed to scale horizontally. Additional workers and nodes can be added depending on the expected load. Ceilometer offers two core services:
These are the REST & CLI Services offered by Ceilometer for Monitoring used to be found here: https://docs.openstack.org/developer/ceilometer/webapi/v2.html. They are now deprecated as the storage elements have moved over to Aodh [Alarms], Gnocchi [Metrics] and Panko [Events].
This file is shared under the GNU General Public License (GPL). You are free to download it and use it as you like. You can either make use of your own Archmate Tool and download it in .archmate format, or use your own tool that support the Open Groups open Exchange File format. These files are both compressed into a .zip file.
| Tool that supports Archimate notation & content | Model File – click to download | File Format |
| Download the Free Opensource Archimate Tool | Cloud Hosting – OpenStack Model | .archimate Model file in .zip |
| Opengroups – Open Exchange File | Cloud Hosting – OpenStack Model | .xml Model File in .zip |
Cloud Openstack
his blog on Openstack modelled using Archimate follows on from the previous Blog on OpenStack Cloud Identity in Archimate – Part 8.
Mission: Heat as the OpenStack Orchestration program is to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds. Why Heat? It makes Clouds Rise!
Heat is the main project in the OpenStack Orchestration program. It implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. A native Heat template format is evolving, but Heat also endeavours to provide compatibility with the AWS CloudFormation template format, so that many existing CloudFormation templates can be launched on OpenStack. Heat provides both an OpenStack-native ReST API and a CloudFormation-compatible Query API.
This Architecture appears to be in a state of constant refactoring and enhancement, so follow the Architecture here: https://wiki.openstack.org/wiki/Heat/Vision
Orchestration services to create and manage the life-cycle of cloud applications are described like this:
The next blog in the series is OpenStack Cloud Metering in Archimate – Part 10
Cloud Openstack
This blog on Openstack modelled using Archimate follows on from the previous Blog on Openstack Cloud Object Storage in Archimate – Part 7
Keystone is an OpenStack service that provides API client authentication, service discovery, and distributed multi-tenant authorization by implementing OpenStack’s Identity API. It supports LDAP, OAuth, OpenID Connect, SAML and SQL. It offeres Role Based Access Control (RBAC).
Keystone provides a single point of integration for OpenStack policy, catalog, token and authentication.
Keystone handles API requests as well as providing configurable keystone (service & admin APIs) catalog, policy, token and identity services.
Standard backends include LDAP or SQL, as well as Key Value OpenStack token backend, catalog backend, policy backend and identity backend stores (KVS).
Identity Service Most people will use this as a point of customization for their current authentication services.
These are the REST & CLI Services offered by Keystone for Identity. For each Service below there are one or many sub-services or commands that can be found here: https://developer.openstack.org/api-ref/identity/v3/
The next blog in the series is OpenStack Cloud Orchestration in Archimate – Part 9.
You must be logged in to post a comment.