The Administrative Systems Modernization Program (ASMP 2.0) is tasked with replacing UT Austin’s current mainframe with a new Service-Oriented Architecture (SOA). In a SOA model, programs and applications, called services, interact over a distributed network. This is in contrast to traditional IT systems, which use a monolithic or silo architecture.
The goal of SOAs is to promote modular programming, code reuse, and object-oriented software development efforts to create distributed computing systems which align systems activities with business process activities. By creating a system in which a client using any device, operating system, or programming language can access services, SOA overcomes common challenges including application integration, transaction management, varying security policies, and the difficulty of allowing newer devices and protocols to access legacy systems. Seen as building blocks, services can be reordered, enhanced, and combined to support changing business processes.
SOA models rely on a highly distributable communications and integrations backbone. In the University’s case, this is provided by the use of an Enterprise Service Bus (ESB) provided by MuleSoft. The ESB is an application-agnostic platform that delivers calls between heterogeneous applications. ESBs replace previous middleware products to act as both a transporter and transformer of messages – data are transformed irrespective of their formats. Services connected to an ESB can be upgraded, moved, or replaced without modifying or disrupting other applications. ESBs allow systems that do not directly support service interactions, such as legacy systems and packaged applications, to communicate.
While MuleSoft’s ESB will be the primary method of implementing SOA on campus, other systems, such as the message broker RabbitMQ, will also transport data and integrate systems. The common denominator in our SOA system is an API registry, which is a catalog for services, endpoints where services can be invoked, and details of invocation (availability, security, etc.).
Other services are being identified by the Technical Architecture (Tech Arch) team to handle aspects of the SOA system including:
|Validation and authorization||User portal||Version control|
|Load balancing||Binary repository||Virtual machines|
|Storage||Database hosting||Data collection and analytics|
Developers and SOA
Developers and designers using a SOA approach are able to work with programs and applications without knowledge of their locality or remoteness; the programs’ interconnect scheme, transport protocol or data format for invocations; nor which components are needed to establish connections. Unlike mainframe systems, SOA systems allow for a distributed network to talk without need for the end user to translate.
Developers, IT users and service consumers must consider several aspects when reengineering systems to implement SOA: legacy services have different vintages, use different technologies, and have different value to the College, School or Unit (CSU). Technical users should consider:
- Should applications be wrapped in SOA interfaces without internal change?
- Do certain applications need to be migrated and decomposed as services?
- Which applications require integration and migration?
- What is the reuse potential of these applications?
- What are the strategic, architectural, technical, and cost-benefit considerations in making these decisions?
There are some common concerns that users contemplating new system adoption face which are relevant to SOA implementations. In research studies of application adoption, cloud security is a primary concern for users (89%), as well as the desire to have close to a 100% uptime (90.4%), data privacy (87.6%), and integration requirements (79.4%).
For our chosen ESB, security concerns have been addressed by rigorous ISO and IAM checks; the MuleSoft ESB offers a secure method of integrating with on premise applications using a secure tunnel. Applications built on the ESB currently implement using service account authorization and will use OAuth (open standard for authorization) in the future; authorization patterns are currently under review. In addition, an ESB is not an application that stores data, it is a tool that transports encrypted data. Uptime is mitigated through an analysis of the service along with its infrastructure and all underpinning services. The University is designing its SOA implementation around redundant components and best practices to optimize uptime; the University also requires SLAs (Service Level Agreements) from each of its vendors, which are being posted within the University’s online service catalog. MuleSoft ESB has high security certifications, and it’s underpinning cloud offering has an uptime SLA of 99.99%. MuleSoft ESB offers visibility into flows and other services while also providing multi-tenant isolation to end-users for data security and integrity.
Additional concerns include access mechanisms, shared network and infrastructure, and compliance to federal, state and local laws such as HIPAA and FERPA. Cloud data security, data privacy, and compliance to laws such as HIPAA and FERPA are mitigated through the University’s assessment process and later audits by ISO and IAM.
The same study discovered that 76% of respondents with cloud computing experience perceived that cloud technology is easy to use and integrate, and that SOA systems were more useful than legacy systems. The degree of difficulty for first-time programming and integration of SOA applications is comparable to writing for other APIs. In the mainframe world, when developers changed any component of their system, many other components would need to be modified. In the decoupled SOA, the use of middleware products takes the burden of constant adjustment off developers, and allows for greatly enhanced discovery and reuse of existing resources.
Overall, studies have found that even when users experience the challenges of system integration and the complexity of migrating legacy applications, they continue to implement SOA systems and see benefits for doing so.
The majority of SOA implementations were judged by their users to be successful (68.4%), and identified benefits such as improved organizational ability (63%), reuse of applications (58%), legacy application integration (54%), standardized data representation (54%), and improved business processes (53%).
The same study discovered that complexity of SOA technology, organizational size and vendor support for SOA does not present a barrier to SOA use. Factors that do impact SOA use and success are the use of multiple standards and platforms, top management support, good governance, adequate resources, and vendor support for integration and development tools. In a federated SOA like the one being implemented at the University, governance is especially important. The Tech Arch team has compiled documentation of processes that will make adoption easier for developers, which includes best practices, standards, and guidelines for production. Lastly, a Customer Steering Committee will be formed to help guide and prioritize our SOA efforts.
Note: A service is a set of architectural features that provide value to the UT Administrative community. The Open Group offers the following definition of service:
“A service is: a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, and consolidate drilling reports); is self-contained; may be composed of other services; is a ‘black box’ to consumers of the service.”
The term Service by ASMP 2.0 indicates specific features that will fulfil a function for the UT community (for example, the service “Document Management” is fulfilled in part by the product “DocuSign,” or “eSignature”).
Part 2 of this post discusses how SOA implementation will affect campus.