How to best represent PaaS such as AWS?

[Robert Campbell]

Here is my first stab at designing how we will build out AWS platform and apps deployed.  Suggestions please.

Maybe I don't need to represent the data center as a business application and I can show the application service as a that instance of the AWS platform however, the data center is not actually an instance of the PaaS that is AWS, it's merely a datacenter on that platform. There are other things that can go wrong above the data center that could cause a problem. Since it is PaaS, how important is it to identify that in the CMDB?

I wasn't sure if this should go under CMDB or CSDM section.

[Mathew Hillyard · Accepted solution]

Hi @Robert Campbell 

This is definitely the correct forum as you're looking at both the design and manage technical services domains.

Datacenters are a CI Class in the CMDB, so would not be represented as a Business Application, not least because Business Applications are the "design" object, not the operational, so it would not normally include location information (such as us-east-1).

The design domain in CSDM, and more specifically the Business Application table contain reference to and categorisation of the application technology that underpins one or more Business Capabilities. 

AWS is a platform that has a lot of different use cases and technologies that run on it. At the most basic level you can create a Business Application for the platform, setting the Architecture type to "Platform Host", and then a Business Application for each of the distinct apps that run on AWS, and set their Architecture type to "Platform Application" and the Platform Host to the AWS Business Applications. However, this is quite one-dimensional and limited, as typical AWS implementations are quite large and complex.

This link on NowCreate gives an extensive set of example deployed CSDM services for different technologies (albeit not with any AWS examples) and could help you decide how to structure AWS in your organisation: CSDM Data Model Examples (NowCreate).

APIs are now recommended to be handled via the Digital Integration Management application that is a part of Enterprise Architecture - much better than large volumes of Depends on::Used by Application Service relationships.

I hope this helps!

Mat

[Robert Campbell]

I agree with your assessment and I do have the data center in the data center class. The problem that we are trying to solve for is communicating in a way that everyone would understand the hierarchy. Also, I likely misspoke when I identified that top business application as a data center. It is actually more of a landing zone (which is also a class) but they want to show that this landing zone "consumes/hosts" all of these applications. 

The problem is all things are viewed in a upstream/downstream view. Upstream we need to have the main thing and everything that supports that thing is somewhere downstream and that main thing is the thing we're deploying so it is representative of the business application. So, we are deploying a landing zone so it is an application service (because of how we have things set up). That application service requires a business application for it to be created so a landing zone business application was created. But we have an AWS PaaS business application and we can't have a business application which doesn't have a business application or application service so that's why I designed it that way. The us-east-1 business application is the landing zone that was created for the release.