Introduction
Today information systems are no more synonymous to the enterprise systems. The enterprise is now more of a demand-supply chain relationship between suppliers, partners, and customers. The enterprise systems are also now ready to realise the benefits of MDA. This week’s discussion will help you to understand how the enterprise is passing through a paradigm shift that will help us to classify enterprise systems most effectively.
Modular Enterprise
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 organization. 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 Architecture Integration (EAI) fashion. Appropriate assessment is recommended in all cases.
On the other hand, in case of B2B type organizations (which are generally part of an enterprise) offers 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 brand their services with such lucrative jargons like SOA and BP Integrators to get the benefits of better business opportunities. The other type 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. The overall enterprise modularisation could be depicted as illustrated in Figure 1.

Figure 1: Modular Enterprise: How the Enterprise Game is Evolving
This diagram shows how a small organisation is really separated from the whole Enterprise by a single mystic line. It also shows how organisations can be a holistic part of enterprise offerings like coarse-grained micro services to the enterprise system and 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.
Modularisation Rationale
Modularisation and collaboration-oriented communication between the macro and micro level modules enable the realisation of a service that is otherwise difficult to achieve. Today’s enterprise successfully implements modularisation to achieve the following prime benefits:
- Abstraction from implementation details
- Encapsulation of internal functionalities
- Greater reusability
- Easy maintainability
- Interface minimisation
- Low coupling
The process of modularisation matures through an evolutionary approach based on enterprise requirements. The Enterprise Master Plan is very much essential in this respect.
Today we deliver business services as a software system that automates one or more business capabilities and bridges the gap between people and technology. However, underneath these services, several components, systems and subsystems are the foundation fluids of the enterprise anatomy.
Modularisation Benefits
Business is driven by economy. So, apart from technology interests, modularisation involves economical implications. One powerful idea sustaining the interest in modularisation is that enterprise software could be developed in parallel, which prevents lengthy iterations and results in savings in the IT budget of the organisation. This modularisation concept promotes the idea of ‘buy in’. This is why package modules such as ERP, CRM are doing good business, and how organisation assets move towards supplier assets. Modularisation is probably another reason why ISVs are doing well. Modularisation is another driving force behind offshore development and the outsourcing concept. This revolutionary concept of Aspect Enterprise Architecture Integration Oriented Programming (AOP) and concern oriented development further boost the move towards modularisation. Modularisation is now passing through a new horizon of cross cutting concern oriented development and model-driven architecture, to open up ample opportunities in software modeling, architecting and software testing.
Paradigm Shift
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. See Figure 2.

Figure 2: Enterprise Paradigm Shift. Inspired and Adapted from [Systems Thinking].
The enterprise working mechanism has now shifted from a simple information system to a demand-supply chain service provider model as shown in Figure 3.

Figure 3: Enterprise Demand-supply Chain Model
Therefore, enterprise needs to be architected in a completely different way on the basis of the correct type of classification knowledge. The enterprise dynamics has raised two important questions, as shown in Figure 4.

Figure 4: Enterprise Dynamics: Reestablishes the importance of Enterprise Classification Framework
Question 1: How to reduce the time to respond? Question 2: How to increase the time to think?
These two questions actually lead us to the most effective path of successful Enterprise Architecture (EA) implementation. The agility of the enterprise is directly related to the time-to-respond which is effectively utilised by a proper classification of the enterprise.
Model Driven Collaborative Enterprise Architecture (MDCEA)
MDA has introduced the concept of CIM and PIM that has produced platform- and technology-neutral models. These models are highly reusable enterprise assets. Moreover, MDA encourages interoperable modeling. For a better understanding of MDA in terms of impacting the enterprise modeling, it is recommended you read Weaving the Ultimate Enterprise Architecture with Aspect Oriented Design. MDA encourages Enterprise Collaboration Architecture (ECA) which emphasised platform/technology independent modeling and simplifies the development of component-based EDOC systems by means of a modeling framework. ECA is another promising technology implementation initiative, which is an MDA initiative, from the Object Management Group (OMG). ECA consists of the following elements:
- The Component Collaboration Architecture (CCA), with UML profiles, describes how classes, collaborations and activity graphs can be used to model, at different levels of granularity
- The Entity profile, with the help of a set of UML extension, describes model entity objects that represent application problem domains
- The Event profile, with the help of a set of UML extension, describes model of event driven systems
- The Business Process profile, a specialization of the CCA (with the help of a set of UML extension) describes model workflow-style business processes in the context of the components and entities that model the business
Therefore, ECA provides a platform / technology independent, loosely coupled enterprise architecture that is leveraged by re-usable business components collaboration. This B2B / B2C components based enterprise could be called as Model Driven Collaborative Enterprise Architecture (MDCEA).
Conceptual Revolution Versus Technology Innovation
The difference between conceptual revolution and technology innovation is often unclear. In an Enterprise System the development stage enterprise should be classified to incorporate the conceptual considerations that will eventually help to derive agile enterprise architecture. OMG’s MDA is one of the most revolutionary concepts to derive a Model Driven Enterprise Architecture, which is easy to reuse and takes less time to market. On the other hand, SOA and ESB are the two most profound technology innovations to implement a successful integration implementation of the derived Enterprise Architecture.
Enterprise Classification Framework: How does that help?
An Enterprise Classification Framework is the foundation stone to build any successful enterprise architecture. It helps to populate most of the meta information about the enterprise architecture rapidly and effectively. It therefore acts as the input criteria for any EA Framework-based EA implementation. The Enterprise Classification Framework therefore should be able to provide direction about:
- Seven Life Cycle Aspect of EA Reference Framework: Entity Identification, Entity Concept, Entity Requirement, Entity Design, Entity Implementation, Entity Operations and Entity Decommissioning
- Enterprise Architectural Concepts: Human Oriented Concepts, Technology Oriented Concepts, Entity Life Cycle Concepts, Entity Life History Aspects, Entity Types, Modeling, Enterprise Modules and Enterprise Operational concepts
Conclusion
This issue dealt with the nature of the enterprise paradigm shift that explains the importance of enterprise classification framework in terms of classifying the enterprise nature and positioning the same within this game. In the next issue, I will detail the EA framework and classification framework success criteria. I will also explain the nature of the Zachman Framework, its strength and weakness, and also discuss the most effective classification framework to build a successful modeldriven enterprise system.
References
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
Systems Thinking: Managing Chaos and Complexity: A Platform for Designing Business Architecture by Jamshid Gharajedaghi “, Published By Butterworth-Heinemann (May 10, 1999) ISBN: 0750671637
Weaving the Ultimate Enterprise Architecture with Aspect Oriented Design
Enterprise Entity
Enterprise Reference Architecture Framework
MDA Specification
Enterprise Collaboration Architecture (ECA) Specification
Model-Driven Architecture: Vision, Standards And Emerging Technologies Position Paper Submitted to ECOOP 2001 for Workshop on Metamodeling and Adaptive Object by John D. Poole, Hyperion Solutions Corporation, April 2001
Concepts for Modelling Enterprise Architectures by Henk Jonkers, Marc Lankhorst, René van Buuren, Stijn Hoppenbrouwers, Marcello Bonsangue, Leendert van der Torre where Telematica Institute, University of Nijmegen, Nijmegen, the Netherlands, Leiden Institute for Advanced Computer Science, Leiden, the Netherlands, CWI, Amsterdam, the Netherlands
|