archimate Archives - Page 3 of 4 - Agile Enterprise Architecture

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

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

Modelling

Example Services and Capabilities with Meta-Model

2014-11-092018-05-08
by Charles

Introduction

This blog on Services and Capabilities came out of thinking about a few related subjects:

1. How to use Archimate to model Capabilities as this is not directly supported in Archimate terminology.

2. On how Services relate to Capabilities. These seems to be a lot of discussion about this on the EA forums.

3. How all of the above should all be modeled in an Enterprise Architecture Model using any tool that supports Archimate.

4. How Architects who model hierarchical nested diagrams of one type (e.g. Application services) can see how this would still be possible.

So I thought the best way of explaining how I believe it should be modeled was to model one example situation in each domain for the following:

1. The Business domain – Business Service & capability – Route Planning example

2. The Application Domain – Application Service & capability – that supports Route Planning example

3. The ICT Domain – ICT Service & capability – the Database service that supports the above two.

Enterprise Service Model

So below is the Enterprise Service Model. It shows the typical structure of a whole Enterprise Services model. The services on this diagram (shown in green) give you one Business Service, one Application Service and one ICT Service; one service from each domain. On it I have only shown what has been modeled in the separate Models / diagrams in the sections below as well as any ‘used by’ services or ‘related’ showing service dependencies.

Route Planning – Business Service & Capability Example

This model below is the Business Service and related Capability to support the ‘Route Planning’. Route planning comes from the notion of a travel agency establishing tailored itineraries for prospective customers. As you can see the Capability is shown as a ‘Business Interaction’ and is a collection of Roles, Actors, Processes, Artefacts, Locations and events, that all make up the Capability. The Business Service also depends in a large part on some Application Services.

Route Planning – Application Service & Capability Example

The Route Planning Application Service is shown here in more detail. It shows the Application Services with it various Application Interfaces (some System/Machine and some Human). It then shows the Application Capability, again using an Application Interaction as the wrapper for all items that make up the capability, such as locations, Application Collaborations and Application Components. Each of these elements relies on ICT Services such as servers, desktops and other technology.

Database Server (for Route Planning DB) service – ICT Service & Capability Example

This is one Service of many that support the Application Service and its Capability elements. Again following the pattern of a Service having an Infrastructure interface and saying what should be done not how it should be done. The Capability expands on the detail of how it is realised. This is where I felt there should possibly be the same notion of an Infrastructure Interaction entity but Archimate does not seem to support that. This model also shows how the layers above it interact with the ICT Service, e.g. that the DB SQL Server (software) service relies on a DB Server (O/S & hardware) service.

Meta-Model that brings it all together

While not wanting to re-invent the Archimate Meta-Model, I wanted to show the groups, and inter-relationship that this would build up in an EA Model of the organisation if we were using a tool to support this. The top part is the Portfolio and Programme office controlling the work-packages to do a transformation. They would need to understand the As-is and various Tranches of work per gap to get to a To-Be state. This they would primarily do of the higher level services, but could also go down to more detailed Capabilities to see the deltas between the various as-is and to-be plateaus.

Other Model Views

It seems to me that many EA initiatives love to show the breakdown hierarchically of one Architecture building block type, e.g. Principles, or Organisational Business units, Services, etc. in isolation. I wanted to show by doing the above that all this information would be gathered in any case by working to build up these models. They would just be a by-product of gathering the above information.

The real value is to be derived from the interconnections and relationships in the meta-model of all of these elements below, including the entity instances themselves so that we always know what our inventory of them is so as not to forget things in doing analysis. The impact and dependency analysis is only obtained by connecting up the relationships between entities, provided it is done at a course grained enough level and we don’t try and model the whole world in great detail.

Modelling

Why a CV in Archmate?

2014-07-142018-05-08
by Charles

Background

The thought process was that since I am an Architect selling myself to other Architects, if I was to demonstrate some of the capabilities I am trying to sell the prospective clients out there, then why not use the very technique I would use in doing Enterprise Architecture to do the CV? An Archimate CV. After all the target market are the business and technical people in the business who require these very models. Also since the role is Architect, then an Architecture model describing what Architecture had been done before would be a good sample of my work.

Agreed, one has to get past the Agents and HR people in the process of reaching the end client representatives, some of whom would probably think I had sent in the incorrect document in instead of my CV, but I thought I would send them both versions of the CV in any case, the textual version and the modeled version to get around that small challenge.

Challenge to other Enterprise Architects

I also thought it was unique and different too, because many of the Architects I know wouldn’t even be able to / nor interested in modeling in Archimate, so I saw it as a bit of a challenge to other Architects too.

CV

This is a work in progress and will continually be re-factored over the next while.

The CV can be seen here.

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

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

Example Services and Capabilities with Meta-Model

Introduction

Enterprise Service Model

Route Planning – Business Service & Capability Example

Route Planning – Application Service & Capability Example

Database Server (for Route Planning DB) service – ICT Service & Capability Example

Meta-Model that brings it all together

Other Model Views

Why a CV in Archmate?

Background

Challenge to other Enterprise Architects

CV