Introduction
Integration is key to almost all enterprise system development, and” I AM” [Information around Modules] has been replaced with “We ARE” [Wider Enterprise fueled by Abstracted Reusability Entity value chains]. However, enterprise requires an enormous effort to integrate the value chain verticals across the globe. This includes the enterprise semantic models that address the business dynamics and orchestrate business processes. Enterprise architecture framework and enterprise classification framework can play a vital role in differentiating these increasingly blurred technology stack choice and provide a guided roadmap toward convergence in various aspects. This issue demystifies these integration puzzles and discusses how harmony and the enterprise classification framework play a crucial role in the enterprise integration playground.
Enterprise Value Chain
Business agility in the enterprise domain demands a solid grasp of processes and workflows, not only to particular verticals but also it requires a crossover between partners, suppliers and all other enterprise enablers. This new formula capitalises the long leveraged expertise and capabilities of these enterprise enablers in their particular industry segments. This vertical integration is increasingly becoming crucial to the agile enterprise playground in redefining the art of enterprise play.
Figure 1: Enterprise Value Chain Integration
Integration is the critical success factor for agile applications of today’s agility. The most common hurdle in this objective – to provide quality service and better operational efficiency – is integration challenge. Integration includes both the enterprise life cycle and product development life cycle. Today’s enterprises are no longer able to afford the luxury of individual existence in this market place vacuum.
“The difference between supply chain integration and application integration is in their relationship to one another. One is the rail, the other is the train. Application integration, as we've discussed, requires placing new approaches and technologies around the process of extending the reach of applications, enabling them to exchange information with other applications that exist in other organizations. Supply chain integration represents the enabling processes that run on top of the infrastructure that application integration creates” [Next Gen].
Enterprises need to be ready to take on technological innovation opportunities to conquer business problems.
10 Holistic Steps to be INTEGRATED
Enterprise integration is a result of a successful strategic "Enterprise Master Plan". The following 10-step formulae details how you can ensure an enterprise is well integrated. See Figure 2.
Fig. 2: Integration Success Formula
Enterprise Integration Layers
Enterprise applications integration approaches can be classified into the following four general categories:
- Information-oriented
- Business process integration-oriented
- Service-oriented
- Portal-oriented
These approaches may be further categorised as follows:
- Static binding to static Services
- Dynamic Binding to Static Services
- Dynamic Binding to Dynamic Services
Another parameter is:
- Distributed
- Non-Distributed
Table 1 summarises different types of integration approach:
Table 1: Types of Integration Approach
Figure 3 demystifies the above mentioned integration styles:
Fig. 3: Integration Abstraction Layers
This diagrammatic representation shows how organisations can be a holistic part of the enterprise offerings like coarse-grained micro services and also how it can create a macro Business Process by crossing this mystic line. However, organisations should ensure their capabilities and integrate the offerings into classes, components, systems, subsystems, and module levels. These layers of separation are not as easy as it looks, however. This integration effort requires a significant harmonisation between intra-enterprise and the Enterprise Value Chain verticals. This scenario is depicted in Figure 4:
Figure 4: Integration Harmonisation
Enterprise Integration Maturity
The success of an enterprise depends highly on the strategic alignment of business and IT domains, organisational and information system process and infrastructure. The enterprise is a complex adaptive system and the alignments that stretch horizontally, vertically, and across is necessary to cope with the complexities of an enterprise. Assesing the enterprise integration maturity is an important part of the Enterprise Master Paln. These maturity layers are illustrated in Figure 5:
Figure 5: Organisational Maturity Band
Enterprise Views and Integration
GERA identified views help the enterprise visualise the requirements better. Therefore, supporting enterprise views is one of the critical success factors for the enterprise. GERA recommended views are fantastic tools to successfully implement enterprise integration, as described in Figure 6:
Figure 6: GERA Views and Integration Concepts
The CORE of the enterprise architecture includes the way to the enterprise business entities, within the context of how the enterprise Meta-information systems are classified, organised and maintained in an appropriate relationship. Figure 7 explains the decomposition of the enterprise entity into fine grained functional objects. Figure 8 depicts the enterprise SOA layers.
Fig. 7: Enterprise Entity Decomposition
The enterprise entity decomposition is another interesting aspect of the enterprise integration effort. It associates enterprise decomposition with different enterprise viewpoints. Harmony, the enterprise classification framework is created with one of the objectives to classify the layers and organise them into an ontological relationship. Figure 7 and Figure 8 shows how to decompose the enterprise in terms of fine grained modules and layers in order to describe and predict the enterprise functionalities.
Figure 8: Enterprise SOA Layers
SOA: True Lies or Separate Lies
Service Oriented Architecture (SOA) is now becoming the new radical wave that changes enterprise evolution pattern. The enterprise is now going through a major technological innovation breakthrough that has completely changed the enterprise game. However, a closer inspection reveals that extracting the right set of enterprise metadata information out of the Houdini's cage shifts the nature of the current enterprise portfolios from components to on-demand services, data to meta-model, and modules to models. The birth of different technology innovations make the situation more complicated. It also aids in coining new buzzwords and hypes that eventually instigate a new trend of, which I call ‘Chain of accidents,’ generating a new formula ‘Enterprise’ + Buzzword + ‘Architecture’; for example, enterprise SOA, enterprise MDA, enterprise ESB architecture and so on. This ‘Chain of Accidents’ is the result of the inability to develop a cohesive integration vision for the enterprise as a whole.
“SOA is the aggregation of components that satisfy a business need. It comprises components, services, and processes. Components are binaries that have a defined interface (usually only one), and a service is a grouping of components (executable programs) to get the job done. This higher level of application development provides a strategic advantage, facilitating more focus on the business requirement.
SOA isn't a new approach to software design; some of the notions behind SOA have been around for years. Jess Thompson, a research director at Gartner, argues that the underlying concepts date back to the early 1970s, when researchers started drawing boundaries around software and providing access to that software only through well-defined interfaces.
A service is generally implemented as a coarse-grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled (often asynchronous), message-based communication model.” [Source: Messaging Patterns in Service-Oriented Architecture, Part 1]
David S. Linthicum describes SOA as: “First, SOAs are complex, domain-specific architecture, and one technology or approach does not always fit. In many cases, creating an SOA is going to take a heck of a lot of redevelopment, and in other cases, not as much. In some instances, messaging layers (ESBs, really) are the proper technology to apply, for others, there is not as much need for structured information movement.
Second, SOAs are all about agility and not as much about the technology or approach. We build SOAs for one reason; it’s strategic technology that will make your business run better and accommodate change much better than traditional approaches. We do this by creating an infrastructure, somehow, that’s changeable as processes, services, and information changes.
Finally, we should consider the notion of an SOA as static, and technology and approach as dynamic. Let’s face it, the technology that we apply changes all the time. We should encapsulate those dynamics in their own domain and not get too wrapped around the axel about the latest and greatest, or manage our architecture by magazine articles and conferences” Source: ESB versus Fabric…Stop It!.
Enterprise Service Bus: What Journey does it Start?
ESB is an open standards-based distributed synchronous or asynchronous messaging middleware that provides secure interoperability between enterprise applications via XML, Web services interfaces and standardised rules-based routing of documents.
ESB is an extension of EAI that provides better information transformation, portability, scalability and failover capability. There are enterprise politics, which effectively sell the ESB as a complete different wine in a new bottle. However, “when I hear "ESBs are better than EAI" I get very confused because I defined the concept of ESBs in the EAI book, as what it is, an enabling technology for EAI. EAI is a larger notion, where ESBs are a mere instance of technology. It's almost like saying "Automobiles are better than the concept of transportation." Source: ESB vs. EAI?"…Give me a Break.
Enterprise Integration and Harmonisation
If you consider an enterprise from a macro-level point of view, the functional decomposition of macro organisations result in the formation of coarse-grained components known as business processes or services or subsystems. As a coarse-grained component represents a higher level of abstraction, they are less complex and less coupled. Coarse-grained components aim to deliver discrete and complete business capabilities.
In general, most of the organisation (generally B2C type, where C is the direct end-user), which are not a part of B2B collaboration, do not need service-based integration within the organizations, and therefore components, system and subsystem based modules are used to digitize the participant departments or system. Nowadays, there is a tendency to use the term SOA for consulting business propaganda only or to implement SOA without understanding the organisation. We try to convince our customers to implement SOA or SOA-based integration, which is mostly service driven integration. However, we should be very careful in these cases from an architectural point of view and should properly investigate the opportunity of starting integration of different types of components, systems and subsystems in a simple enterprise rrchitecture integration (EAI) fashion. Appropriate assessment is recommended in all cases.
On the other hand, in case of B2B type organisations (which are generally part of an enterprise) offer services to other businesses. Since this requires more automation, it uses a Business Process based infrastructure. Such a situation requires proper type of integration technologies starting with simple EAI. There are two different aspects of software services companies. One type of service providers brands their services with such lucrative jargons like SOA and BP Integrators to get the benefits of better business opportunities. The other types of companies are technology lovers and better practitioners of the art of software technologies. So they always try to justify the type of technologies to be used on a case-by-case scenario. Therefore, we should be very cautious about the level of modularisation granularity required compared to that proposed by the service provider consulting companies.
Service Identification
Service Identification is one of the primary requirements in order to perform a successful enterprise value chain integration process. In fact, there are different levels of services are present within the enterprise layers as depicted in Figure 9.
Fig. 9: Service Identification
Enterprise should get the appropriate guidance from the chosen enterprise architecture framework to successfully identify the appropriate services in order to achieve the enterprise integration. In this respect harmony, the enterprise classification framework provides you the right roadmap that leads your enterprise to the “Kingdom of Heaven”.
Enterprise Integration Cycle
Enterprise Integration is best achieved through the five phases as shown in Table 2:
Therefore, a proper SWOT analysis enables the better requirement capturing process that facilitates a better integration plan:
Figure 10: SWOT Analysis and Integration Opportunities
Harmony, the Enterprise Classification Framework could be successfully used here in order to provide the best SWOT analysis.
Figure 11: Enterprise Integration Cycle and the Harmony Classification Framework
Enterprise Architecture Frameworks and Enterprise Integration
It is a true that technology innovation should be an integral part of the enterprise architecture framework. Unfortunately, this is not the case for almost all the available frameworks, helping one type of opportunistic group to gain a significant amount of currency. Lack of Object Oriented principles use mostly hinders getting benefited from the recommended specialisation and extension types of inheritance, to provide better support the reusability and modularisation. This ‘Spaghetti’ practice of enterprise business on the other hand promoted incorrect specification, construction, and limitation type inheritance.
Figure 12: Integration Approaches and Contribution of Architecture
Figure 13: Object Orientated Conceptualisation within Enterprise Domain
Unfortunately, absolute reuse of enterprise services and models are still distant goal. The reasons for this failure are primarily due to the inability of lack of convergence support by enterprise architectures. When a new business need arises, organisations need to review their enterprise master plan to fit the requirement within the enterprise architecture and transform these requirements into technology specification through a selection of right technological stack. In order to achieve this convergence, enterprise architecture framework should be capable of transforming the requirements into right set of integration path and identifies the way of harmonisation to handle the diversified software solutions stack that relates to the appropriate integration solution of the identified business-level requirements.
Harmony, the Enterprise Classification Framework: “La Sagrada Familia”
The harmony classification framework defines the long awaited requirements of an ultimate success path as a foundation upon which enterprise value chains will be able to be easily integrated. Harmony is an enterprise classification framework that develops the E=MC2 powered enterprise. This unique harmony classification framework effectively classifies, organises and relates the enterprise entities that enable a smooth enterprise integration implementation using enterprise architecture framework.
Figure 14: How to be INTEGRATED with Harmony Classification Framework
Harmony paves the enterprise integration roadmap in the fastest speed.
References
[GERAM] GERAM: Generalised Enterprise Reference Architecture and Methodology. Version 1.6.3 ( http://www.cit.gu.edu.au/~bernus/taskforce/geram ) also in P.Bernus, L.Nemes and G. Schmidt (Eds) Handbook on Enterprise Architecture, Berlin : Springer (2003) pp 22-64
Handbook on Enterprise Architecture, by Bernus, P., Nemes, L. and G. Schmidt (eds.) , Springer, (2003), ISBN is 3540003436
[Next Gen] Next Generation Application Integration: From Simple Information to Web Services by David S. Linthicum, Published By Addison Wesley Professional, ISBN-10: 0-201-84456-7
Enterprise Application Integration by David S. Linthicum, Published By Addison-Wesley Professional, ISBN: 0201615835
Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap By Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah, Published By IBM Press, ISBN: 0131870025
|
