What is Information Development System?
Information System Development can be defined as “a process wherein a set of changes take place in a particular process with respect to object systems in a set of environments by a development group using tools and an organized collection of techniques collectively referred to as a method to achieve or maintain some objectives.” (Smith, G. F., & Browne, G. J. (1993)
In Information System Development is supposed to include the development of both the manual as well as the computerized parts of an object system and hence includes both manual and computerized parts.
The most important part of the complete development of the system is the tool and the technique being used for it. So, it is important to be clear about these two terms.
A technique is basically a set of rules which describe how an Information System is developed and used using related conceptual structures and notations. Systems developers use these techniques to define and communicate on various aspects of existing and future object systems. These aspects are defined by the conceptual structure of the technique and represented by the related notation.
A tool, on the other hand, is a computer based application which is used for the application of a modelling technique. Any modelling functionality that is supported by a tool is known to abstract the object system into models which in turn helps a developer to check that the models are consistent and are effectively converting results from one form of the model to another form. It also provides specifications and functionalities for review.
A method is defined as a predefined and pre organized collection of rules which explain the steps required to be taken to implement a set of techniques. A method always includes both the product and process aspects.
Examples of methods include Structured Analysis and Design (, and the object-oriented methods of Booch (1991) and (Mayer, R. J., et al. (1987).
What is Information System Integration?
With decreasing differences between various inter and intra verticals in any business, it is very difficult to fragment each of these in terms of application systems.
For example, as value chain enterprises expand beyond borders, supplier and customer systems become part of each other’s information architectures.
Also, in many application areas, data is used by a host of verticals and hence it is distributed over a multitude of heterogeneous and generally autonomous information systems. Exchange and sharing of data between these systems is very difficult, more so if the data base is very large.
Generally, each organizational unit is divided into 3 architectural layers:
- Business Architecture: This layer defines the organisational structure and the workflows for business rules and processes. It is a conceptual level defined in a way that is easily understandable by the users of the applications.
- Application Architecture: This layer defines the implementation of business concepts in terms of enterprise applications. This layer acts as the binding interface between the application domain as defined by the business architecture and the technical solutions provided by the technology architecture.
- Technology Architecture: As the name suggests, this layer is used to define the information and communication system or infrastructure. The whole process of how to achieve the output using Information Technology is designed at this level.
Different application integration:
- Enterprise Application Integration: Here we try to integrate independent enterprise resource planning systems at this layer. This can be done using various techniques like SAP/R3 approach wherein the integration is done using a single database having no boundaries between different enterprise units. However, messaging services are required for integrating autonomous ERP systems, both within and across the enterprises.
The deployment of ERP systems usually needs re-framing the business processes to align them with the ERP system although it is generally unacceptable to require the business to change to the applications’ functionality. Instead the information architecture should align with the business organization. System Integration aims at supporting the business processes along with stabilizing and retaining the investments in systems.
Use of Business Modelling in System Integration:
Development of a Systems Information System (SIS) is a complex process which includes solving not only the technological problems associated with the SIS architecture and its components, but also the organizational related to the SIS application domain. In the enterprise context, the application domain of an SIS can be seen as the business system or target that is supported by the SIS (Silver, G. A., & Silver, M. L. (1989).
Authors, such as Avison & Fitzgerald, Flynn and Kruchten, emphasize the importance of
modelling the business before eliciting its requirements. A business model is a representation that captures the structure and dynamics of the target organization in which the SIS is to be deployed. We refer to the target organization as the SIS application domain. A business model can help SIS developers to gain a more comprehensive understanding of the SIS application domain, its information problems, and the functional requirements that the SIS must satisfy.
Business modelling is a very important and critical part of various different processes like Business Process Reengineering, Organizational change, Enterprise Modelling & Integration, Business Process Management, Enterprise Application Integration, ERP System Configuration, E-Commerce, Software Development and Information System Planning and Development.
Areas like Information Systems and Software Development (IS/SD), where business
modelling is recognized as a necessary activity, few methods are available that explicitly cater to the critically important organizational dimension of the IS/SD process models.
Some of the methods found in the literature that include explicitly the business modelling as an activity of their IS/SD process models are the following: RUP, Business Engineering, Watch, MERISE , EKD, Mainstream Objects , Information Engineering , Business Modelling with UML, and Enterprise Modelling with UML (Zachman, J. (1987).
These methods describe, in one way or another, the activities, artefacts and workflows that are needed to model a business. Typical business concepts that are modelled, by these methods, are the following: goals, business processes, actors, business rules, job structure, business objects, and events. The way these concepts are modelled varies from one method to the other.
There is a new model that has been proposed recently, called the BMM model. This method represents the main concepts of a business system and their relationships, including the technologies that are applied by the business system. The method can be used as a previous stage of the requirements engineering process to help SIS development teams to get deeper understanding of SIS application domains.
Conceptual modelling scheme is a kind of data modelling system. Data models are used to provide the format and characteristics of the data to support data and computer systems. If this is done consistently across systems then compatibility of data can be achieved.The scheme is described as below:
Conceptual schema: It describes the semantics of a domain which can also be the scope of the model. For example, it may be a model of the interest area of an organization or industry. This includes entity classes that represent significant attributes in the domain, and relationships assertions about associations between pairs of entity classes. A conceptual schema specifies the kinds of facts or propositions that can be described and executed using the model (Olle, T. W., et al. 1988). Hence it can be said that it defines the useful expressions in a system with a scope that is limited by the scope of the model.
Different types of Conceptual structures:
Generic data models:
This is a generalization of conventional data models. They are used to define standardized general relation types along with the related attributes. By standardization or generalization of an exhaustive list of relation types, a generic data model enables the expression of a large number of different kinds of data types (Pressman, R. S. (1987). Conventional data models, on the other hand, have a fixed and limited domain scope.
Fig: Generic data modelling architecture
Semantic data modelling:
This model is used to derive an inter relationship within different kinds of data within a same framework or a system. It is used to serve various functions like:
- planning of data resources
- building of shareable databases
- evaluation of vendor software
- integration of existing databases
The semantic model makes use of the abstraction techniques for these purposes. These techniques are generally related to the field of Artificial Intelligence. The semantic model also acts as a fundamental step in any data ware house related development process and is very useful in understanding the requirements of the system. Similarly, it is also very useful in designing the subsequent data models. Also, it acts as a link or a join up between the tool interface and the physical data models. (Smith, G. F., & Browne, G. J. 1993).
The semantic model might not be very popular in terms of logical or physical data handling ways, but the most important attribute that makes it relatively attractive is the fact that it always gives paramount importance to the users’ perspective. (Coleman, S. (1992).
Fig: Semantic data modelling
Also Read Indian Banking System Assignment
Various modelling methodologies:
- Bottom-up model: These start with an existing model, with existing data structures or texts. These models are generally physical and specific to the application that they have been designed for. Usually, sharing of data is very difficult in these models because they do not refer to other verticals of the organization.
- Top-down model: This is merely a reference for the actual model that has to be created. Generally a lot of data is collected and then the actual model is designed on the basis of the type of data that has been collected. It is possible that the model does not incorporate all the entities and aspects of the logical model in it.
It must be noted that there are times when a model is developed using a mixture of both the methods, as in taking in various attributes of both the models.
- Mayer, R. J., et al. (1987). Knowledge-based integrated information systems development methodologies plan (Vol. 2), (DTIC-A195851).
- Smith, G. F., & Browne, G. J. (1993). Conceptual Foundations of Design Problem Solving. IEEE Transactions on Systems, Man, and Cybernatics, 23(5).
- Zachman, J. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276-292.
- Silver, G. A., & Silver, M. L. (1989). Systems Analysis and Design. Reading, MA: Addison-Wesley.
- Pressman, R. S. (1987). Software Engineering: A Practitioner’s Approach. New York: McGraw-Hill, 1987.
- Olle, T. W., et al. (1988). Information Systems Methodologies: AFramework for Understanding. Reading, MA: Addison-Wesley Publishing Company.