As with the broad industry trend across rapid application
development scenarios, microservices and single page applications are abundant
across the healthcare administration and analytics business purposes. The
promise of microservices is the separation of concern among business purposes
with deep isolations when necessary, including the data stores. They are also
independently testable and provide a medium for continuous deliverables to
stakeholders. The promise of single page applications is the simplicity of
describing modular components within the web pages and for reusability across
workflows. Together they empower a variety of scenarios that require the spectrum
of compute intensive to data intensive capabilities.
We leave the infrastructure provisioning and the associated operational
services such as logging, registry and monitoring out of this discussion and focus
instead on the development of applications and api services. Although the
choice of infrastructure and the development of the application are not
completely divested of one another and must have mutual considerations, it suffices
to say that the business capability versus application development boundary is
customer facing while the infrastructure provisioning and application
development boundary is backend facing.
Among the several aspects of application development,
dedicated data services such as catalog or inventory can be separated from the
rest of the capabilities such as claim analytics, cob rules and commercial
lines of business. The api services by virtue of their number often suffer from
consistency and framework that the infrastructure demands and are developed in
house by those business divisions. They also become bloated as division tend to
take on solutions to common problems that do not necessarily deal streamline
with the business capabilities.
The same can be said about the components in the single page
applications. Many applications rediscover the same browsing, filtering, and editing
capabilities that do not necessarily pertain to a line of business. This leads
both the applications to develop a common repository for reusable modules that
become more of a limitation rather than a facilitator of consistency and
capability. If there are attributes left out of the common definitions and the
derived instance cannot add them, they can no longer use the common definitions
and must write one from scratch.
The single page applications essentially display tabular
data. They are not data entry intensive or require complex long running
calculations. This makes the entire user workflows have short duration but more
interactive. Some of the workflows are read-only operations often requiring checking
on status or model predictions that run independently. These imply that the analytical
queries and logic are also saved external to the applications and sometimes
external to the API. Grouping of queries is also dedicated to the business
purpose and often require little or no grouping. This leads to a different set
of requirements on the analytics and reporting side than on the application and
processing side.
Finally, the applications require modernization as much as
the legacy platforms do. For example, the dominant statistical platform is SAS
and this is now universally replaced by Python and R packages.
#codingexercise
public static
int[] canonballsIterative(int[] A, int[] B) {
for (int j = 0; j < B.length; j++) {
int h = B[j];
for (int i = 0; i < A.length;
i++) {
if (A[i] >= h ) {
if (i == 0) { break; }
if (i > 0) {
A[i-1] += 1;
System.out.println("h=" + h + " i=" + i + " A:
" + printArray(A));
break;
}
}
}
}
return A;
}
No comments:
Post a Comment