Skip to content
Agile Enterprise Architecture
  • Home
  • Services
    • Remote Services
      • Looking for EA modelling?
      • Why Arch-as-a-Service?
      • Modelling-as-a-Service
      • Assess Arch Maturity Free
      • Arch Modelling Notations
        • Archimate model types
        • Quadrant model types
        • Canvas model types
        • UML model types
        • BPMN Model types
        • DMN Model types
        • ERD Model types
        • Structured Info types
        • Cisco model types
      • Arch Modelling tools
    • Consultancy Services
      • Digital Integration Services
      • Business Architecture
      • Health check services
        • Arch Risk Assessment
        • Arch Governance checkup
        • Arch Models health check
        • Arch Content health check
    • Cloud Hosting services
      • EA SaaS – Orbus iServer
      • EA SaaS – EVA Netmodeler
      • EA SaaS – Dragon1
      • Meta-Model Structuring
  • Blogs
  • About
    • Our AgileEA Business Model
    • Our AgileEA Principles
      • Open & Transparent
      • Value for money
      • Keep it simple
      • Love what we do
      • Efficient & effective
    • Location

Blogs

Cloud Openstack

OpenStack Cloud Dashboard in Archimate – Part 2

  • 2017-04-272018-05-08
  • by Charles

Previous

This blog on Openstack modelled using Archimate follows on from Openstack Cloud in Archimate – Part 1.

Horizon = Dashboard Functionality

Mission: Horizon is the canonical implementation of OpenStack’s dashboard, which is extensible and provides a web based user interface to OpenStack services.

Horizon = Dashboard Architectural Goals

Horizon = Dashboard Structural Logical Architecture

  • Is “stateless” — doesn’t require a database.
  • Delegates error handling to the back-end.
  • Doesn’t support all the API functions exposed by the other Openstack Applications.
  • Can use memcached or database to store sessions.
  • Gets updated via API polling.
  • Uses Django Project, which is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. See more detail on Django here: https://www.slideshare.net/balakumarp/django-framework
  • It can be extended.

Horizon = Dashboard Structural Logical Architecture

As mentioned in Part 1., the Openstack Cloud can be managed via a command line interface (CLI). This Dashboard makes is a lot easier to facilitate simple queries and changes, but does not support all the ever evolving services served by all the relevant Applications. To get all the functionality, one would need to connect to the CLI manually or REST services using the API programmatically.

Horizon = Dashboard Behavioural Services Architecture

Horizon does not offer or provide any of its own services, it simply consumes all the services from the other applications. Since in latest blogs we will show all Services offered by each application, nothing will be modelled here.

Next

This next blog in the series is OpenStack Cloud Networking in Archimate – Part 3.

Cloud Openstack

OpenStack Cloud in Archimate – Part 1

  • 2017-04-272018-05-08
  • by Charles

Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on Hosting and Cloud software delivery modelled in Archimate.

Introduction

One of the first things that struck me about the OpenStack cloud software was its naming of elements by the Project names they were/are developed under, which makes it a bit harder to learn, because you not only have to learn the name but also mentally map it to the functionality it provides. So one of the reasons for this blog was to model OpenStack, both to help me learn and understand it but also share the models at the same time.

The second thing that struck me was how well it conforms to the Microservices architectural style, with smallish isolated Applications that are independent and have an API to integrate into the broader context.

Thirdly I wanted to build up an Open Architecture Model using Archimate version 3.0, that would help others in Architecting Cloud Solutions. At the end of the ten part series I will publish this model for download.

This information has been pieced together from information available off openstack.org and google searches. This blog has been written around the Openstack Ocata release from Feb 2017. In other words, it could be wrong in places, because of modelling older versions, etc. If you spot items that are simply wrong and thereby misleading, please contact me and I’ll try and fix the model.

OpenStack Core Services

Openstack Cloud has core application collaborations that offer application services defined as:

  • Neutron [Networking] Services
  • Nova [Compute] Services
  • Glance [Image] Services
  • Cinder [Block Storage] Services
  • Swift [Object Storage] Services
  • Keystone [Identity] Services

Not included in the core list of application collaborations, but core if you don’t want to do command line interface (CLI) interaction and configuration of your cloud is:

  • Horizon [Dashboard] – Web GUI for defining and configuring the Core elements

Also – two optional more recent application collaborations as shown in the diagram below

  • Heat [Orchestration] Services – Automates provisioning of Compute, Images, Networks & Storage
  • Ceilometer [Telemetry / Metering] Services – meters the usage of most core components

The diagram below is not in Archimate, but was one of the simplest clearest models I found to explain the concept at a high level.

Openstack Cloud Application Components by Function

There are other optional application collaborations such as Ironic (bare metal service), Fuel (deployment service), Octavia (load balancing service), Trove (database Service), Sahara (Data processing), etc. In fact there are many (+/- 50 odd) optional application collaboration projects.

Core Application Architecture showing behaviour

In Archimate the high level Architectural view would look like the diagram below. Most Openstack core Applications expose behaviour via Application Services through an Application Programming Interface (API) realised by Application Functions, implemented as lower level Application Components and grouped by one Application Collaboration. You will see this coming out in the models in later blogs.

Each Application is built as a project under the project names as described below, and it follows a microservices style architecture. Virtually all Application Functions offer an API that exposes both CLI commands and set of REST based services, so they can be accessed manually as commands or manipulated programmatically for automation. The Dashboard then cleverly uses these same services to offer a User Interface via a Web portal from which to control your cloud configuration.

OpenStack - Core high level Architecture showing interactive Behaviour

We will explore each Application Collaboration shown in the white dotted line packages above. We will explore each applications Logical Structured Architecture and the Behavioural Service Architecture in subsequent blogs.

Next

The next blog in the series is OpenStack Cloud Dashboard in Archimate – Part 2.

Cloud Openstack

Hosting and Cloud Software Delivery modelled in Archimate

  • 2017-04-192018-05-08
  • by Charles

Introduction

I set out to define a set of good simple ready-made Hosting and Cloud models (something like this diagram below) in Archimate 3.0 notation. I decided to model Openstack in Archimate.

IaaS-PaaS-SaaS

Even this diagram above does not really explain the Platform-as-a-Service concept of virtualised O/S components at all, using the concept of Containers as implemented by Docker and Kubernetes for example. Containers give us Scalability, Availability, implement Microservice Architecture, Deploy much quicker, etc. So I started simple and want to evolve the thinking. This is my first attempt and am happy to take comments and observations to improve it and get it stable.

 

On Premises Hosting Model

This is a simple Archimate Model showing the left most Column in the initial diagram above. In this model, the company is responsible for its own IT equipment at all levels. You scale, make resilient and manage.

On Premise Hosting

 

Infrastructure-as-a-Service Hosting Model

This is a simple Archimate Model showing the second from left Column in the initial diagram, being Infrastructure-as-a-Service hosting in both on Premise and in the cloud.  In this model, the company is responsible for its own IT equipment down to and including the operating system on a server (be that virtual or base metal). You scale, make resilient and manage all the items from the O/S upwards. The rest is managed and owned by the vendor.

IaaS-Hosting

 

Platform-as-a-Service Hosting Model (Standard)

This is a simple Archimate Model showing the third from left Column in the initial diagram, being Standard Platform-as-a-Service hosting in both on Premise and in the cloud. In this model, the company is responsible for its own IT Applications and Data. You scale, make resilient and manage only Applications and Data. The rest below that is managed and owned by the vendor. This includes Software Virtualisation as well as Hardware Virtualisation.

This is the Standard method that has been used and evolved for decades, however this does not cater for Containerisation. I have added a simple Containerised version of this in a later section below.

PaaS-Hosting

 

Software-as-a-Service Hosting Model

This is a simple Archimate Model showing the third from right most Column in the initial diagram, being Software-as-a-Service hosting in the cloud. In this model, the company is responsible for none of its IT, with the possible exception of End User Computing. The rest, Server side is managed and owned by the vendor.  The Vendors scales, makes resilient and manages everything including Applications and Data.

Platform-as-a-Service Hosting Model (Containerised)

This is a simple Archimate Model showing the third from left Column in the initial diagram, further extended from the Standard Platform-as-a-Service to Containerised PaaS hosting in both on Premise and in the cloud. In this model, the company is responsible for its own IT Applications and Data. You scale, make resilient and manage only Applications and Data. The rest below that is managed and owned by the vendor. This includes Software Virtualisation as well as Hardware Virtualisation. It is of course made easier to manage, scale and is way more resiliant using the Containerisation concepts.

Containerised-PaaS-Hosting

What this model does not show is any Orchestration of Containers and Pods, but this will be done in a separate blog that shows the concepts of Cloud Microservice designs looking in more depth at OpenStack, then Docker and Kubernetes.

 

Conclusion

The first thing I noticed, is that it is possible to model this stuff relatively easily in Archimate as above.

However I also noticed that because the various Cloud Components that make up a cloud implementation (made more visible by looking at for example the OpenStack Software) mean that there is a bluring of the lines between Infrastructure and Applications. Why do I say this? Because each module of any Cloud Component element is actually made up of a whole set of Microservices that can be described as an Application in its own right, made up of Services, Databases, Queues, etc.

Another thing to notice is that while it is relatively easy to show a static / structural view of these elements, the value and understanding of how the Containerisation works is in the Behaviour and dynamic aspects. Things like creation of Containers pulling from a public cloud registry, Orchestration and Deployment of Pods, Security Tokens, etc. Even Locations become blurred in terms of exactly where shared Object storage resides, etc. More to come.

Next

See Open Stack Cloud modelled in Archimate – part 1

Architecture Maturity Assessments Health checks

Why do Architecture Maturity Assessments regularly?

  • 2017-03-222018-05-08
  • by Charles

What shape is your Architecture practice in?

Do you know what shape your company’s Architecture team are in health-wise? You should test your team against some form of Industry or third-party benchmark. Architecture Maturity Assessments should be like clock-work. Once a year.

These maturity assessments tend to be expensive, time consuming and get in the way of day to day business. So assessments are not done often enough to keep track of progress or regression. So practices muddle on without much realisation about what needs to improve.

What is Architecture maturity?

Based upon the premise that all Architecture Practices have some form of life-cycle. Much like a human goes though from foetus, to baby, to childhood, to adolescence, to adulthood. Starting from very immature ⇒ very mature.
  • Architecture practices start off being non-existent nor recognised as a capability. A few good people fighting the good fight.
  • Then practices become more formal and recognised but still reactive. A team where individuals each do their best to fight the good fight.
  • Then practices become proactive, functional and repeatable. A team which do their best according to their method to align the architecture.
  • Then practices move towards better integration with other structures. With better communication to more stakeholders. A team which do their best according to their method and integrations to other teams to align architecture.
  • Finally they become ubiquitous. They drive out business value outcomes as part of the daily function. A team whose raison d’etre is understood and their methods and business alliances make a massive difference to the efficient and effective business operation.

 

Measuring your Architecture maturity

So how would you like to find out where you stand once a year? In a series of 10 minute surveys by each of your Architects. For Free. And what the next best recommended steps should be, to improve this situation. You’ll also get a Radar chart like this one to show you your assessment for this year. Looks like this model below.

 
It’s always easier coming from a 3rd party than from within, even if you know what to do. Once an area of weakness is identified, there are more detailed health checks to get into detail if required.

Benefits of doing an assessment

  • It’s quick – 10 minutes of each assesee’s time.
  • It’s easy – Minimal questions to cover your entire architecture capability.
  • It’s free – Avoid expensive audits that by the sheer cost only happen once in a blue moon.
  • It’s impartial – Get a 3rd party impartial view of your architecture practice.
  • It’s based on industry standards – BAMM, TOGAF, Gartner, etc.
  • It’s repeatable – Because of the above it’s easy to do once a year and keep a track of progress

 

Want to take it further and do the free assessment?

If you are interested, read up more on this free health-check Architecture Maturity Assessment service.

 

References

  • Measuring business architecture capability maturity
  • Gartner.com – Scoring Enterprise Architecture
  • ErWin – Why Enterprise Architecture Needs Maturity Models
Modelling

Archimate 3.0 introductory basics videos

  • 2017-02-282018-05-08
  • by Charles

These are some of the Opengroups Archimate 3.0 introductory basics videos we thought you might find useful.

ArchiMate® 3.0 (Part 1 The Framework)

 

ArchiMate 3.0 (Part 2 Generic Metamodel)

ArchiMate 3.0 (Part 3 Motivation & Strategy)

ArchiMate 3.0 (Part 4 Physical Elements)

ArchiMate 3.0 (Part 5 Relationships)

ArchiMate 3.0 (Part 6 Improvements & Notation)

ArchiMate 3.0 (Part 7 Viewpoints,Standards & Wrap-up))

Posts navigation

1 2 3 4 5 … 9

Categories

Tags

Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

Recent Posts

  • Announcing Our Train44Ir.org charity 2020-04-24
  • Data Fabric Framework – Archimate 3.0 model 2018-05-10
  • OpenStack Cloud Metering in Archimate – Part 10 2017-04-28
  • OpenStack Cloud Orchestration in Archimate – Part 9 2017-04-28
  • OpenStack Cloud Identity in Archimate – Part 8 2017-04-28
  • OpenStack Cloud Object Storage in Archimate – Part 7 2017-04-28
  • OpenStack Cloud Images in Archimate – Part 6 2017-04-28
  • OpenStack Cloud Block Storage in Archimate – Part 5 2017-04-27
  • OpenStack Cloud Compute in Archimate – Part 4 2017-04-27
  • OpenStack Cloud Networking in Archimate – Part 3 2017-04-27
  • OpenStack Cloud Dashboard in Archimate – Part 2 2017-04-27
  • OpenStack Cloud in Archimate – Part 1 2017-04-27
  • Hosting and Cloud Software Delivery modelled in Archimate 2017-04-19
  • Why do Architecture Maturity Assessments regularly? 2017-03-22
  • Archimate 3.0 introductory basics videos 2017-02-28
  • Example Services and Capabilities with Meta-Model 2014-11-09
  • Why a CV in Archmate? 2014-07-14
  • Charles Edwards Archimate CV 2014-07-10
  • EA Conference 2009 – Agile EA: A Step change is required 2009-06-13
  • Who should own Enterprise Architecture? 2009-03-28

Previous Posts

Our Twitter Feed

My Tweets

Recent Comments

    Translate site

    Tag Cloud

    Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

    Blogs about

    AgileEA Process Blogs Charity Cloud Openstack Enterprise Architecture Health checks Information & Data Modelling Strategy Technical Debt Thoughts Use Cases
    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2023.
    Theme by Colorlib Powered by WordPress
    Agile Enterprise Architecture
    Proudly powered by WordPress Theme: Shapely.
     

    Loading Comments...
     

    You must be logged in to post a comment.