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

Business Services & Capability Model

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.

Application Services Model

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.

ICT Services Model

 

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.

Meta-Model

 

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.

Other Views Model

Thoughts

Exploring Services and Requirements – Part 3

  • 2008-07-252018-05-08
  • by Charles

Abstract

Exploring Services and Requirements – Part 3

A series of three papers exploring the tie up between gathering requirements for a Services world and how this overlaps with the Enterprise Architecture world. They were also published and commented on the www.requirementsnetwork.com (RQNG) website in 2008.

Download

Exploring Services and Requirements Part 3 – v0.06.pdf

Thoughts

Exploring Services and Requirements – Part 2

  • 2008-07-252018-05-08
  • by Charles

Abstract

Exploring Services and Requirements – Part 2

A series of three papers exploring the tie up between gathering requirements for a Services world and how this overlaps with the Enterprise Architecture world. They were also published and commented on the www.requirementsnetwork.com (RQNG) website in 2008.

Download

Exploring Services and Requirements Part 2 – v0.09

Thoughts

Exploring Services and Requirements – Part 1

  • 2008-07-162018-05-08
  • by Charles

Abstract

Exploring Services and Requirements – Part 1

A series of three papers exploring the tie up between gathering requirements for a Services world and how this overlaps with the Enterprise Architecture world. They were also published and commented on the www.requirementsnetwork.com (RQNG) website in 2008.

Download

Exploring Services and Requirements Part 1 – v0.09

Modelling

Modeling Services and Capabilities (2009 thinking)

  • 2009-04-282018-05-03
  • by Charles

One view of the Enterprise Architecture is the Services View, where you can look at the whole enterprise from the Business capabilities, expressed as Services (or Capabilities – where conceptual and not yet implemented), through Logical Design Services, through Implemented Services, right down into the Physical implementation elements such as software infrastructure Services (like unix FTP components, Browsers, Middleware, etc.) and Hardware Services (Servers, Routers, Printers, etc.).

See example diagram below for a simple idea of these (using Archimate Notation):

Modelling Services And Capabilities

I therefore believe that showing all the Services used in the Enterprise is possible at the right level of granularity. Services are more than just Web Services or the middle layer of this diagram “IS Application SOA implemented services”.

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

    Our Twitter Feed

    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2021.
    Theme by Colorlib Powered by WordPress
     

    Loading Comments...
     

    You must be logged in to post a comment.