Enterprise Architecture and Outsourcing
VerifiedAdded on 2020/03/28
|29
|3018
|281
AI Summary
This assignment delves into the complexities of enterprise architecture by outlining a 'To-Be' architectural structure using ArchiMate modeling. The focus is on the impact of outsourcing medical claims and payments functions to an administrator, requiring a shift in responsibility and service delivery. The document examines viewpoints from various stakeholders like administrators, CIOs, developers, and outlines the technology layer implementation. Enterprise lifecycle management strategies are also discussed for effective resource utilization and information asset protection.
Contribute Materials
Your contribution can guide someone’s learning journey. Share your
documents today.
Enterprise Architecture Application
Assignment 4
0
Assignment 4
0
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
Abstract
The MediCo enterprise’s case study is studied and analysed. This report is intended to sketch out
the importance of enterprise's architecture and the importance of communication in processing
the processes. It provides detail information about the current and the future expected state of the
enterprise, with the help of a "To-Be" architecture. The intension is to process and deliver the
required outsourcing service. The problem of the enterprise, its approach towards the solution
and the best practices are determined. The importance of Enterprise Lifecycle Management is
also determined. The aim is to provide a clear understanding of the architecture, to the
stakeholders, Chief information officer (CIO), directors, application architects and systems
architects. On the other hand, this report focuses to provide a clear picture of the business
architecture, application architecture and technology architecture. The enterprise involves
medical claims and payments as its functions and processes. The ArchiMate modelling tool is
used for generating the “To-Be” architecture.
The MediCo enterprise’s case study is studied and analysed. This report is intended to sketch out
the importance of enterprise's architecture and the importance of communication in processing
the processes. It provides detail information about the current and the future expected state of the
enterprise, with the help of a "To-Be" architecture. The intension is to process and deliver the
required outsourcing service. The problem of the enterprise, its approach towards the solution
and the best practices are determined. The importance of Enterprise Lifecycle Management is
also determined. The aim is to provide a clear understanding of the architecture, to the
stakeholders, Chief information officer (CIO), directors, application architects and systems
architects. On the other hand, this report focuses to provide a clear picture of the business
architecture, application architecture and technology architecture. The enterprise involves
medical claims and payments as its functions and processes. The ArchiMate modelling tool is
used for generating the “To-Be” architecture.
Table of Contents
Abstract......................................................................................................................................................1
1. Introduction.......................................................................................................................................1
2. As-Is architecture of MediCo........................................................................................................1
2.1 Viewpoints and Discussion per Stakeholder................................................................................2
3.1 Vision..........................................................................................................................................7
3.2 Mission........................................................................................................................................7
3.3 Products and Services................................................................................................................8
3.4 Reason for Transformation.......................................................................................................8
3.5 Principles of the Architecture...................................................................................................8
3.6 Actors..........................................................................................................................................8
3.7 Challenges..................................................................................................................................9
3.8 Approach....................................................................................................................................9
3.9 Deliverable..................................................................................................................................9
3.10 Best Practices or Solutions........................................................................................................9
4. Overview of Stakeholders and their Concerns..............................................................................10
4.1 Needs of the Stakeholders.......................................................................................................10
4.2 Concerns...................................................................................................................................10
5. Viewpoints and Discussion per Stakeholder..................................................................................11
5.1 To-Be Architecture..................................................................................................................12
6. Conclusion........................................................................................................................................21
References................................................................................................................................................22
Abstract......................................................................................................................................................1
1. Introduction.......................................................................................................................................1
2. As-Is architecture of MediCo........................................................................................................1
2.1 Viewpoints and Discussion per Stakeholder................................................................................2
3.1 Vision..........................................................................................................................................7
3.2 Mission........................................................................................................................................7
3.3 Products and Services................................................................................................................8
3.4 Reason for Transformation.......................................................................................................8
3.5 Principles of the Architecture...................................................................................................8
3.6 Actors..........................................................................................................................................8
3.7 Challenges..................................................................................................................................9
3.8 Approach....................................................................................................................................9
3.9 Deliverable..................................................................................................................................9
3.10 Best Practices or Solutions........................................................................................................9
4. Overview of Stakeholders and their Concerns..............................................................................10
4.1 Needs of the Stakeholders.......................................................................................................10
4.2 Concerns...................................................................................................................................10
5. Viewpoints and Discussion per Stakeholder..................................................................................11
5.1 To-Be Architecture..................................................................................................................12
6. Conclusion........................................................................................................................................21
References................................................................................................................................................22
1. Introduction
At present, the business practices are mostly integrated with the IT infrastructure, which
is essential and its demand is increasing day-by-day. The business architecture, application
architecture and technology architecture provides a clear understanding of the processes
followed in the enterprise or an organization. The stakeholders possess a key role in the
enterprise and it is necessary to effectively communicate the enterprise to them. The enterprise
architecture helps in representing the working of the enterprise. The case study of MediCo is
represented in this report. It has decided to outsource the claims and payment function to one of
its Administrative partners. Because, it no more intends to directly manage and handle the
claims, of the medical payments from its members. The enterprise involves medical claims and
payments are the functions and process. At present, it is planning to add additional members to
manage the general relationships with the customers and partners. The addition of outsourcing
includes various decision processes, in the overall process. It also contains certain exceptions
that are handled only by MediCo.
The objectives are listed below:
1) To provide a To-Be architecture from the ArchiMate modelling tool.
2) To provide viewpoints to communicate the To-Be architecture, to the
stakeholders.
3) Demonstrate the understanding of stakeholders and their needs.
4) To provide business architecture, application architecture and technology
architecture.
5) The importance of Enterprise Lifecycle Management will be determined.
2. As-Is architecture of MediCo
The AS-IS structure of the Medico is presented as the PDF document to the
stakeholders, the problem is that it is very technical and hard to understand the document.
The legacy system is maintained by one of the third-party service providers. With the
help of the terminal emulation the all the user log into the system that is physically
located in one data center. The current core function of the Medicos are subdivided into
three main business functions and areas of continuous activity.
1
At present, the business practices are mostly integrated with the IT infrastructure, which
is essential and its demand is increasing day-by-day. The business architecture, application
architecture and technology architecture provides a clear understanding of the processes
followed in the enterprise or an organization. The stakeholders possess a key role in the
enterprise and it is necessary to effectively communicate the enterprise to them. The enterprise
architecture helps in representing the working of the enterprise. The case study of MediCo is
represented in this report. It has decided to outsource the claims and payment function to one of
its Administrative partners. Because, it no more intends to directly manage and handle the
claims, of the medical payments from its members. The enterprise involves medical claims and
payments are the functions and process. At present, it is planning to add additional members to
manage the general relationships with the customers and partners. The addition of outsourcing
includes various decision processes, in the overall process. It also contains certain exceptions
that are handled only by MediCo.
The objectives are listed below:
1) To provide a To-Be architecture from the ArchiMate modelling tool.
2) To provide viewpoints to communicate the To-Be architecture, to the
stakeholders.
3) Demonstrate the understanding of stakeholders and their needs.
4) To provide business architecture, application architecture and technology
architecture.
5) The importance of Enterprise Lifecycle Management will be determined.
2. As-Is architecture of MediCo
The AS-IS structure of the Medico is presented as the PDF document to the
stakeholders, the problem is that it is very technical and hard to understand the document.
The legacy system is maintained by one of the third-party service providers. With the
help of the terminal emulation the all the user log into the system that is physically
located in one data center. The current core function of the Medicos are subdivided into
three main business functions and areas of continuous activity.
1
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Actors:
In the AS-IS structure there are 2 actors
1. Member
The member handle all the functions that is related to the member lifecycle
management
2. Third-party
The third-party handles the functions of the third-party management.
2.1Viewpoints and Discussion per Stakeholder
The viewpoint-oriented method supports to know the issues. The key intension of the
viewpoints is to provide a quick guide to various stakeholders to different parts of the AS-IS
Architecture Diagram. Every views can be presented by using the language and notation suitable
to the knowledge, proficiency, and concerns of the projected leadership. The necessities are
considered as the viewpoints.
As-Is (baseline) architecture diagrams
Level 0: MediCo’s Value Chain
The core business functions are subdivided into three member lifecycle management (MLM),
third-party lifecycle management (TLM) and service provider lifecycle management (SLM) and
particular activities that is to be done are being allotted to each actors. Medical claims and
payments, relationship management and other top-up benefits are under the MLM. Audit control
and contract are under the TLM, insurance management and service level management are
provided by the SLM.
2
In the AS-IS structure there are 2 actors
1. Member
The member handle all the functions that is related to the member lifecycle
management
2. Third-party
The third-party handles the functions of the third-party management.
2.1Viewpoints and Discussion per Stakeholder
The viewpoint-oriented method supports to know the issues. The key intension of the
viewpoints is to provide a quick guide to various stakeholders to different parts of the AS-IS
Architecture Diagram. Every views can be presented by using the language and notation suitable
to the knowledge, proficiency, and concerns of the projected leadership. The necessities are
considered as the viewpoints.
As-Is (baseline) architecture diagrams
Level 0: MediCo’s Value Chain
The core business functions are subdivided into three member lifecycle management (MLM),
third-party lifecycle management (TLM) and service provider lifecycle management (SLM) and
particular activities that is to be done are being allotted to each actors. Medical claims and
payments, relationship management and other top-up benefits are under the MLM. Audit control
and contract are under the TLM, insurance management and service level management are
provided by the SLM.
2
3
Source file is attached here.
Level 1: MediCo’s Member Lifecycle Management
4
Level 1: MediCo’s Member Lifecycle Management
4
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
Source file is attached here.
Level 2 - MediCo’s Claims and Payment
Level 3 - Integrated Baseline Architecture
The member and the third party are the actors in the "As-Is" architecture, member have a
direct business with the medical claim and its inbound and outbound claims.
5
Level 2 - MediCo’s Claims and Payment
Level 3 - Integrated Baseline Architecture
The member and the third party are the actors in the "As-Is" architecture, member have a
direct business with the medical claim and its inbound and outbound claims.
5
Source file is attached here.
Level 3 - Baseline Business Architecture
6
Level 3 - Baseline Business Architecture
6
Source file is attached here.
7
7
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Level 3 - Baseline Application Architecture
Source file is attached here.
8
Source file is attached here.
8
Level 3 - Baseline Technology Architecture
All the user log on to the data center that is located at one point and in the case of disaster
it take 24hrs for data recovery in "As-Is" architecture.
3. “To-Be” Background of MediCo
MediCo is a firm that handles services of various medical schemes. It also contains
variety of scheme packages, plan and benefits. At present, MediCo follows a legacy system, and
it has no outsourcing service. The MediCo Company has taken decisions to outsource the
functions like claiming and payment, to the company's Administrative partners. Thus, the
medical claims and payments are the functions and processes it involves. The administrator,
9
All the user log on to the data center that is located at one point and in the case of disaster
it take 24hrs for data recovery in "As-Is" architecture.
3. “To-Be” Background of MediCo
MediCo is a firm that handles services of various medical schemes. It also contains
variety of scheme packages, plan and benefits. At present, MediCo follows a legacy system, and
it has no outsourcing service. The MediCo Company has taken decisions to outsource the
functions like claiming and payment, to the company's Administrative partners. Thus, the
medical claims and payments are the functions and processes it involves. The administrator,
9
claimant and the third-party are the actors involved in the overall functioning of the enterprise.
The administrator follows a set of instructions related to inbound and outbound claims or
payments.
The data partition takes places, for which the enterprise business, its applications and
technology are transformed and requires a “To-Be” architecture. The implementation of
technology is related to data repartition and redistributing of its datacenter. This is to
accommodate the administrator and the different components of its Information System. The
administrators have no role to play in this. Instead they have a role to play in following a set of
instructions related to inbound and outbound claims or payments.
3.1 Vision
To enhance the enterprise and its working services.
3.2 Mission
The mission of MediCo is related to the stakeholders and the new “To-Be” architecture of
the enterprise.
1) To communicate with and make the stakeholders understand about the “To-Be”
architecture.
2) To communicate with the strategic leadership like the directors of the enterprise.
3) To communicate with the application architects.
4) To communicate with the systems architects.
3.3 Products and Services
Medical claims and payments is the process, where MediCo undergoes the following
functions:
1) Administrator Inbound Claim
2) Scheme Inbound Claim
3) Claim Assessment
4) Claim Reconciliation
3.4 Reason for Transformation
The reasons for transformation of MediCo are listed below:
10
The administrator follows a set of instructions related to inbound and outbound claims or
payments.
The data partition takes places, for which the enterprise business, its applications and
technology are transformed and requires a “To-Be” architecture. The implementation of
technology is related to data repartition and redistributing of its datacenter. This is to
accommodate the administrator and the different components of its Information System. The
administrators have no role to play in this. Instead they have a role to play in following a set of
instructions related to inbound and outbound claims or payments.
3.1 Vision
To enhance the enterprise and its working services.
3.2 Mission
The mission of MediCo is related to the stakeholders and the new “To-Be” architecture of
the enterprise.
1) To communicate with and make the stakeholders understand about the “To-Be”
architecture.
2) To communicate with the strategic leadership like the directors of the enterprise.
3) To communicate with the application architects.
4) To communicate with the systems architects.
3.3 Products and Services
Medical claims and payments is the process, where MediCo undergoes the following
functions:
1) Administrator Inbound Claim
2) Scheme Inbound Claim
3) Claim Assessment
4) Claim Reconciliation
3.4 Reason for Transformation
The reasons for transformation of MediCo are listed below:
10
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
1) To enhance the enterprise’s legacy system.
2) To compensate with the new changes of implementing the outsourcing service.
3) To handle outsourcing service’s related decisions.
3.5 Principles of the Architecture
The principles of the architecture includes the principles to implement the business
architecture, application architecture, information architecture and technology architecture. The
business architecture
The changes in any small or a large enterprise is difficult to recognize, because the
implementation of changes are not that simple. Therefore, such changes can be simplified with
the help of an architecture. Like how the architecture designs a house to meet the owner’s needs,
similarly the enterprise architecture is designed based on the needs of its stakeholders.
3.6 Actors
1) Administrator
Role: The administrator’s role is to receive, check and validate the membership claims,
before assessing the claims.
2) Claimant
Role: The claimant's role is to make payment for the claim.
3) Third-Party
Role: The claims are procured by the third-party.
3.7 Challenges
The challenges include,
i. Data recovery is centralized.
ii. To make instant data recovery.
iii. If both member and the administrator are facing disaster, then recovery must be
within 24 hours.
iv. If either one of them faces the disaster, the problem must be resolved in 30 min.
3.8 Approach
The approaches of the Enterprise are listed below:
11
2) To compensate with the new changes of implementing the outsourcing service.
3) To handle outsourcing service’s related decisions.
3.5 Principles of the Architecture
The principles of the architecture includes the principles to implement the business
architecture, application architecture, information architecture and technology architecture. The
business architecture
The changes in any small or a large enterprise is difficult to recognize, because the
implementation of changes are not that simple. Therefore, such changes can be simplified with
the help of an architecture. Like how the architecture designs a house to meet the owner’s needs,
similarly the enterprise architecture is designed based on the needs of its stakeholders.
3.6 Actors
1) Administrator
Role: The administrator’s role is to receive, check and validate the membership claims,
before assessing the claims.
2) Claimant
Role: The claimant's role is to make payment for the claim.
3) Third-Party
Role: The claims are procured by the third-party.
3.7 Challenges
The challenges include,
i. Data recovery is centralized.
ii. To make instant data recovery.
iii. If both member and the administrator are facing disaster, then recovery must be
within 24 hours.
iv. If either one of them faces the disaster, the problem must be resolved in 30 min.
3.8 Approach
The approaches of the Enterprise are listed below:
11
a) The approach focusses on the business strategy.
b) It is based on an iterative and agile Enterprise Architecture method.
c) Aligns with customer and industry frameworks.
d) It controls the business models and the provided architecture with best practices.
e) It aims on the results that are sustainable with realistic controlling.
3.9 Deliverable
The major deliverables include the following:
1) It defines the roles.
2) Current EA Practice Assessment
3) Charter of the MediCo’s Enterprise Architecture
4) It describes the engagement model.
5) Principles of the architecture.
6) Architecture that shows the future state of the enterprise.
7) It provides the roadmap of the technology, to be implemented in MediCo.
3.10 Best Practices or Solutions
The best practices are:
1) It is a top down approach.
2) Effective communication
3) Strong IT support for the business
4) Skilled staff
5) Enterprise Architecture
6) Swift actions on the failure state.
7) Providing progressive results.
8) Effective training
4. Overview of Stakeholders and their Concerns
The MediCo want its enterprise to be stakeholder-centric. Thus, the enterprise
architecture is built to fulfill this need. The lack of insight is related with the incapability of
taking decisions, and this is the reason that the stakeholder-centric, approach is a better option.
12
b) It is based on an iterative and agile Enterprise Architecture method.
c) Aligns with customer and industry frameworks.
d) It controls the business models and the provided architecture with best practices.
e) It aims on the results that are sustainable with realistic controlling.
3.9 Deliverable
The major deliverables include the following:
1) It defines the roles.
2) Current EA Practice Assessment
3) Charter of the MediCo’s Enterprise Architecture
4) It describes the engagement model.
5) Principles of the architecture.
6) Architecture that shows the future state of the enterprise.
7) It provides the roadmap of the technology, to be implemented in MediCo.
3.10 Best Practices or Solutions
The best practices are:
1) It is a top down approach.
2) Effective communication
3) Strong IT support for the business
4) Skilled staff
5) Enterprise Architecture
6) Swift actions on the failure state.
7) Providing progressive results.
8) Effective training
4. Overview of Stakeholders and their Concerns
The MediCo want its enterprise to be stakeholder-centric. Thus, the enterprise
architecture is built to fulfill this need. The lack of insight is related with the incapability of
taking decisions, and this is the reason that the stakeholder-centric, approach is a better option.
12
4.1 Needs of the Stakeholders
The needs and the concerns the stakeholders are discussed in this section. The enterprises
contains many stakeholders, similarly MediCo has four stakeholders. The stakeholders are:
1) Chief information officer (CIO),
2) Directors,
3) Application architects
4) Systems architects
Each stakeholders have difference of opinions when it comes to implementation of
technology and related application. Thus, their concerns also differ, respectively. The common
concerns include stakeholder’s “Stake”. The possible stakes include:
a) Effective use of the newly developed system.
b) Short-term development of the system, in the enterprise.
c) Long-term technical support.
4.2 Concerns
The concerns are divided for all the stakeholders in the below section.
The CIO’s concerns include:
a) To ensure that the existing system’s compatibility is maintained.
b) Software modification related guidance.
c) Guidance for the evolution of the architecture.
d) He is also concerned about the non-functional requirements like the performance and
reliability.
The directors’ concerns include the following:
1) The directors are concerned about the effective implementation and budget.
2) Then, they are concerned about estimating the schedule.
3) To assess the risks.
4) Progress tracking
5) Feasibility
6) Requirements traceability
13
The needs and the concerns the stakeholders are discussed in this section. The enterprises
contains many stakeholders, similarly MediCo has four stakeholders. The stakeholders are:
1) Chief information officer (CIO),
2) Directors,
3) Application architects
4) Systems architects
Each stakeholders have difference of opinions when it comes to implementation of
technology and related application. Thus, their concerns also differ, respectively. The common
concerns include stakeholder’s “Stake”. The possible stakes include:
a) Effective use of the newly developed system.
b) Short-term development of the system, in the enterprise.
c) Long-term technical support.
4.2 Concerns
The concerns are divided for all the stakeholders in the below section.
The CIO’s concerns include:
a) To ensure that the existing system’s compatibility is maintained.
b) Software modification related guidance.
c) Guidance for the evolution of the architecture.
d) He is also concerned about the non-functional requirements like the performance and
reliability.
The directors’ concerns include the following:
1) The directors are concerned about the effective implementation and budget.
2) Then, they are concerned about estimating the schedule.
3) To assess the risks.
4) Progress tracking
5) Feasibility
6) Requirements traceability
13
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
The concern of the architect includes,
a) They are also concerned about the requirements traceability.
b) Context definition
c) Support of trade-off analysis.
d) Architecture’s completeness
e) Architecture’s consistency
The developer’s concerns include:
i. Enough design details.
ii. Reference to select and assemble the components.
iii. Ensuring to maintain the existing system’s compatibility.
The other concern of the stakeholders is requirements traceability, which is linked with the
architecture. Because, the requirements are taken in the process of developing an architecture,
which requires taking decision. The architecture should represent the satisfaction of meeting the
requirements, from the taken decisions. Therefore, it can be concluded that financial profit is not
the concern of this non-profitable enterprise. Moreover, it is observed that the requirements and
decisions are interlinked.
5. Viewpoints and Discussion per Stakeholder
The viewpoint-oriented method supports to know the issues. The main intension of the
viewpoints is to quickly guide various stakeholders to different parts of the Architecture
Diagram, depending on the articular concerns. Moreover, all the views can be presented using
language and notation appropriate to the knowledge, expertise, and concerns of the intended
leadership. The requirements are considered as the viewpoints. The viewpoints are:
1) Administrator viewpoint
2) Developer Viewpoint
3) CIO Viewpoint
14
a) They are also concerned about the requirements traceability.
b) Context definition
c) Support of trade-off analysis.
d) Architecture’s completeness
e) Architecture’s consistency
The developer’s concerns include:
i. Enough design details.
ii. Reference to select and assemble the components.
iii. Ensuring to maintain the existing system’s compatibility.
The other concern of the stakeholders is requirements traceability, which is linked with the
architecture. Because, the requirements are taken in the process of developing an architecture,
which requires taking decision. The architecture should represent the satisfaction of meeting the
requirements, from the taken decisions. Therefore, it can be concluded that financial profit is not
the concern of this non-profitable enterprise. Moreover, it is observed that the requirements and
decisions are interlinked.
5. Viewpoints and Discussion per Stakeholder
The viewpoint-oriented method supports to know the issues. The main intension of the
viewpoints is to quickly guide various stakeholders to different parts of the Architecture
Diagram, depending on the articular concerns. Moreover, all the views can be presented using
language and notation appropriate to the knowledge, expertise, and concerns of the intended
leadership. The requirements are considered as the viewpoints. The viewpoints are:
1) Administrator viewpoint
2) Developer Viewpoint
3) CIO Viewpoint
14
5.1 To-Be Architecture
The "To-Be" architecture diagram helps to provide a high level overview and decision
support.
The following are the targets of the "To-Be" architecture:
a) It is process oriented.
b) It is delivery oriented.
c) It is rigid.
d) It is flexible.
e) It is realistic.
Level 0: MediCo’s Value Chain
15
The "To-Be" architecture diagram helps to provide a high level overview and decision
support.
The following are the targets of the "To-Be" architecture:
a) It is process oriented.
b) It is delivery oriented.
c) It is rigid.
d) It is flexible.
e) It is realistic.
Level 0: MediCo’s Value Chain
15
Level 1: MediCo’s Administrator Life Cycle Management
16
16
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
Level 2: MediCo’s Claims and Payment
17
17
The following diagram displays the list of functions that are involved in the medical
claim and payments process. The administrator, receives the medical claim from the member and
then checks and validates the claim before the claim can be assessed. All the content of the claim
is evaluated and if the medical claim is correct, then the claim is accepted as inbound claim
which can be assessed for the payment process. However, if the medical claim is incorrect, then
it is rejected. After that, the scheme inbound claim reviews the reason like, why the inbound
claims have been rejected and it need to be rectified. Thus, it returns the record to the
18
claim and payments process. The administrator, receives the medical claim from the member and
then checks and validates the claim before the claim can be assessed. All the content of the claim
is evaluated and if the medical claim is correct, then the claim is accepted as inbound claim
which can be assessed for the payment process. However, if the medical claim is incorrect, then
it is rejected. After that, the scheme inbound claim reviews the reason like, why the inbound
claims have been rejected and it need to be rectified. Thus, it returns the record to the
18
administrator. If the claim is finally rejected, then the rejection notification is produced and the
medical claim is transferred to the exception handling, for the purpose of finalization. The claim
assessment process is to assess the claim and for evaluation. The medical claim has been
approved and readied for the payment. The process of reconcile team is to reconcile and update
the claim. Finally, the claim is approved by the scheme payment tracking, then the claim audit
log is noted and updated. After that, the payment notification is sent to the scheme payment
tracking when the payment process is completed. Finally, the outbound claim is processed and
sends the notification to the claimants and the members. Then, the scheme is notified that, the
outbound claim has been finalized.
19
medical claim is transferred to the exception handling, for the purpose of finalization. The claim
assessment process is to assess the claim and for evaluation. The medical claim has been
approved and readied for the payment. The process of reconcile team is to reconcile and update
the claim. Finally, the claim is approved by the scheme payment tracking, then the claim audit
log is noted and updated. After that, the payment notification is sent to the scheme payment
tracking when the payment process is completed. Finally, the outbound claim is processed and
sends the notification to the claimants and the members. Then, the scheme is notified that, the
outbound claim has been finalized.
19
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Level 3: BUSINESS LAYER
Administrator Viewpoint Diagram
20
Administrator Viewpoint Diagram
20
The administrator provides administrative inbound claim to verify in case of any rejection. It also
has scheme Inbound, for reasoning the rejection case with the exception handling function. The
assessment history and flags are provided for the further notification i.e., sent to the member. All
the reasons for claim, benefit and third-party agreement is handled by the admin representation.
Level 3: APPLICATION LAYER
CIO Viewpoint Diagram
21
has scheme Inbound, for reasoning the rejection case with the exception handling function. The
assessment history and flags are provided for the further notification i.e., sent to the member. All
the reasons for claim, benefit and third-party agreement is handled by the admin representation.
Level 3: APPLICATION LAYER
CIO Viewpoint Diagram
21
Level 3: TECHNOLOGY LAYER
Developer Viewpoint
22
Developer Viewpoint
22
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
Level 3: Baseline Business Architecture
23
23
In ‘To-be’ baseline business architecture given that 3 layers that is business layer, Application
layer and technology layer. These layers are provides because ‘To be’ structure signifies the
variations due to outsourcing of the Medical Claims and Payments functions to the administrator
who is responsible. Since the Member do not directly involved in the business function it is the
function of the Administrator to take all the necessary services for the claim approval. An
administrator claim inbound is provide with all the functions to claim. In Application layer claim
acquisition, reconciliation and payment where service are provided. Her audit management,
benefit management is served. Finally, technology layer is provide with the database server and
application server where they are connected with the help of a network.
24
layer and technology layer. These layers are provides because ‘To be’ structure signifies the
variations due to outsourcing of the Medical Claims and Payments functions to the administrator
who is responsible. Since the Member do not directly involved in the business function it is the
function of the Administrator to take all the necessary services for the claim approval. An
administrator claim inbound is provide with all the functions to claim. In Application layer claim
acquisition, reconciliation and payment where service are provided. Her audit management,
benefit management is served. Finally, technology layer is provide with the database server and
application server where they are connected with the help of a network.
24
Enterprise Lifecycle Management
The enterprise lifecycle management helps in managing the energy and resources that are
included in the collaboration. Enterprise lifecycle management also acts as a controlling process
for protecting the information asset.
6. Conclusion
The enterprise business its applications and technology is understood. The “To-Be”
architecture from the ArchiMate modelling tool is provided. The viewpoints for communicating
the “To-Be” architecture, to stakeholders is provided. The needs of the stakeholders are
determined and presented. Their concerns are listed. The implementation of technology is
discussed.
The problem is understood and the related solution is determined with the help of “To-
Be” architecture. It is determined that communication is a vital factor that can help is easing the
collaboration. It is also observed that there is a demand for effective management of Enterprise’s
lifecycle. The Enterprise Lifecycle Management helps in the integration of all the functions that
are present in the enterprise. It also helps to manage the relationships. The implementation is
related to the data repartition and redistributing its datacenter, for accommodating the
administrator and the different components of its Information System.
25
The enterprise lifecycle management helps in managing the energy and resources that are
included in the collaboration. Enterprise lifecycle management also acts as a controlling process
for protecting the information asset.
6. Conclusion
The enterprise business its applications and technology is understood. The “To-Be”
architecture from the ArchiMate modelling tool is provided. The viewpoints for communicating
the “To-Be” architecture, to stakeholders is provided. The needs of the stakeholders are
determined and presented. Their concerns are listed. The implementation of technology is
discussed.
The problem is understood and the related solution is determined with the help of “To-
Be” architecture. It is determined that communication is a vital factor that can help is easing the
collaboration. It is also observed that there is a demand for effective management of Enterprise’s
lifecycle. The Enterprise Lifecycle Management helps in the integration of all the functions that
are present in the enterprise. It also helps to manage the relationships. The implementation is
related to the data repartition and redistributing its datacenter, for accommodating the
administrator and the different components of its Information System.
25
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
References
Lankhorst, M. (2013). Enterprise Architecture at Work. 3rd ed. Springer Berlin Heidelberg.
Sparxsystems.com. (2017). Views and Viewpoints | Enterprise Architect User Guide. [online]
Available at: https://sparxsystems.com/enterprise_architect_user_guide/13.0/guidebooks/
tech_ea_views_and_viewpoints.html [Accessed 28 Sep. 2017].
26
Lankhorst, M. (2013). Enterprise Architecture at Work. 3rd ed. Springer Berlin Heidelberg.
Sparxsystems.com. (2017). Views and Viewpoints | Enterprise Architect User Guide. [online]
Available at: https://sparxsystems.com/enterprise_architect_user_guide/13.0/guidebooks/
tech_ea_views_and_viewpoints.html [Accessed 28 Sep. 2017].
26
1 out of 29
Related Documents
Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
© 2024 | Zucol Services PVT LTD | All rights reserved.