Platform Modelling - Should a BA be modelled to support a TMS/TMO?

[Aron84]

I need some help to verify if my assumptions are correct as different sources are making different claims, especially regarding business applications.

At my company we have a team that manages Azure accounts for the business. They have several offerings depending on region and certain size limitations in the accounts. If one of our devops teams want to build one ore more applications in an Azure account, they get an account from this team. In my assumption this leads to a Technical Management Service along the lines of "Managed Public Cloud Hosting" and at least two offerings "Azure L" and "Azure XL".

Now comes my problem. All these accounts have some shared networking infrastructure and centrally managed control policies. Next to that, the team managing all these account has automated everything. "Asking" for an account results in a call to an account factory API that automates the entire account setup. This all is underpinned by a architectural design.

The above makes me believe that a business application is required for this although the application itself does not directly deliver value to the business. My assumption in this is strengthened looking at the CSDM 5 draft which unlike the CDSM 5 whitepaper renames business applications into digital products. This makes me believe that this will be the state the CSDM is working towards.

Besides the above mentioned I am also in doubt whether these Technical Management Offerings should contain service instances (application service) with the Azure account as a CI on which the service instance runs, or if it should be a dynamic CI-group containing the Azure accounts. 

Would I be correct that:

- I require a Business Application describing the architectural design.

- I require one Technical Management Service like "Managed Public Cloud Hosting".

- Each Azure account consumed by a team requires its own Service Instance (application service) with the actual Azure account as a CI connected using a runs-on relationship. And each of these service instances has a uses relationship with the Business Application (which could result in 200+ service instances).

[Fabian Kunzke]

Hey,

Starting with the short answer: You are correct (mostly).

Now the long answer:

First, the CSDM V5.0 draft did indeed rename BAs to digital products (which i super-like). The actual V5 does not do that (which i dislike). Your example is the actual case on why digital product would be a better name, as what the team does deliver from an architectural design perspective is indeed a digital product. With that in mind, having it as a Business Application record, would be a reasonable alternative (as it is the same thing, but with a different name now).

Scondly, the techncial management service being needed is also correct. With the different offerings in mind (although, you may not need all of them, as some seem to be just straight up catalog items). With offerings, try to be as specific as possible, but don't confuse it with actual catalog items. In this case your azure team would offer multiple templates (catalog items) for teams to request.

Your last assumption is where i'd like to challenge your thought process a bit. Having all accounts be reflected as service instances is certainly reasonable, however it would only make a difference, if nothing runs on them. The teams using the azure accounts should have something which runs on them (their service instance). The azure account would therefore "just" be a representation of the infrastructure behind the teams specific service instance.

Which brings us back full circle to an idea you mention - and the one i actually prefer: dynamic CI groups. Using dynamic CI groups to group together all azure accounts supported by your cloud hosting team, then adding the relationship to the technology offering supporting these accounts makes the most sense to me. Further, this also gets rid of your business application, as per definition, dynamic CI groups are a horizontal slice of infrastructure and don't have a link to a business application record (after all, windows servers don't have on either). [NOTE: this is for debate, having a business application relationship may still make sense to track organizational ownership across all azure accounts]

What you'd end up with is a quite straight forward setup:

Every service instance which runs on azure would have a relationship to their specific azure account (infrastructure CI). All azure accounts are grouped into a dynamic CI group, supported by the technology offering of the "Managed Public Cloud Hosting" technology management service. This is also where the ownership on an operational level is tracked.

No BA needed.

Now this assumes, that you catalog management is well done. Because here you'd absolutely have a product where teams can order Azure infrastructure based on a templated solution. However, the question of having the relationship to such a Business Application for all the operational Azure Account CIs is only reasonable to answer with yes, if the organizational data maintained in the BA record (usually finances & ownership) is indeed independent from the operational ownership (Technology Management Service). If it isn't, then you are just maintaining the same data twice.

Hope this helps.
Fabian