GRADE Ideology

What's Wrong with IT and Business Process Re-engineering?

Why do 50% of Large Software and Re-engineering Projects Fail?

The primary problem with developing complex IT based systems is the difficulty in coming up with a specification or blueprint of what should be developed. The root cause of nearly every failed software project is a lack of clear understanding and common interpretation of what the software should do.

INFOLOGISTIK believes that developing blueprints or engineering drawings, as practiced in the mature engineering disciplines, also applies to software engineering and to business process re-engineering. Fads and poorly conceived approaches have stood in the way of a paradigm shift.

Large and Small Systems Are Not One and the Same

In general, small systems can be built effectively without a blueprint; large systems, which require a large team and have different stakeholders, cannot.

Just as no one would dream of building a skyscraper without a blueprint, no one should undertake a major system implementation or business process change without one. A blueprint serves to:

Communicate concepts and solutions among stakeholders of different backgrounds (owners, managers, users, IT professionals),
Recognize/reflect complex interdependencies and see/illustrate the global impact of a local optimization, as well as local impact of a global optimization,
Visually recognize/reflect incomplete or inconsistent parts of a specification.

How to Improve the Conventional Way

When a new software application or technology, such as e-commerce, is introduced, it impacts its environment -- the organizations that use it. Therefore, the software application should be conceived and modeled as an integral part of the enterprise.

The conventional way of developing a software application or introducing e-commerce to support vague, often conflicting ideas about the "to be" business processes often leads to poor software. Much faster and better results can be achieved if the "to be" business processes are firmed up first and the software application is designed to support them. This also applies to implementation of standard ERP software systems, taking into consideration what support could be provided by IT (customization makes different scenarios possible).

The Faulty Focus of the IT Profession

Computer Aided Software Engineering (CASE) efforts have failed to bring about the desired results, with the IT profession focusing primarily on:

Tools and techniques for producing software fast, but leaving largely unsolved the issue of determining what software should be developed to solve a particular business problem or to optimize business processes and structures.
Very elaborate methodologies that describe all facets of the process but don't provide convincing, practical tools and techniques for producing a blueprint of the sociotechnological system to be implemented.
Pursuit of fads and promotion of the misconception that software engineering by its nature needs to be different from the mature engineering disciplines.

Dealing With Complexity in an Understandable Manner

Is there a straightforward way of dealing with sociotechnological system complexity? We believe there is, if the objective is to conceive an improved process and develop a specification or blueprint for implementing it.

A primary precondition is that the concepts and terminology of the technique be easily understandable by all stakeholders, not just software professionals, as is the case with the popular methodologies.

We apply the same concepts to modeling of a company or of a software system, i.e., to any discrete event system, therefore looking at both together as one "whole" and designing optimization of both is quite natural. In fact, a software or re-engineering project is a "system" in this view and should be modeled prior to implementing it.

Fundamental Building Blocks of Systems

GRADE is based on concepts and terminology derived from observable reality. We view a sociotechnological system and its representation in a model as being made up of three "fundamental building blocks":

Active objects (or "result" producers), e.g., an IT system, a manufacturing plant, a supplier, a customer
Passive objects (or produced "results"), e.g., an order, parts, an assembled PC, an e-mail message
Processes (or activities that produce "results"), e.g., processing an order, assembling a PC

An active object is active and supports a process.

A process can consume, produce or modify a passive object.

A passive object can be created, sent to another active object and used or modified by an active object.

Decomposing Fundamental Building Blocks and Keeping Track of Details

Active objects, passive objects and processes can be very complex, and therefore it must be possible to represent each on different levels of detail or decomposition. Furthermore, to ensure integrity of a model, it must be clear which active object deals with which passive objects and what process it supports, i.e., an integrated view of structure, behavior and data.

Different Views of a Model

It must be possible to derive different views to serve different needs. For example, in some cases it is important to see a business process from the perspective of a single active object, and in other cases to see how a process spans multiple active objects.

In other situations it is important to describe fragments of a process, such as individual tasks, with their preceding and succeeding events and have them automatically combined into task sequences, based on these.

We have found that the modeling approach based on fundamental building blocks, from which different views are derived to serve different audiences and needs, permits us to understand and manage seemingly unmanageable complexity and thus makes possible global process optimization in a systematic and practical manner.

Ten Primary Issues Addressed by GRADE

Our experience with complex systems has led us to believe that the following are the major issues to be addressed by a technology for developing system blueprints:

Effectively communicating concepts, needs and solutions among people of different backgrounds and orientation.
Representing complexity on different levels of detail, yet in a consistent and unambiguous manner.
Making complex interrelationships among parts of a system understandable and presenting the consequences of changing one part on the rest of the system.
Validating assumptions before committing to implementation, either visually or through prototyping or simulation.
When optimizing business processes, presenting the enterprise organization, its IT systems and the external organizations with which there is interaction as an integral whole.
Keeping information about a system so that there is a place for everything and everything is in its place, and allowing rapid registration of known facts, which can be displayed in their graphical context.
Facilitating thinking in terms of processes and results rather than functions.
Allowing the user to start structuring a model for a system of seemingly overwhelming complexity.
Facilitating the transition from "as is" to "to be" in a systematic manner.
Presenting model information to suit different objectives and audiences, e.g., suppressing diagram details, enhancing diagrams with pictures, presenting different views, etc.

Click here to go to the GRADE product page.