Actions

Information Engineering (IE)

Revision as of 16:29, 28 December 2018 by User (talk | contribs) (Information Engineering (IE) is a top-down enterprise information systems development approach which forms a part of the strategy for the overall systems architecture.)

Gartner defines Information Engineering (IE) as " a methodology for developing an integrated information system based on the sharing of common data, with emphasis on decision support needs as well as transaction-processing (TP) requirements." It assumes logical data representations are relatively stable, as opposed to the frequently changing processes that use the data. Therefore, the logical data model, which reflects an organization’s rules and policies, should be the basis for systems development.[1]


As a concept, information engineering is intended to unify and combine the different requirements that must be engineered in any complex system or application. This includes requirements for a database (data engineering), for insuring controlled access (security engineering), and for binding all application components into a single system (software engineering). Data engineering focuses on the required information (input and/or output) for a given application, to meet the needs of software engineers (who ‘build’ the system) and users (who utilize the system). Software engineering refers to the organized process of producing a software application, from the original idea to the final deliverable product. Software engineers utilize the data engineering results (information), and apply methodologies in the design and construction of an application. Security engineering refers to the access of information, both by the software engineers and the end user, clearly defining what each individual can do with what information at which times. The key issue is that applications cannot and must not be engineered in a vacuum. Information engineering must span the entire business process, and not be limited to the design and development of an application.


History of Information Engineering[2]
Information engineering has a somewhat chequered history that follows two very distinct threads. It originated in Australia between 1976 and 1980, and appears first in the literature in a series of Six In Depth articles by the same name published by US Computerworld in May - June 1981. Information engineering first provided data analysis and database design techniques that could be used by database administrators (DBAs) and by systems analysts to develop database designs and systems based upon an understanding of the operational processing needs of organizations for the 1980s. Clive Finkelstein is acknowledged as the "Father" of Information Engineering (IE), having developed its concepts from 1976 to 1980 based on original work carried out by him to bridge from strategic business planning to information systems. He wrote the first publication on Information Engineering: a series of six In Depth articles by the same name published by US Computerworld in May - June 1981. He also co-authored with James Martin the influential Savant Institute Report titled: "Information Engineering", published in Nov 1981. The Finkelstein thread evolved from 1976 as the business driven variant of IE. The Martin thread evolved into the data processing-driven (DP) variant of IE. From 1983 till 1986 IE evolved further into a stronger business-driven variant of IE, which was intended to address a rapidly changing business environment. The then technical director, Charles M. Richter, from 1983 to 1987, guided by Clive Finkelstein, played a significant role by revamping the IE methodology as well as helping to design the IE software product (user-data) which helped automate the IE methodology, opening the way to next generation Information Architecture. The Martin thread was database design-driven from the outset and from 1983 was focused on the possibility of automating the development process through the provision of techniques for business description that could be used to populate a data dictionary or encyclopedia that could in turn be used as source material for code generation. The Martin methodology provided a foundation for the CASE (computer-aided software engineering) tool industry. Martin himself had significant stakes in at least four CASE tool vendors - InTech (Excelerator), Higher Order Software, KnowledgeWare, originally Database Design Inc, (Information Engineering Workbench) and James Martin Associates, originally DMW and now Headstrong (the original designers of the Texas Instruments' Information Engineering Facility and the principal developers of the methodology). At the end of the 1980s and early 1990s the Martin thread incorporated rapid application development (RAD) and business process reengineering (BPR) and soon after also entered the object oriented field. Over this same period the Finkelstein thread evolved further into Enterprise Architecture (EA) and his business-driven IE methods evolved into Enterprise Engineering for the rapid delivery of EA. This is described in his books: "Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies". first edition by Clive Finkelstein (2006) in hardcover. The second edition (2011) is in PDF and as an iBook on the Apple iPad and ebook on the Amazon Kindle.


Characteristics of Information Engineering (IE)[3] IE applies structured techniques on an enterprise-wide basis, or to a larger sector of an enterprise, rather than on a project-wide basis.

  • IE progresses in a top-down fashion through the following stages:
    • Enterprise strategic systems planning
    • Enterprise information planning
    • Business Area analysis
    • System Design
    • Construction
    • Cutover
  • As it progresses through these stages, IE builds a steadily evolving repository (encyclopedia) of knowledge about the enterprise, its data models, process models, and system design.
  • IE creates a framework for developing a computerized enterprise.
  • IE then separately developed systems fit into this framework.
  • Within the framework, systems can be built and modified quickly using automated tools.
  • The enterprise-wide approach makes it possible to achieve coordination amongse parately built systems, and facilitates the maximum use of reusable design and reusable code.
  • IE involves end users strongly at each of the stages above.
  • IE facilitates the long-term evolution of systems.
  • IE identifies how computing can best aid the strategic goals of the enterprise.
  • IE utilizes Integrated CASE (I-CASE ) tools to:
    • support the complex data mgt
    • control the analysis and design process through crosschecking/consistency features


Four stages of Information Engineering[4]

  • Stage 1: Information Strategy Planning. Concerned with top management goals and critical success factors. Concerned with how technology can be used to create new opportunities or competitive advantages. A high level overview is created of the enterprise, its functions, data, and information needs.
  • Stage 2: Business Area Analysis. Concerned with what processes are needed to run a selected business area, how these processes interrelate, and what data is needed.
  • Stage 3: System Design. Concerned with how selected processes in the business area are implemented in procedures and how these procedures work. Direct end user involvement is needed in the design of procedures.
  • Stage 4: Construction. Implementation of the procedures using, where practical, code generators, fourth generation languages, and end user tools. Desire is link to construction by means of prototyping.


Information Engineering (IE) is a top-down enterprise information systems development approach which forms a part of the strategy for the overall systems architecture. IE employs data models and process models for each business function or area, to formulate a basic framework of how an enterprise functions and how information technology can help it to function better.[5]


Information Engineering Model (See Figure 1.)[6]
Below is a diagrammatic representation of an Information Engineering Model. In the example, each party is vendor in zero, one, or more purchase orders, each of which initially has zero, one or more line items, but eventually it must have at least one line item. Each line item, in turn, is for either exactly one product or exactly one service.Entities are shown in square-cornered rectangles. An entity’s name is inside its rectangle. Attributes are not shown at all. Mr. Finkelstein shows them in a separate document, the "entity list". Mr. Martin has another modeling technique, called "bubble charts", specifically for modeling attributes, keys, and other attribute characteristics. Names of entities are common terms, and the words in multi-word names are separated by spaces. Relationships are shown as solid lines between pairs of entities, with symbols on each end to show cardinality and optionality. Unique identifiers are not represented in an Information Engineering data model. Sub-types are represented as boxes within their super-type box. (Each occurrence of a sub-type "is a[n]" occurrence of the super-type.) This is shown in the figure. PERSON and ORGANIZATION are sub-types of PARTY. They are portrayed as separate boxes, with a linked with "isa" relationship lines.


An Information Engineering Model
Information Engineering Model
Figure 1. source: Essential Strategies


Information Engineering (IE) Framework[7]
Information engineering is vitally important. On the one hand, the timely and efficient utilization of information must be ensured since this significantly impacts on productivity, will play a major role if industry is to move successfully into the future, can support and promote collaboration as the key to maintaining a competitive advantage, and will allow individuals and companies to use information in new and different ways. On the other hand, the collection, synthesis, analyses of information can lead to: a better understanding of processes, sales, productivity, etc.; and, the dissemination of only relevant and/or significant information, which can effectively reduce the overload of information on end-users. The underlying theme for both of these perspectives and our previous examples is that confidentiality must be insured and misuse must be both prohibited and prevented. Moreover, it should be clear that information engineering must span the entire business process, and not be limited to the design and development of an application.This is most easily quantified via the following list of design level questions. An example using software-development environments (SDEs) is employed to illustrate the utility of each question. ∗ What are different kinds or types of information for an application? ∗ Is the “same” information stored in different ways?: In SDEs, for a given module we might maintain multiple representations for the source code (ascii file), the object code, a parse tree, a symbol table, and a data-flow graph. All of these representations offer different perspectives of a portion of a program that are important and provide different views to different users. ∗ How will the types of information be manipulated to maximize usage? Actions or operations on source code (e.g., edit, compile, etc.) are different than ones for a parse tree (e.g., create node, scan node, get token, etc.). Information engineering requires the definition of specific manipulation techniques for all of the different representations of an application. ∗ What are the information interdependencies? In SDEs, a given source file must be bound to its object code, parse tree, symbol table, and dataflow graph. Moreover, consistency across representations is needed to insure that a change to one representation is realized in all other appropriate representations. ∗ Are there any performance requirements related to the access and/or use of information? SDEs are dynamic, with respect to the constant changes being made to the source code. In order to insure that all other representations (parse tree, symbol table, etc.) are consistent whenever the source is changed. Such an activity is likely computationally intensive, and if so, there would be response-time requirements regarding its completion so that the user interface performance does not suffer. ∗ What are the allowable values for the different types of information? From a programming perspective, allowable values involves typing; from a database perspective, integrity constraints. Both are critical for SDEs. In the latter, constraints might be simple (e.g., object code corresponds to the most recent version of the source) or complex (e.g., changes in the source must be realized in all relevant representations). ∗ Will information persist over time? In SDEs, to support incremental design and development, the different representations must be stored in a long-term repository like a database. In addition, to promote reuse, a software or information engineer (IE) must be able to access “old” software to use in “new” designs/implementations. ∗ Are multiple versions of information available? This question transcends traditional approaches via source code control systems, since it must offer new and different capabilities that can take advantage of longitudinal data that are not simply ascii files. Versions of all information associated with design and development in SDEs must be recorded, thereby allowing the restoration of a project to an earlier (and hopefully, consistent,) time-point. ∗ Who needs access to what information when? In SDEs, there are many different types of IEs (e.g., IEs for project management, design, development, testing, maintenance, or IEs new to a company or project). All of these IEs need different access at different times to the representations that comprise an application in an SDE (e.g., IEs for development need write access to modules, while IEs that are new to a company may only need read access initially). Further, their access might change over time (e.g., once a new IE has improved his/her skills, changes to privileges that yield wider access can be made). ∗ Is some information sensitive? ∗ Must some information be protected? The last two questions are related, since once information has been identified as sensitive (e.g., employee evaluations of IEs by a project manager), it must be protected from access by all unauthorized individuals. Overall, these eleven questions form a solid framework for an initial exploration of the information engineering requirements for an application.


The Phases of Information Engineering (See Figure 2.)[8]

  • Strategic Business Planning: The business directions that senior managers set for the future are defined in strategic business plans, with their greater definition in tactical business plans and implementation in operational business plans. Most organizations acknowledge today a vital need to develop such business plans. But it has often been difficult for these plans, expressed in terms that are relevant to senior management, to provide clear direction also at the tactical and operational levels of organizations. Feedback is needed, so that any problems that occur due to miscommunication and misinterpretation of business plans can be corrected early.
  • Data Modelling: Data models should ideally be based on directions set by management for the future. As discussed, these are defined in business plans. Where business plans are not available or are out-of-date, or the reasons why business processes exist are lost in the dark recesses of history, data models of business information provide clear insight into future needs. Data models can be developed from any statement, whether it is a narrative description of a process, or a statement of a policy, goal, objective or strategy. Redundant data versions that typically have evolved over time in different areas of an organization (each defining its own version of the same data) can be consolidated into integrated data models so that common data can be shared by all areas that need access to it. Regardless of whichever area updates the common data, that updated data is then available to all other areas that are authorized to use it.
  • Process Modelling: A business event is the essential link between a business plan and a business process. It initiates strategies and tactics. In the plan, an event is defined as a narrative statement. Physically, it may be a transaction that invokes a business process. Or it may represent a change of state. The process invoked by each event should be clearly indicated. Without a link to the plan, the business reason(s) why the process exists may not be clear. It may be carried out only because “we have always done it that way”. If the process cannot be seen to support or implement relevant plans at a strategic, tactical or operational level of the business, or provide information needed for decision-making, then it has no reason to remain. To implement these processes without first determining whether they are needed also for the future is an exercise in futility. If the process is essential, then the strategies or tactics implemented by the process must be clearly defined. Associated goals or objectives must be quantified for those strategies and tactics. Relevant policies that define the boundaries of responsibility for the process and its planning statements must be clarified. Missing components of the plan can thus be completed, with clear management direction for the process and hence the business. Process modelling documents processes using a variety of diagrams. These include data flow diagrams, state transition diagrams and object oriented process and class hierarchy diagrams. These documented processes are used to provide input to systems design and systems implementation.
  • Systems Design and Implementation: The Business Model, comprising data models and process models that are developed from business plans, indicate the business needs to be addressed by relevant information systems and data bases. They define the systems requirements from a business perspective, which is one part of systems design. The other part considers available technologies to be used for design and implementation. These technologies may be used for the design of client/server systems using relational data base management systems and object-oriented development tools. Or technologies may be used for design of Data Warehouses, accessed using Executive Information Systems (EIS), Decision Support Systems (DSS), OnLine Analytical Processing (OLAP), Relational OnLine Analytical Processing (ROLAP) and Decision Early Warning Systems (DEWS) based on the information and processing needs indicated by the Business Model.


The Phases of Business-driven Information Engineering
Phases of Business-driven Information Engineering
Figure 2. source: Clive Finkelstein


Information Engineering (IE) Variants and Techniques[9]

IE Variants

  • DP-driven
    • Information Strategy Planning (ISP): develop a plan for implementing business systems to support business needs.
    • Outline Business Area Analysis (OBAA) : answers a range of questions related to implementation of a business area.
    • Detailed Business Area Analysis (DBAA) : provide detailed models as a solid basis for system design.
    • Business System Design : specify all aspects of a system that are relevant to its users, in preparation for the technical design, construction, and installation of one or more closely related databases and systems.
    • Technical Design : prepares an implementation area for construction and installation.
    • Construction : produce a system, as defined in the technical specification, on time and within budget.
    • Transition : the period during which newly developed procedures gradually replace or are interfaced with existing procedures.
  • Business-driven Variant of IE for Rapid Delivery
    • Strategy Analysis : This is a rapid delivery method for senior managers and business unit managers for refinement of existing strategic business plans, or development of new strategic business plans if none exist yet.
    • Strategic Modeling: This uses a facilitated modeling session with senior business managers who review the strategic business plans to develop a strategic model.
    • Tactical and Operational Modeling : This uses the same approach as for strategic modeling, but focuses on tactical business units.
    • Activity Modeling : Activity models, based on IDEF0 and activity-based costing, are used to document priority business activities for rapid delivery.
    • Process Modeling : Business Process Modeling Notation (BPMN) is used, supported by modeling tools, to define process model diagrams in BPMN of priority activities for rapid delivery into production.
    • Code Generation : BPMN process model diagrams are used to generate XML-based code in Business Process Execution Language (BPEL) for execution.

IE Techniques

  • Entity analysis : identifies all the things that the enterprise may want to hold data about.
  • Function analysis and process dependency : takes a function (a major business activity) of the enterprise and breaks it down into elementary business processes.
  • Process logic analysis : describes the sequences of actions carried out by a business process and shows which data are used by each action.
  • Entity type lifecycle analysis : describes the significant business changes to entities and confirm that processes have been modelled to effect these changes
  • Matrix cross-checking : creates cross- references between data objects and processes to verify that they are necessary and complete.
  • Normalization : provides a formal means of confirming the correctness of the entity model.
  • Cluster analysis : helps define the scope of design areas for proposed business systems.
  • Data flow and data analysis : makes a comparison possible between the business area models and the systems currently supporting this area, these current systems are analyzed using data flow and data analysis techniques.


See Also

Enterprise Engineering
Business Process Engineering (BPE)
Information Technology (I.T.)
Information Technology (IT) Transformation
Enterprise Architecture
Enterprise Architecture Framework
Design & Engineering Methodology for Organizations (DEMO)
Information Management (IM)
Information Resource Management (IRM)
Strategic Vision
Enterprise Information Integration (EII)
Enterprise Information Management (EIM)
Enterprise Information Security Architecture (EISA)
Information System (IS)


References

  1. Definition of Information Engineering Gartner
  2. History of Information Engineering Wikipedia
  3. What are the Characteristics of Information Engineering (IE)? [^https://kelasti.files.wordpress.com/2009/04/intro-2-ie-full1.pdf%7CIndra Tobing]
  4. Four stages of Information Engineering James Martin
  5. What is Information Engineering (IE)? Business Dictionary
  6. Information Engineering Model Essential Strategies
  7. Framework for an initial exploration of the information engineering requirements for an application UConn.edu
  8. What are The Phases of Information Engineering Clive Finkelstein
  9. Information Engineering (IE) Variants and Techniques Maria Elloso


Further Reading

  • An Introduction to Information Engineering: From Strategic Planning to Information Systems Clive Finkelstein
  • Information Engineering Methodology: A tool for competitive advantage Ken Richmond
  • Introduction to Information Engineering Stephen Roberts
  • Object-Orientation and Business-Driven Information Engineering The Data Administration Newsletter
  • Information Engineering for the Development of Spatial Information Systems: a Research Agenda Y. Bédard