dWare OS

Event-based business processes modeling

What is the idea? 

You look at the world and describe it with a set of tools.

Is there any philosophy?

Yes, there is.

Everything is an event.

That’s all.

(unbelievable, J but true!)

What is the result?

A web-based information system.

You mean

the business realityàme àand the virtual reality

without programmers, testing, …?

Yes, exactly!

Is it possible?

Yes.

In reality we talk about modeling.

Modeling business processes based on the idea that everything that happens in business can be described like an event.

You already speak about tools. What kind of tools?

The simplest are some very simple and largely employed pictures like:

And what else?

You have a piece of software in which you have to put down your observations of the reality that you want to incorporate in an information system.

Does it take a lot of time?

Depends on your expertise in what you are starting to do. Yours and that of your client.

Can I see something of my work?

Yes. This is a so-called business process of …

But where is the web-based system ?

Please …

Are there any reports?

Reports are our favourite thing to do.

Users, roles …

Absolutely

Organizational structures?

Of course.

What is the name of this software?

dWare OS

I understand that we have a software with a philosophy and tools to transform the business reality into a virtual reality called Information system without programming, testing.

Yes, and not only the business reality…

Can I modify my first idea or expand it?

Yes.

What will happen with the data?

The data follows the changes.

Who created dWare OS?

dWare OS is created by dWare Ltd.

EVENT-DRIVEN APPROACH TO THE CONSTRUCTION OF

INFORMATION SYSTEMS

Damian Ivanov

dWare Ltd., dware@dware.bg

SUMMARY

Various statistical data shows that about 60% of the developed information systems end without achieving their set goals.  Our analysis shows that the problems lies neither in the stages of development of the information systems, nor in the methodology.

The problems lies in the vision /absence of a suitable abstraction/ and adequate tooling to materialize the examined processes into an information system.   The approach and tooling developed by us allow modelling of the business reality by means of ‘dEvents’. As a result, we obtain simple and understandable notations, convenient to maintain and develop, and the relevant operating web-based information systems, based on a relational Database Management System.

KEY WORDS

Event, Object, Space, Attribute, Event-driven model, Methodology for Information System development, Physical layer, Logical layer, Presentation layer, Notation

1. I.                   INTRODUCTION

Our attention is focused on the construction /examination, design, elaboration, implementation, maintenance and development/ of information systems /IS/.

We will analyse the data about the software projects, showing that approximately 60% of them are not successful.  

By tracing the life cycle of a project, we will try to outline the major issues underlying the failures.

We will propose a new philosophy and tooling pretending to eliminate the established reasons underlying the failure.  Finally, we will present the benefits of the application of the new philosophy.  

1. II.               LIFE CYCLE OF THE SOFTWARE PROJECT, METHODOLOGIES AND PROBLEM ANALYSIS

Are there any problems that require analysing the construction of an information system?

It turns out that the processes concerning the construction of an information system constitute a complex, long-term and expensive undertaking, yet without a guaranteed result.

Some facts:

1. ROGER SESSIONS [1] assesses that the costs of unsuccessful projects on a WORLDWIDE SCALE for 2009 are USD 6.2 trillion.
2. Dr John McManus and Dr Trevor Wood-Harper [2] estimate that the costs of the unsuccessful projects in EU for 2004 are EUR 142 billion and only one of every eight projects has been accepted as fully successful according to a study performed in the period 1998-2005 and covering 214 projects in 10 areas /defence, healthcare, education, agriculture, trade, production, finance, construction, transport and logistics/.
3. The Standish Group [3] analyzed the successfulness of the projects for 2009 and published the following figures:

-                 Successful projects (achieved goals, kept deadlines);  38%

-                 Unsuccessful projects (goals not achieved):                   33%

-                 Suspended projects:                                                                29%

Similar findings are valid for France, Switzerland, USA and the whole world.  The figures and percentages will for sure be different in the various studies and for the different countries, but this is no important.  

What matters is the ratio between successful and unsuccessful projects and the constancy of this ratio over the years.

Those figures demonstrate that the stake is great and it makes sense to seek for the reasons for the failure and most of all to find a solution.

Can we outline the problem more clearly?

The project life cycle analysis demonstrates that irrespective of the viewpoints, a life cycle incorporates the following stages:

-                 definition of goals,

-                 study,  

-                 design,  

-                 elaboration,  

-                 implementation,  

-                 maintenance and

-                 development.

The above-mentioned study by Dr John McManus and Dr Trevor Wood-Harper analyses the stage at which the studied 214 projects are suspended or delayed.

№1

SUSPENDED AND DELAYED PROJECTS

Out of the studied 214 projects, 28 were cancelled and 32 were delayed at the design stage! We can already note the fact that 15 projects were suspended and 57 were delayed or made more expensive at the programming stage.

What is important for the design stage?

New and new design methodologies have been developed since the 1950s.  There are tens of methodologies.

‘Agile’ methodologies have also been appearing and 55 of them have been described.

What does this say, without even analysing any of them?

It says only one thing.  There is a problem.  None of them complies with the requirements regarding the construction of various information systems.

Why do agile methodologies appear?

It is well-known [4] that 17 people of the practice define the following conclusions:

-                 People and communication are superior to processes and instruments.

-                 Operating software is superior to detailed documentation.

-                 The cooperation with the customer is superior to negotiations during contract execution.

-                 Addressing changes is superior to following the plan.

In fact, the right elements underlie the various methodologies until now, which leads to:

-                 Failure to achieve the goals

-                 Time delay

-                 Increased costs

Is this true?

If we examine more carefully any of the methodologies, we will find several simple truths:

-                 All methodologies /new and old/ solve the same problem

-                 However each one of them gives priority to one or another aspect of the study, design, implementation in order to solve various problems.

Thus, the main problem is the time necessary to accomplish the project, since the increased costs and failure to achieve the goals are a function of time.

Taking into account that the scope of activities related to study, elaboration and implementation of a project, irrespective of the selected methodology, is the same, if the projects had been accomplished within the expected deadlines, most of the methodologies would have been obsolete.

Let’s have a look at the above study, where we can see the number of projects cancelled or delayed at the programming stage – 15 and 57 respectively.  

In other words, all those methodologies have problems as early as this stage – the programming.  

This is an indication that:

-                 We will obligatorily have problems with the developed system due to the specific aspects of the programming itself /definition, elaboration, testing, integration, documenting…/

-                 Absence of vision, adequate abstraction of the essence of an information system as a reality model, which always requires additional development of new and new programmes.

Let’s have a look from another viewpoint.

Generally, an information system is a reflection /model/ of some aspects of the business reality in an organization.  /Now we are disregarding the technical and communication aspects, human resources, software, which ‘bear’ and achieve the goals of the information system./

In order to reflect a reality, we need the appropriate tools.  An artist uses paints and paintbrushes, a photograph – a camera, a writer – a pen, etc.

Is the reflection complete and accurate? Of course, the reflection is incomplete, however it achieves the set goals to some extent and does the expected work.

Let’s have a closer look at the business reality.   

From information point of view we have contracts, invoices and other documents, nomenclatures…

We could also have a look at the business reality from the point of view of:

-                 organisational structure,  

-                 ‘actors’ /roles/ in business

-                  etc.

We have seen that the programming stage is reached as a result of the study and design.

The consumer software is most often presented as an aggregation of algorithms and programmes implementing them in order to achieve the goals of the information system.

The result of the design of an information system consists mainly of describing the business processes according to certain methodology or without a methodology /information flows, information carriers, algorithms for the processing of information, organizational structure, ‘actors’…/ and necessitates the creation of the relevant programmes.  

Sometimes the programmes turn into software implementing certain functionality, supplemented with options to determine the parameters for the purpose of more flexible compliance with the requirements of the specific business.

Determination of the parameters, but within the framework of the specific functionality! The new functionality requires new programmes or new software.

WHAT IS THE RESULT?

Usually the result is an information system that achieves the set goals to a different extent, however always with restrictions in terms of development towards inclusion of a new functionality from the whole business reality /as stated above/ and system support.

IS THERE AN ALTERNATIVE?

An alternative to what?

The business space is a whole.  Examining it from various viewpoints, subsystems, tasks … is made for greater convenience.  Mainly for convenience of management.  But most of all, due to the absence of philosophy, abstraction, covering and reflecting adequately the set goals, in a simple and understandable language, and the whole business reality.

In other words, what we have seen in the previous paragraphs is the alternative to the impossibility to reflect the business reality in any other way.

IS THERE AN ALTERNATIVE TO THE EXISTING PRACTICE?

Yes, there is, and it comprises the creation of new philosophy, new abstraction of an information system, and may be a more general way to model the business reality, while trying to awaken a new and unknown sensibility to perception as a whole.

And apart from philosophy, we would also need tooling to do this.

1. III.           PHILOSOPHY AND TOOLING OF dWareOS

Our solution is dWare OS. dWare OS /dOS/ is:

-                 philosophy, abstraction, trying to present in a simple and accurate way the business reality /within the framework of your needs, according to the degree of your knowledge/, and

-                 tooling, aimed to fix such description and enliven the described models.

The main idea is the finding that everything in the business reality can be presented as dEvents.

The elements of dWare OS and dEvent, dObject, dSpace.

A dEvent is described by:

-                 name

-                 attributes

dEvents are materialised in dObjects.  All dEvents are at the ENTRANCE of all dObjects.

Every dObject generates a dEvent as an EXIT.  The aggregate of dObjects, dEvents and their movement form dSpace.   

We can differentiate between several layers within a single dEvent.  

-                 logical/functional,

-                 presentation,

-                 physical.

Examples of dEvents include contracts, invoices, letters of acceptance and delivery, commodity receipts, inventories, petty cash credit orders, petty cash payment orders, advance reports. Examples of dObjects include accounting warehouse, marketing, but also register of invoices, register of contracts. An example of movement is the invoice, which will be located in the dRegister of invoices, in dAccounting, but also in dWarehouse, and dMarketing.  It will also go to the entry point of dContracts, where it could be rejected depending on the specific business practice. A single dSpace may be the space of accounting, cash register, but all objects could also be in the same space, depending on the organization of work in the specific business practice.

Graphic presentation /Notation/

Business spaces are described by a set of graphic symbols, such as beginning, object, condition, entrance:  on-screen, object, e-mail, file, service, exit to:  file, e-mail, print… according to the methodology for construction of an information system, developed by us.

Managers

Managers are the programmes that ‘enliven’ the dSpaces.

What is the result of the implementation of an information system by this philosophy and tooling?

1. IV.           CONCLUSION

The results are most of all in the overcoming of the main problems of the existing methodologies for the construction of information systems.

-                 Accurate and timely reflection of the customer’s needs

-                 Quick result

-                 Achievement of the goals

-                 Low price

It is worth noting that our abstraction does not reject or oppose none of the methodologies, approaches or practices for the construction of an information system, but only allows the opportunity to achieve the goals set for the information system.

The opportunities in a dSpace are a consequence of our abstraction:

-         time ‘rewinding’

-         changing the ‘rules of the game’ /functions/

-         ‘expanding/shrinking’ the space itself with new objects/functionality.

Two more significant results are achieved alongside:

-                 Easy support

-                 Predictability and controllability.

And /almost/ no programming!

dWare OS

Как да пристигнете първи, когато заедно с останалите пътници  пътувате  в един и същ самолет? Независимо от това в коя класа сте: SAP, Oracle, Microsoft …

Не вярвам, че някой взима категорично решение каква система за управление на бизнеса си взима на един или друг  форум, Мисията е по-скоро разузнавателна с цел  да види, ако има очи за това, кой какво предлага било то от презентациите, било  и от споделения опит. Това обаче не е лесна задача, защото информацията, която се поднася малко или повече е украсена, да не кажем и деформирана, защото се прави от разработчика или внедрителя на дадена система, на даден продукт. Преценката на потребителите, вече внедрили една или друга система, също не винаги е напълно обективна, защото малко или повече оправдава вече взетото решение.

 Ето защо умението е не само да се слуша, а да се чува същественото, не само да се гледа, а да се вижда в дълбочина и в същината на това което всяка фирма разработчик представя пред публиката от потенциални клиенти.

Ако се заслушате в презентациите ще видите, че никой нищо конкретно не каза. Вие постепенно бивате омайвани от:

• Една мъгла.
• При това представена примамливо.
• Въпросът е - Има ли нещо зад мъглата?
• Естествено, че има. Но то е малко по-различно      от това, за което съзнателно или не се говори доста мъгляво.

Каква е истината ?

Истината е, че нещата са пределно ясни на вендорите и не до там ясни на клиентите.

Вендорите прекрасно знаят какво може тяхното решение (модел, идея, философия), както и пътищата, по които могат да го развиват /естествено срещу съответната цена) и са го предвидили в своята методология за инсталиране.

Клиентите по-скоро се сблъскват с проблемите, които ежедневно трябва да решават в своя бизнес. Всичко останало им се струва като един тих ужас, една спотаена лудница,  хаос, създаден от разни бюрократи и неблагодарни служители ....

Решението на вендорите прилича на  джудото – да те преборя като използвам не моята сила, а твоята. От теб искам да ми кажеш как искаш това, как да става онова. Да, де ама ето, че попадаме в парагаф 22 –хем не познаваш продукта, хем да казваш как го искаш.

Освен това бавно, но сигурно те влудява целият този набор от неразбираеми справки и отчети. И тук изведнъж се появяват спасяващите магическите кубове и т.н. Не че са безсмислени. Просто показват неспособността на съответната система да доведе нещата до край със собствените си средства.

А нещата стоят съвсем конкретно.

От едната страна стои отчетността, а от друга страна се намира оперативното управление.

Отчетността пък е още по-ясна. Тя обикновено се припокрива със счетоводството и за целите на това представяне може да приемем, че е така. Да, ама в счетоводството има един точно определен набор от отчети, които трябва да се представят на определени дати. Всеки един от тези отчети се прави по точно определен начин и има съответната форма и съдържание. Следователно половината от нещата са пределно ясно дефинирани, до толкова ясни че може да се изкаже и едно еретично твърдение – а именно, че няма нужда от счетоводство. Не че няма наистина нужда, но няма нужда от обичайните счетоводства, а има нужда от такова счетоводство, което да умее да анализира и да дефинира счетоводната отчетност в полза на фирмата, стъпвайки на конкретната икономическа действителност, даденост – закони, практики.

Оперативното управление е по-интересното. То е в някаква степен по-различно при различните клиенти. И какво става?  Имаме добрите практики. Но те какво са ? Едни реализирани модели на това как да си получиш отчетната информация. Но наистина ли са модела на успеха ? Едва ли има някой, който да даде гаранция. /Връщам се към началото при сравнението с за пътниците в самолета.

Къде е решението ?

Решението е в инструмент, който да отразява и съчетава разнообразието на бизнеса и креативността на хората.

И за да не се преоткриват вече откритите неща, защото тук нe става дума за първите любовни трепети от откриването на любовта или унеса на танца, тръпката на ловеца, рибаря, бънджи скока, опиянението от скоростта, ... а за борба на живот и смърт, за капитализъм, то оптималният инструмент трябва да гарантира тази отчетност от една страна и да е свободен да отразява бизнеса, при това по начин, който да се променя всеки ден ако трябва.

Този инструмент се казва dWare OS.

For further information please contact us at

dware@dware.bg