- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-05-2025 05:37 AM
When should a business application record first be established? For internally developed applications, should it be established as soon as there is a plan to build, when development has started, or when it's actually deployed? For commercial applications, should it be when RFP is started, when contract is signed, or when system goes live?
Creating records earlier could result in applications in the inventory that are never actually delivered, but is there still value in that? Does anyone create business application records for software that has been requested and rejected, just to maintain a standardization status of "Non-Standard".
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a week ago
Hi Darin,
You asked this a while ago so I hope you found a path that met your requirements in the interim. In case you haven't, I'll throw my 2 cents into the ring here.
Firstly, not to be too much the consultant, but the answers to your questions depend on what aligns with your processes, desired future state, and ability to sustain. Any decision you make here should align with the CSDM, but outside of that there is not a 'right' way, rather there is a 'right for you'. For example, it may be good practice to create a Business App record when it is initially requested and would be in a life cycle of Ideation > Under Evaluation, if you have no situation in which this record would be used in your internal processes it may not be needed. So, keep that in mind as you are deciding on what to do.
In general, I recommend you use the CSDM Life Cycles and a request/task/approval flow that creates the required records at the correct stages of the flow, creates tasks for groups to complete onboarding work, and uses approvals to ensure process is followed. For example, in a Generic App request, once the Request is approved for review, then a Business App could be created in Ideation > Under Evaluation. Groups involved in the evaluation receive a task to do that work (Security, EA, Procurement, etc). If the tasks are complete then the Arch Review Board can approve a Pilot (App record goes to Ideation > Pilot), or approve an implementation (App goes to Build > Chartered, Design...). Keep in mind that if at any point you are deploying an instance you should create the appropriate Service Instance (CSDM 5) / App Service (CSDM 4) and relate it to the Business App. So on and so forth until the BA is Operational > In Use. Ask yourself what stages of the life cycle you would actually use and then let them guide you to align your workflow automation and process with the Business App Life Cycle.
A specific comment on internally developed applications - I recommend you also look in to SDLC components. SDLC leverages Agile for the development, testing, and deployment of SW. These components relate to the Business App and Service Instance records and depending on whether you are developing additional functionality to an existing BA, or creating a new application, the Life Cycle of the Business App would reflect that appropriately.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a week ago
Hi Darin,
You asked this a while ago so I hope you found a path that met your requirements in the interim. In case you haven't, I'll throw my 2 cents into the ring here.
Firstly, not to be too much the consultant, but the answers to your questions depend on what aligns with your processes, desired future state, and ability to sustain. Any decision you make here should align with the CSDM, but outside of that there is not a 'right' way, rather there is a 'right for you'. For example, it may be good practice to create a Business App record when it is initially requested and would be in a life cycle of Ideation > Under Evaluation, if you have no situation in which this record would be used in your internal processes it may not be needed. So, keep that in mind as you are deciding on what to do.
In general, I recommend you use the CSDM Life Cycles and a request/task/approval flow that creates the required records at the correct stages of the flow, creates tasks for groups to complete onboarding work, and uses approvals to ensure process is followed. For example, in a Generic App request, once the Request is approved for review, then a Business App could be created in Ideation > Under Evaluation. Groups involved in the evaluation receive a task to do that work (Security, EA, Procurement, etc). If the tasks are complete then the Arch Review Board can approve a Pilot (App record goes to Ideation > Pilot), or approve an implementation (App goes to Build > Chartered, Design...). Keep in mind that if at any point you are deploying an instance you should create the appropriate Service Instance (CSDM 5) / App Service (CSDM 4) and relate it to the Business App. So on and so forth until the BA is Operational > In Use. Ask yourself what stages of the life cycle you would actually use and then let them guide you to align your workflow automation and process with the Business App Life Cycle.
A specific comment on internally developed applications - I recommend you also look in to SDLC components. SDLC leverages Agile for the development, testing, and deployment of SW. These components relate to the Business App and Service Instance records and depending on whether you are developing additional functionality to an existing BA, or creating a new application, the Life Cycle of the Business App would reflect that appropriately.