Frameworx Home

Application Framework (TAM)

Business Process Framework (eTOM)

Business Process Framework Flows

Information Framework (SID)

Business Metrics High Level

All Diagrams

Frameworx Processes

Frameworx Applications

Information Framework ABEs

Frameworx Metrics

Views

10. Integration Infrastructure

Frameworx Domain Integration Infrastructure Domain (1) TAM Application Type API Management (1) TAM Application Type Business Process Management & Workflow (1) TAM Application Type Enterprise Application Integration

10. Integration Infrastructure

Diagram Description

The Applications Map is an integral part of Frameworx. Integrating applications into a cohesive, automated and flexible infrastructure to enable ‘lean’ operations is as important as the application’s functionality itself. This section of the Applications Framework is designed as an overview for companies either building or deploying applications. Key to the success of a highly integrated ‘lean operator’ is that such an approach should enhance, not diminish the business flexibility that the enterprise can achieve.  Previous approaches of tightly coupling applications with specific functional interfaces ( i.e. ‘hard-wired’ integration) are not only expensive to build and maintain such one-one interfaces, they are extremely inflexible because they reflect the needs of the enterprise and its business processes at the time of development. Today, the communications industry is very dynamic and such ‘hard-wired’ approaches badly serve the business.

Ø    It is critical to separate business process control from the individual applications.

Ø    The key is for the individual applications to offer open interfaces that allow for business process control.

TM Forum’s approach to integration is based on 3 key principles:

Ø    the use of a common communications bus and/or other type of mediation technology, such as an API Broker or SOA Gateway,

Ø    the use of business process management (process workflow) composed from business services interfaces (aka SOA services);

Ø    the use of standards-based interfaces between applications and services,  sharing  a common information model.

Clearly the applications described in this document need not adhere to these core principles but unless applications migrate in this direction, the level of process automation achieved will be low, the amount of business flexibility will be low and the level of customer service will be low.

Achieving lean and agile business processes places a very significant reliance on integration between applications that deliver the various work functions of an operator’s main processes. Full flow-through integration of applications at an enterprise level is a very significant task and one that many industry sectors have been trying to perfect over many years. In the communications industry, some degree of application integration has been achieved over the past decade, but this typically has consisted on system-system point integration to achieve a specific, high volume flow-through result. The reality of this approach is that it can work but it is very expensive and very inflexible, requiring programmatic changes every time a minor process change is needed. The enterprise integration applications described in this document seek to provide an effective, generic and flexible approach to such integration where changes can be made by operations people rather than software engineers.

It is critical to the success of any ‘lean operator’ program that integration between  processes, data and applications can be achieved progressively, accommodating both legacy applications as well as new systems sourced from commercial suppliers or built in-house. Some approaches to integration are really only applicable to ‘clean-build situations and for most operators with legacy systems, it is most unlikely that they can deploy anything other than step-by-step progressive integration approach. This progressive approach assumes that an increasing number of steps in a lean operator’s processes will be automated via applications, either by replacement of current manual process steps, replacement of existing applications with one’s offering greater functionality or upgrades to existing systems. Thus the task of providing end-to-end, flexible process automation is essentially one of providing integration between “islands” of automation.

There are 3 primary building blocks to achieving a generic and flexible approach to integration such process and application “islands”.  These are:

A common communications infrastructure between each application. Several leading middleware products are now well established to provide a common communications vehicle. The most common of these is currently enterprise application integration (EAI) bus technology that supports numerous interface types to cater for a variety of legacy operating systems, databases, data formats, standards etc. EAI is concerned foremost with application-to-application exchange of data, not user activity or interaction. A business process management (BPM) environment. BPM is an emerging class of technologies that work hand-in–hand with EAI technology to provide a range of facilities to manage process and information flows between applications. The real value of BPM is the ability to define and execute business processes independent of applications and infrastructure. While EAI and integration capabilities offer an important resource to BPM environments, EAI software alone typically lacks the ability to address the user-facing side of business processes.

Business Services defined interfaces between applications. In Frameworx parlance, these are defined as contract interfaces. Frameworx Business Service define the interfaces to Services made available by the application. The data and metadata in Business Service specifications use information defined in the Information Framework.

Beyond classic EAI/BPM technologies, a specific set of technologies has been proven and thus dramatically raised in its importance since its early days in SOA (Service-oriented Architectures): standards-based APIs (Application Programming Interfaces), and more specifically, Web APIs, are today the preferred integration technology in enterprise architecture because of its intrinsic ability to deliver strategic capabilities and agility to the business.

Even when an organization has already deployed an ESB, and/or using a BPM product to execute workflows, the expectation of a user experience that now widely varies by the user’s needs, preferred devices and context, heavily contributes to the increasing difficulty for enterprise IT to serve the needs of a diverse mix of users, and managing an ever growing portfolio of Service APIs.

API Management technology thus appears as an answer to modern integration requirements, specifically managing the API lifecycle complexity, by enabling a Service APIs Catalogue, supported on a light runtime engine specifically designed for Digital Services APIs, delivered over HTTP, efficiently supporting and delivering Cloud services, multi-channel and multi-platform Web user experiences, and enabling OTT (over-the-top) business models.


This was created from the Frameworx 16.0 Model


Created from the TM Forum Model Frameworx 16.0.0 on 6/13/2016 at 22:07