Please report any problems to wiki-admin(a)lists.wisc.edu or use our support form. For more info Shared Tools KB
Skip to end of metadata
Go to start of metadata

Advanced Integration Architecture (AIA) Enterprise Service.

The goal of the AIA Enterprise Service is to provide the needed infrastructure to support SOA integration and orchestration capabilities.  These capabilities include: publishing service endpoints (REST, Web Services, Publish/Subscribe), managing the security of those endpoints, a repository for discovery of endpoints and schema management, orchestration capabilities (workflow including human, application and business-to-business), governance and audit/monitoring.

 

Current Status:

The AIA Enterprise Service is currently being developed.  There is an AIA Test Lab initiative underway.  A variety of campus partners are testing two SOA suites to learn more about the capabilities and to help guide the deployment of the AIA service itself.  See the AIA Test Lab space for more information.   To see how these initiatives relate, see the AIA EDM Roadmap in the Related Documents to the right.

We are currently developing a 5 year operational budget and plan.  The goal is to begin deployment of these capabilities in early FY13-14.  The plan includes a phased approach to developing and delivering the enterprise service.  

Core Concepts:

The AIA Enterprise Service is constructed of several capabilities.  These concepts are organized into the major groupings shown below.  See the CORAModel and the SOA Test Lab Business Case Graphics for detailed explanations.

Core Infrastructure:  The Core Infrastructure allows for the publication, management, discovery and governance of a variety of types of endpoints.  The common technical elements of the core infrastructure are: an Enterprise Service Bus (ESB), a Service Registry, Message Oriented Middleware, Security and Governance Middleware and Auditing, Monitoring and Logging Middleware.   These technical elements provide the capabilities needed to publish an endpoint, its schema, manage the security of the endpoint, approve/deny/revoke access to the endpoint and monitor the endpoint's usage.  Think of it like UPS's intake, sorting, distribution and delivery capabilities allow for packages to be delivered but it doesn't create and ship the packages themselves.

Endpoints:  Endpoints include traditional Web Services (XML and SOAP based API calls), REST services, Message Oriented services (Publish and Subscribe topics or queues, event driven messaging) being the most common endpoints.  Endpoints can expose data (like Course Rosters or Account Balances) and/or business services (like Enroll In A Section or Deduct Funds).  The endpoints are published and managed in coordination with the data and business service stewards (e.g the Registrar's Office for Curricular Web Services).  To follow on the UPS metaphor above, if the core infrastructure is the UPS deliver system, the endpoints are shops that create the content, box and mark for delivery the packages carried by UPS.

Consumers:  Consumers are either applications or people who request access then leverage the endpoints that are exposed and managed through the Core Infrastructure.  Usually, consumers are other business applications that need the data or services for their business functions.  These business applications can be internal to UW-Madison or external.  When they are external, the term business-to-bussines (B2B) is often applied.

Orchestration Infrastructure:  The Orchestration Infrastructure allows for business processes to be automated, managed and controlled.  It is the basis of enterprise workflow.  These workflows can include human interactions (e.g. review and routing based on approval or denial), application-to-application interactions (e.g. when system A publishes a change, transform it and push it to system B for further action) and business-2-business interactions.  The orchestrated process (workflow) is managed through configuration of the infrastructure rather than through custom code.  Business Process Execution Language is the most common standard in this sphere.

Service Center or Center of Excellence:  The management of the complete suite of capabilities listed above requires a diverse group of business and technical experts.  These range from: Infrastructure Managers (those who manage the Core Infrastructure and Orchestration Infrastructure applications themselves), Endpoint developers and managers, Orchestration and Composition Developers (those who work on the business process definition and create and manage the workflows), Data Experts, Business Analysts, Training and Outreach coordinators and Project/Portfolio Managers.   These people are not in a single organizational unit but they must come together into a "Service Center" or "Center of Excellence" structure that allows for the efficient and effective operation of the service.

Governance:  The final piece of that completes the service delivery is Governance. Governance covers the data definitions, security requirements determination, approval for access processes and prioritization processes for the infrastructure as a whole.  Governance needs to work with consumers and endpoint owners to determine the correct data definition and appropriate source(s) for new endpoints.  Governance needs approve, deny or reroute requests for access assuring the use is appropriate and that the correct endpoint(s) are being used for the business case.  Governance also plays a role in setting priorities for new endpoints and/or service expansion.

Principles:

  1. The service is core to the strategic goals of the enterprise.  As such, it should be focused on: fiscal efficiency, business effectiveness and designing for agility.
  2. As an enterprise service, enterprise-class requirements must be met where feasible (redundancy, fail-over/fail-safe, change management, security and risk reduction et al).
  3. The services should drive towards a common definition and understanding of the data and services to be effective and avoid errors and misunderstandings.
  4. Data and services should come from the "best" source where possible (i.e. we should reduce redundant services and migrate away from improper and redundant sources).
  5. We should be able to easily determine who is using the endpoints and for what purpose (e.g. we should have business case driven requests and we should be able to track those requests over time).
  6. We should have a single point for consumers to access when they want to request access to one or more endpoints regardless of the source.  The approval process may be different but the starting point should be consistent.

 

About: AIA Enterprise Service is co-sponsed by Chris Holsman (DoIT, EIS) and David Pagenkopf (DoIT, ADI).  Jim Phelps (DoIT, Architecture) is the Enterprise Architect for this effort.  For more information about the service, please contact them.

Recently Updated

  • No labels