Should a BA be modelled to support a TMS/TMO?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
hi @Aron84
You can search taxonomies on filter navigator and open your portal form and under child topics you can add the category.
Happy to help!
To help others in the community find this solution, kindly mark this response as the Correct Answer and Helpful.
Warm Regards,
Deepak Sharma
Community Rising Star 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Aron84 - Below are my answers in line assuming instance is on Zurich release
- I require a Business Application describing the architectural design. - Agree.
UD: Business App to Digital Product is just a label change. "Account Factory" is an investment under Ideation&Strategy domain a defined architectural blueprint. A Digital Product record is the "source of truth" for the software's lifecycle, GRC aspects, regardless of whether the "customer" is an external client or an internal. In your case internal DevOps team.
- I require one Technical Management Service like "Managed Public Cloud Hosting". - Agree
UD: Yes- one step forward - Azure L/XL would be your TMO.
- Each Azure account consumed by a team requires its own Service Instance (application service)... - Disagree.
UD: That creates maintenance overhead (200+) & CMDB sprawl . Instead, I would use Dynamic CI Group(s) & map it against the offering.
"Hope that helps, if it does, please accept the solution and mark it as useful"
BR, UD
