Relevant topics on Enterprise Architecture, Agile EA, Modelling, Archimate

OpenStack Cloud in Archimate – Part 1

2017-04-272018-05-08
by Charles

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

See Open Stack Cloud modelled in Archimate – part 1

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

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.

Why do Architecture Maturity Assessments regularly?

What shape is your Architecture practice in?

What is Architecture maturity?

Measuring your Architecture maturity

Benefits of doing an assessment

Want to take it further and do the free assessment?

References

Archimate 3.0 introductory basics videos

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))

OpenStack Cloud Dashboard in Archimate – Part 2

Previous

Horizon = Dashboard Functionality

Horizon = Dashboard Structural Logical Architecture

Horizon = Dashboard Behavioural Services Architecture

Next

OpenStack Cloud in Archimate – Part 1

Previous

Introduction

OpenStack Core Services

Core Application Architecture showing behaviour

Next

Hosting and Cloud Software Delivery modelled in Archimate

Introduction

On Premises Hosting Model

Infrastructure-as-a-Service Hosting Model

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

Software-as-a-Service Hosting Model

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

Conclusion

Next

Why do Architecture Maturity Assessments regularly?

What shape is your Architecture practice in?

What is Architecture maturity?

Measuring your Architecture maturity

Benefits of doing an assessment

Want to take it further and do the free assessment?

References

Archimate 3.0 introductory basics videos

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))