PROCESS-CENTRIC ENTERPRISE MODELING &
MANAGEMENT (ProCEM
®
)
Erich Ortner
Development of Application Systems, Technische Universität Darmstadt, Hochschulstr. 1, Darmstadt, Germany
Keywords: Enterprise Modeling, Language-Critical Development of Application Systems.
Abstract: The shortage of skilled IT-staff as well as the technological possibilities offered by Service-oriented
Architectures (SOA) and Web 2.0 applications, leads us to the following consequences: working processes,
job engineering and labor organization are going to be modeled and therefore made digital in the sense of
IT-support. This goes along with modeling working processes being independent from the individual
employee in areas to be rationalized resp. not to be staffed by qualified specialists. Hence, there will be a
worldwide net based selection of those who are able and skilled to fulfill modeled work like e.g. “handling a
damage event” or “creating an optimized data structure for master data” by means of the Unified Modeling
Language (UML) in the most effective and efficient way. An enterprise will therefore neutrally manage its
modelled work processes (HB-services) and IT-services (application programs) taking place as computer
supported work equipment in any working process being located anywhere in the world without assigning it
first to a specific performer (natural or artificial actors). By doing so it is possible to control and
dynamically execute working processes globally based on the division of labor, and on a data base
supported administration of “bills of activities” (work plans) by means of the World Wide Web. All that
requires new and dynamic – in the sense of component based – job descriptions and other work equipment
exceeding today’s established skill and task management by far.
1 INTRODUCTION
According to Aristotle (384-322 BC), Architectonics
refers to the art and science of building, while the
term architecture denotes the structure. In civil
engineering, the proportion of “art” within the
structuring activity is usually drawn upon to
distinguish an architect (emphasis on art) from an
engineer (emphasis on methodology).
For vendors and users of information
technology, the term service-oriented architecture
(SOA) has been an issue for about many years.
Organization-centric Requirements Engineering (on
a constructivistic basis) with reference to Applied
Computer Science was proposed for the first time in
1980 (Wedekind & Ortner 1980). The following
observations are important to this concept today:
Organizational processes, which, to some
extent, offer a free choice (e.g. specific
knowledge gained from experience) to the
acting persons in particular steps of an
occurrence, are principally to be distinguished
from the inherently different algorithmic
computer processes (software and hardware).
Therefore, organizational processes ought to be
specified further by language-critical
organization theory (Lehmann 1999).
Ubiquitous (= found everywhere) computer
technology leads to the fact that presently
almost any object (thing or occurrence) can be a
medium in this technology.
Common languages, (e.g. “ontologies”,
conceptual schema, ortho-languages) whether
spoken by people or used in technology, always
serve as a means for integration. This includes,
to some extent, the integration of heterogeneous
elements in a system or architecture.
Today, the object-language/meta-language
diefference in application systems – the
showpiece of system informatics – is firmly
established within the overall architecture by
means of repositories. For example, repositories
are used to enable and facilitate the
management of component-based solutions.
89
Ortner E. (2008).
PROCESS-CENTRIC ENTERPRISE MODELING & MANAGEMENT (ProCEM
R
).
In Proceedings of the Third International Conference on Evaluation of Novel Approaches to Software Engineering, pages 89-98
DOI: 10.5220/0001763300890098
Copyright
c
SciTePress
In the field of constructive languages and
consequently in research methods of various
application fields, there has been considerable
progress in the past few years ascribed to the
Unified Modeling Language (UML), whose
development is still ongoing.
There are predominantly three factors, which
have instigated the necessity to start organizing
work globally. These are: The fact that
Enterprise Organization Theory is a part of
Applied Computer Science, the comprehensive
concept of application systems as service-
oriented architectures, and the development of
new technologies on the internet (Web 2.0), for
example interactive applications (Nussbaum et
al. 2007). It is essential to approach this
organizational task from the position of
dynamically organized enterprise networks that
interact globally.
In the following, we will describe how the
ProCEM
®
method (Process-Centric Enterprise
Modeling & Management) meets the above-
mentioned requirements, taking into consideration
the human needs. The basis for our description is the
experience gained from accompanying the project
“Best Process Architecture”, a contribution to the
BITKOM college competition 2007, the seminar
“SOA in Accountancy” held in the summer term of
the same year, and the lecture organization-centric
“Development of Application
:
Systems”, which is an
ongoing lecture at TU Darmstadt as of 1996.
The progression of software engineering to
enterprise engineering in the last thirty years as well
as the reversionary methodological development of a
complete application system can be conceived as a
basis for ProCEM
®
. Figure 1 depicts this “historical
versus methodological” basis.
2 ORGANIZATION-CENTRIC
DEVELOPMENT OF
APPLICATION SYSTEMS
The iterative orchestration of application systems
(see figure 2) is one particular feature of service-
oriented architectures in the following aspects:
Enterprise Engineering
(Embedded) System Engineering
Software Engineering
+ Processes & Humans
+ Hardware & Technology Carrier
Methodology
History
Enterprise Engineering
(Embedded) System Engineering
Software Engineering
+ Processes & Humans
+ Hardware & Technology Carrier
Methodology
History
Figure 2: Historical versus methodological development o
f
application systems.
Figure 1: Iteration paths of orchestration: processes - technology - man.
: Organization
centric
: Information Technology
centric
(Work) Process Reconstruction
(BPMN, Use Cases)
Rekonstruktion
der (Arbeits-)Prozesse
(BPMN, Use Cases)
Process Improvement
(Simulation, Optimization, etc.)
Service Discovery
(e.g. permanent or transient resp.
Internal or External Services)
Service Schema as Product
(e.g. Service Provider)
Provide
Select
Provide
Select
Work Plan as Product
(Human capital
management)
:Human centric
Optimized
Process
Organization
Dynamic
Organization
Structure
Supporting
Information
Technology
Legend:
: Organization
centric
: Information Technology
centric
(Work) Process Reconstruction
(BPMN, Use Cases)
Rekonstruktion
der (Arbeits-)Prozesse
(BPMN, Use Cases)
Process Improvement
(Simulation, Optimization, etc.)
Service Discovery
(e.g. permanent or transient resp.
Internal or External Services)
Service Schema as Product
(e.g. Service Provider)
Provide
Select
Provide
Select
Work Plan as Product
(Human capital
management)
:Human centric
Optimized
Process
Organization
Dynamic
Organization
Structure
Supporting
Information
Technology
Legend:
ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering
90
optimized work processes,
ideal assignment of employees, and
dynamic use of information technology using
services.
Services, or more precisely service schemas, are
application software that implements work
procedures. They are developed on the basis of
components and specified as algorithms.
Rather than having oboes, violins or triangles at
ones disposal, the orchestration of application
systems (see figure 2) makes use of human beings,
organizational structures and technology. Whereby
anyone who specifies e.g. organizational processes
in the same way as computer processes and does not
distinguish between human-related symbol
processing and computer-based symbol processing
(Oberweis & Broy 2007), is not suitable for the
development of organization-centric application
systems. Such a person lacks the interdisciplinary
knowledge taught by some of the forward-looking
chairs of Applied Computing and Application
Systems at universities worldwide today.
3 INTERDISCIPLINARY
LANGUAGE-CRITICAL
SPECIFICATION OF IT-USE
Which skills and what kind of knowledge do
developers, i.e. “business architects,” “application
developers,” “solution architects,” and so on, need
for organization-centric application development in
order to successfully participate in projects of this
kind or even execute such a project on their own? In
his book “Der Flug der Eule” (The flight of the owl),
Mittelstraß (1989) gives us an answer that is as
clearly defined as it is simple:
“Anyone […] who has not studied interdisciplinary
cannot perform interdisciplinary research.
The acquisition of interdisciplinary schemas and
the understanding of them is a prerequisite for
interdisciplinarity. Anyone who has only studied
how to apply something will not be able to develop
organization-centric application systems. The
following is a simple example that illustrates the
profound understanding of the development process.
The example reconstructs a data schema in Applied
Computer Science.
Schematize the following sentence in object-
language,
a) “Smith is a customer who is willing to pay.”
by means of computer sciences, specifically the
meta-language “relational model”:
b) “Relation Name (key attribute(s); non-key
attributes)”
in an interdisciplinary way, i.e. by different
disciplines simultaneously. In order to accomplish
this, a developer must not solely understand the
sentence in object-language a) with respect to its
business-driven generalization (schematization,
norm), but additionally, the user must have agreed
on the norm derived from it. In our example, this
would mean that a society (language community)
tolerates the following object-language norm:
a’) “If we identify a person as a customer, we are
allowed to characterize the customer more
closely by the attribute ‘payment behavior’.”
Furthermore, it is necessary to realize or
understand that the “relational model” is merely a
different grammar (meta-schema) for representing
the standardized (schematized) object-language
“content”. It is our goal to maintain customer data
efficiently on the computer. Through modeling, we
achieve the significant result of our interdisciplinary
schematization:
b’) “Customer (name; payment behavior)”.
Interdisciplinary schematization (modeling) is
one of the core tasks in Applied Computer Science
such as Business Informatics. For the acquisition of
interdisciplinary knowledge, e.g. in university
courses of study, there is even a so-called
“methodical order” (see figure 1). We can formulate
it as follows, whereby the figures in brackets
indicate the “sequence”, i.e., the methodical order.
Today specified processes are means for ends.
Computer Science: form (4) follows
function (3)
Business Informatics: applications (3)
follow processes (2)
Business and Social
Sciences:
means (2) follow ends (1)
Theoretically, the methodical order, or course
can be avoided. However, in practice, it is
recommended to adhere to it. It is most advisable to
“put on the socks before putting on the shoes”,
although, at least in theory, it may be possible to
PROCESS-CENTRIC ENTERPRISE MODELING & MANAGEMENT (ProCEM®)
91
consider the reversed order. The problem in some of
the programs of study in Computing Sciences is that
interdisciplinary knowledge is not taught – even at
the recently appointed German superior universities,
an apparent lack in IT-architects has lead to the fact
that students in bachelor programs of study merely
concern themselves with pure computer sciences, i.e.
(3) and (4). For those students who have not entered
a practical profession by then, the Masters program
of study will “ensure that they are acquainted with
matters of Applied Computer Science” (Oberweis &
Broy 2007). Well, it is conceivable that disciplines
become extinct!
3.1 Organization Modeling
For successful organization modeling (Enterprise
Engineering) – especially with respect to
optimization – differentiation is vitally important.
Figure 3 illustrates the possibilities regarding
work processes and structures.
The capability to differentiate clearly is critical
to the ability to optimize. This is important for the
object-language level, the application field, as well
as for the meta-language level, the diagram language
field. On both levels, the point is the reconstruction
of connector words (e.g. to do) and topic words (e.g.
to work). On the meta-language level, the developer
gets to know the modeling method in greater detail.
On the object-language level, the grammar of the
modeling language plays a vital role. In the latter
case, the organizational expert knowledge of the
relevant application domain must be represented in a
structured way.
Modeling (topic words of the application field)
and structuring (connector words of the modeling
language) are different but they supplement each
other as complementary parts.
Even before the object-oriented system design
diagram languages have proved to be suitable
modeling languages for the organization of a
company’s structures and processes. Use cases for
example are especially useful for the structural
aspect (see figure 4), while the Business Process
Modeling Notation (BPMN) is suited ideally for the
procedural aspect (see figure 5).
+
+
8.1 IE collects goods from production
and checks identity
+
+
8.2 IE checks quality
8.3 IE sorts goods
8.4 IE reports change in stock to IM
Employee of
Finished goods
inventory (IE)
Production
Inventory
Management (IM)
8. Finished goods inventory
+
+
+
+
8.1 IE collects goods from production
and checks identity
+
+
+
+
8.2 IE checks quality
8.3 IE sorts goods
8.4 IE reports change in stock to IM
Employee of
Finished goods
inventory (IE)
Production
Inventory
Management (IM)
8. Finished goods inventory
Figure 4: Use case diagram of finished goods inventory.
(Work) Processes
(Work) Structure
Process
Architecture
Movement
Inventory
Means for Work
-software
-knowledge
-device
(Whereby?)
Work Input
- basic material
- operating supply
item
-data
(What from?)
Work Output
- product
- service schema
(Wherefore?)
Performer
-man
-machine
- interaction
(Who?)
Workplace
-any
-fixed
(Where?)
(What?)
Operation
(When?)
Work Sequence
(How?)
Work Procedure
Work Object
- physical
-intellectual
(Whereof?)
(Work) Processes
(Work) Structure
Process
Architecture
Movement
Inventory
Means for Work
-software
-knowledge
-device
(Whereby?)
Work Input
- basic material
- operating supply
item
-data
(What from?)
Work Output
- product
- service schema
(Wherefore?)
Performer
-man
-machine
- interaction
(Who?)
Workplace
-any
-fixed
(Where?)
(What?)
Operation
(When?)
Work Sequence
(How?)
Work Procedure
Work Object
- physical
-intellectual
(Whereof?)
Figure 3: Differentiated work organization.
ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering
92
Detailed descriptions of modeling languages can be
found in various case collections (Cockburn 2001)
or OMG manuals. However, anyone who later, in
the system design, intends to specify the flow of
work processes in greater detail is well advised to
distinguish the aspects like “operations”, “work
procedures” and “sequence of work” or “workflows”
orthogonally. The same applies to the organization
structure and aspects such as “workplace”,
“vacancy”, “employee” or “work material” (see
figure 3). The optimization can now be considered
sensibly and from different angles (aspects).
account stock changes
report stock changesstock FGcheck quality
receive FG and
check identity
Incoming
Finished goods (FG)
Gear Inc.
Goods inventory
Inventory management
account stock changes
report stock changesstock FGcheck quality
receive FG and
check identity
Incoming
Finished goods (FG)
Gear Inc.
Goods inventory
Inventory management
Figure 5: BPMN diagram of incoming finished goods.
3.2 Method-Neutral Knowledge
Reconstruction
The method-neutral knowledge reconstruction
(Ortner 1997) is primarily communicative and
hardly any diagram representations are used.
In order to get a first picture of the important
tasks, which are performed in close cooperation with
the users, we classify them roughly in the following
three parts:
Collection of propositions that are relevant for
development by talking to the users.
Clarification and reconstruction of the expert
terminology that has been used.
Establishment of a common enterprise expert
language.
The collection of propositions relevant to the
development can be done by using a model, as
shown in figure 6.
The model is intended to aid the collection and
to ensure that all potential types of results for the
system design have been scrutinized in consideration
of their underlying expert knowledge. The following
list contains several propositions that can be
assigned to the above fields (see figure 6):
a) An account has an account number.
b) An account is opened.
c) Opening an account results in an opening
balance.
d) The total of all debit line items must be the
same as the total of all credit line items in
double entry accounting.
e) A (personal) account is assigned to a business
partner.
f) Shipment of goods is related to posting
business transactions.
g) At the end of an accounting period, all of the
accounts are closed, their values are entered in
a profit and loss account and ultimately
gathered in the balance.
In the clarification and reconstruction of the
identified expert terminology the following
“defects” are discussed and examined thoroughly
with the future users or the company’s experts.
Checking synonyms
Check for words with the same meaning
(extension and intension) that can be
interchanged.
e.g.: MEMBER and ASSOCIATE have the
same meaning for DATEV.
(
DATEV is a computer center and software house for
the German-speaking tax profession where the author
worked as executive manager in software development
for seven years.
)
Eliminating homonyms
Check for words that are written or
pronounced in the same way but have a
different meaning.
e.g.: STALK, which can mean either part of
a plant or to follow someone around
Identifying equipollences
Different names are used for the same objects
(extension) from different perspectives
(intension).
e.g.: Goods or merchandise of a company is
referred to as STOCK from a quantitative
perspective and INVENTORY ACCOUNT
from a value perspective.
Clarifying vagueness
As there is no clear delimitation (definition) of
the terms in regard to their content (intension),
Object
INTERNAL
EXTERNAL
STRUCTURE
PROCESSThing
oriented
Occurence
oriented
a)
b) c)
Constraints
d)
e) f) g)
Object
INTERNAL
EXTERNAL
STRUCTURE
PROCESSThing
oriented
Occurence
oriented
a)
b) c)
Constraints
d)
e) f) g)
Fi
g
ure 6: Classification schema for
p
ro
p
ositions.
PROCESS-CENTRIC ENTERPRISE MODELING & MANAGEMENT (ProCEM®)
93
it may not be clear which objects belong to
each term (scope, extension)
e.g.: Does RESIDENCE, the place where a
CONSULTANT works, belong to the term
CHAMBERS for DATEV or not?
Replacing wrong designators
Discrepancies between the actual meaning of
a word and the meaning assumed at first
(intension and extension)
e.g.: For DATEV, the CONSULTANT
NUMBER does not define the function of a
tax CONSULTANT, but it defines the
USER RIGHTS a tax CONSULTANT has
within DATEV.
This clarification results in further propositions
relevant for development. Their relevance for the
result types (system design) can be examined with
the help of a classification schema (see figure 6).
Work on building a common expert language for a
company, which is aimed at integrating all of a
company’s knowledge resources, can be organized
in different ways.
1. With the help of a repository, a kind of
glossary will be created and administered.
This glossary will contain all the terms that
are important for an organization (language
community), and should be designed for
internal and external use.
2. A much more complex way, in comparison to
(1.), of representing a company’s knowledge
is with an encyclopedia. The encyclopedia
amounts to a conceptual schema for data but
will go substantially further in respect to
terminological coherences. This approach will
distinguish inward and outward knowledge,
which will be administered in a repository as
an enterprise knowledge base.
3. The enterprise expert language is a rational
interim language that is implemented on a
meta-meta language level in the repository
(Ortner 1999). It is used for integrating and
translating other languages used in a company.
For users, it is not necessary to know the
interim language itself.
Currently, the three variants discussed above can be
found in industry worldwide. Vendor-independent
research is done in the field of SOA under the
catchword Enterprise Application Integration (EAI).
Furthermore, companies like Oracle look into
Application Integration Architecture (AIA) and offer
products such as Fusion. Other vendors offer
products like WebSphere (IBM) or NetWeaver
(SAP) for the integration task.
3.3 Generally Object-oriented System
Design
After the development-relevant knowledge (see
figure 6) has been reconstructed neutral to specific
methods and technology (e.g. according to Ortner
1997), and integrated into the overall knowledge
base of an enterprise using common language, then,
in the system design, this knowledge is transformed
into the result types of an object-oriented solution to
the task. Figure 7 shows an object-oriented system
design according to Schienmann (1997) that has
been extended for the design of service-oriented
architectures of an enterprise.
When we speak of entirely object-oriented
development of application systems, the
enlightening step is the introduction of objects from
computing sciences as grammatical objects.
Grammatical objects are target points of language
actions (e.g. writing, speaking, thinking) in a
sentence, whereby they can also be replaced by
pronouns in the sentence (e.g. one, he, him, this
one). At school we have learned to speak of direct
and indirect objects, genitive objects and various
prepositional objects.
In contradiction to what many computer
scientists still believe, when modeling and
programming in computer science we do not
concern ourselves with concrete or “ontological
objects” suc h as this chair, that apple or my laptop.
When speaking of objects “informatically” (i.e.
modeling and programming), it is of particular
importance that abstract types such as “class” in a
repository or the term “invoice” in an application,
are to be thought of as target points. The concrete,
“ontological objects” are usually found in the
application fields.
Computer science is the science where students
learn how to talk constructively about language
(grammatical) objects, or more precisely, about
abstract objects. Needless to say, we can still start
from the concrete objects of the application fields in
“Requirements Engineering” and when introducing
Service
Application
(Procedure Part)
Result
Type
Inventory
Procedure Process
Internal
External
Conceptual
Schema
Organization
Service
Application
(Data Part)
Participation
Restrictions
of
Work
Occurences
Figure 7: Extended object-oriented enterprise design.
ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering
94
the implemented solution, we can refer back to the
users’ concrete (ontological) objects.
The object-oriented approach in the development
of application systems goes back to Platon. Platon
classifies objects from the perspective of human
beings and their languages into things (nouns, proper
names) and actions, which can also be considered
occurrences (verbs). If we transfer this classification
to operating with data on a computer, the object-
orientation (resp. its object) will be classified into
the fields of data orientation (things) and procedure
orientation (occurrences). This classification shows
why object-orientation is universal. It encompasses
data orientation (data classes) as well as procedure
orientation (procedural classes).
Based on the results of organization modeling
(enterprise engineering) and (embedded) system
design (see figure 1), the results from figure 7 are
modeled (software engineering) in the following
methodical order:
1. Process Modeling:
BPMN diagrams (from organization
modeling)
State machine diagrams
Activity diagrams
...
Constraints (e.g. in Object Constraint
Language (OCL))
2. Participation Modeling:
Use cases (from organization modeling)
Sequence diagrams
Job descriptions (in the sense of structural
organization)
...
Constraints (e.g. organizational standards
such as signature regulations)
3. Procedure Modeling:
Class diagrams (data classes and procedural
classes)
State machine diagrams
Activity diagrams
...
Constraints (e.g. plausibility checks at data
entry in service-oriented applications)
4. Inventory Modeling:
Object type diagrams (for the conceptual
schema)
Dataflow diagrams (for specification of data
that are exchanged)
External schemas (extended as data classes)
...
Constraints (e.g. semantic integrity rules
for DBMS-enforced integrity)
Enterprise Engineering and the reconstruction of
development-relevant expert knowledge from the
application fields are highly communicative
processes. Here, users and developers communicate
very “intensively” (in great detail and clearly) with
each other. Diagram languages play a minor role in
this context. In contrast, the (entirely) object-
oriented design of a SOA with diagram languages
must be performed in an already highly
"significative" way. This means that the terms of the
object language and the meta-language (e.g.
”invoice” as an object-language terminus and
“procedural class” as a meta-language terminus)
should be displayed as independent as possible from
their use in the judgment-context. The focus is on
disclosing the types (software, concepts) that shall
be implemented later. Diagrams are ideally suited
for this purpose.
The diagram languages for procedure modeling
are of course very similar to the diagram languages
for process modeling. Procedure modeling
comprises of the process parts (algorithms), which
run as service-oriented applications while a process
is being executed, as well as of those process parts,
which can be specified in less detail since they
involve human work (e.g. following work plans).
The order (1.-4.) chosen here serves merely as a
recommendation. The modeling process is an
iterative process, as every well-educated developer
will know from practical projects (see figure 2).
4 CONCRETION IN THE LARGE
Organization-centric development of application
systems has been derived from data-centric
(Wedekind & Ortner 1980) development. The
development paradigm “applications follow
processes”, which is valid in today’s service-
oriented architectures, complements, but does not
replace the data-centric approach. Therefore, SOA
stands for a new paradigm, not a shift in paradigm.
The data-centric approach remains as important as
ever, but due to the triumphant progress of object-
orientation and component-based development, it is
integrated in the overall architecture and work
processes in a more “intelligent” way (Platon was
right!). In addition to data processing, work
organization (enterprise engineering) has become a
subject in applied computer science (software
engineering).
Figure 8 illustrates an enterprise that is organized
as an application system in a process-centric way,
PROCESS-CENTRIC ENTERPRISE MODELING & MANAGEMENT (ProCEM®)
95
considering the expert field (domain) and the logical
structure (architecture).
Machine Desktop Mobile Device
Person
Participants
Processes
Services
Resources
receive error
message
eval uate error
message
inspect error
message
maintain
document solution
Error Report
Service
Error Reports
System
Reports
Error Correction
Service
Service Plans Skills
Conceptual Schema
Customer
Products
Systems
Employees
Work Plans
Business Participants Tier
Work Processes Tier
Data Resources Tier
Business Services Tier
-BPT-
-WPT-
-BST-
-DRT-
Machine Desktop Mobile Device
Person
Participants
Processes
Services
Resources
receive error
message
eval uate error
message
inspect error
message
maintain
document solution
Error Report
Service
Error Reports
System
Reports
Error Correction
Service
Service Plans Skills
Conceptual Schema
Customer
Products
Systems
Employees
Work Plans
Business Participants Tier
Work Processes Tier
Data Resources Tier
Business Services Tier
-BPT-
-WPT-
-BST-
-DRT-
Figure 8: 4-Tier-Architecture of an enterprise (SOA).
Figure 9 shows an enterprise represented in an
entirely object-oriented way. On the right,
implementation aspects can be found; the right side
lists the specific details of the information
technology available for implementation today. We
are therefore only talking about a “concretion in the
large”. “IT and solution architects”, “integration
developers” and “deployment managers” must be
able to deliver this concretion for the enterprises
(domains) that use information technology
(Jablonski et al. 2004).
Communication
Class
Application-Server
DB-Server
Web-Server
Client
EJB and
J2EE, etc.
EJB, WSXL,
Apache, etc.
4.
3.
2.
1.
PC‘s, control devices, various instruments
Presentation Class
Procedural
Classes
Data
Classes
Conceptual Schema
Class
(Object-)
Relational DBMS
HTML,
Java(Script),
Ajax, etc.
Communication
Class
Application-Server
DB-Server
Web-Server
Client
EJB and
J2EE, etc.
EJB, WSXL,
Apache, etc.
4.
3.
2.
1.
PC‘s, control devices, various instruments
Presentation Class
Procedural
Classes
Data
Classes
Conceptual Schema
Class
(Object-)
Relational DBMS
HTML,
Java(Script),
Ajax, etc.
Figure 9: Entirely object oriented concretion of SOA.
“Code development”, which is of course also
important, in particular from the point of view of the
“service and solution testers” on site, is currently
done in so-called “low-wage countries” by well-
trained people (near and offshoring). In
complementation to a “concretion in the large”, we
are now talking about a “concretion in the small.”
5 DYNAMIC SUPPORT AND
OPTIMIZATION OF WORK
PROCESSES
For the dynamic management of application systems
(see figure 8), it is necessary to create and use a
meta-information system whose most important part
is the repository system (Ortner 1999) as for
example described by (Berbner et al. 2007). In
accordance to the much-noted work “The Quest for
Resilience” by Hamel and Välikangas (2003), future
enterprise networks will be implemented as elastic
ecosystems (Corallo et al. 2007) built from
components of different categories. These systems
must be assembled in the best possible way, thereby
facilitating the systems to respond, possibly even
self-actingly, to changing situations.
The ever changing job design (e.g. due to
product changes) and work organization is crucial to
this approach. This is done considering
a) the aspects: optimized processes, best possible
employee assignment and dynamic IT-support
(e.g. IT-services), as well as
b) the fact that some of the jobs that are part of
these processes, are performed by employees
who come from everywhere, or respectively,
the jobs are done where personnel is available
at low cost.
Assignment-neutral Organized
Schema Base
(IT-Services and HB-Services)
Heterogeneity of Hardware,
Operating Systems and
Applications
Frequently changing
(Business/Work) Processes
including Outsourcing and Offshoring
Variable Number of „Actors“
(natural or artificial)
Large-scale Distributed
Systems (e.g. Internet)
IT: Information Technology
Work Plans
HB: Human based
Accounting Schema Reporting Schema
Assignment-neutral Organized
Schema Base
(IT-Services and HB-Services)
Heterogeneity of Hardware,
Operating Systems and
Applications
Frequently changing
(Business/Work) Processes
including Outsourcing and Offshoring
Variable Number of „Actors“
(natural or artificial)
Large-scale Distributed
Systems (e.g. Internet)
IT: Information Technology
Work Plans
HB: Human based
Accounting Schema Reporting Schema
Figure 10: Labor as a product.
In this regard, organizing potential assignments
for employees in work plans and establishing a
global work base (see figure 10) is exceedingly
relevant. Such a database allows neutral
(assignment-free) storage and maintenance. It could
contain the IT-services (data and program schemas)
that are used anywhere in the world as program-
technological means (to work plans) for work in
those processes. This way, an enterprise’s IT-
department organizes and controls the company’s
work processes worldwide in division of labor and
dynamically using the Internet.
The protruding innovation of SOA is the
extension of the concept of application systems by
work and organizational processes of enterprises.
This makes organization theory as it is found in
Business and Social Sciences, the Engineering
disciplines or in Enterprise Engineering an
ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering
96
“integral”, that is an interdisciplinary part, of
Applied Computer Science. And this in a way that
has not been seen in previous years.
Concepts and institutions like the German
REFA-Association for Work Design or Methods-
Time-Measurement (MTM) founded in 1924 (These
are systems for time allotment that have been used in
Sweden as of 1950, in Switzerland since 1957 and in
Germany since 1960) suddenly constitute a field of
activity and provide IT-businesses and enterprises
worldwide with the knowledge that information and
computing scientists possess. Due to Ubiquitous
Computing, however, this also affects the courses of
study of Enterprise Engineering, Business and Social
Sciences, Mechanical Engineering, Electrical
Engineering or Civil Engineering, as all of them are
concerned with work science and process
organization.
The following is a list of typical issues in
optimization as they were recently elaborated by a
student team of the TU Darmstadt at the Bitkom
competition “Best Process Architecture” (Ghani et
al. 2007).
Parallelization: Operations that are independent
of each other must run in parallel and thereby
shorten the overall process duration.
Optimization of single processes: In addition,
we must analyze each process individually to
make improvements.
Integration: Existing systems are integrated
seamlessly in the new architecture so that the
available resources can be used efficiently and
effectively.
Elimination of information deficits: The
interfaces between operations are analyzed
thoroughly so that the expected input or output
will be found at the right time in the right
place.
Reorganization or sequence optimization:
Process analysis takes into account an increase
in efficiency due to reorganization of the order
of single operations.
Outsourcing: It is considered an alternative to
outsource single processes, especially
maintenance activities at the customer’s site,
to external service providers.
Integration: It is necessary to systematically
analyze the overall process for operations that
belong together and can therefore be
considered a unit.
Elimination: During process analysis those
operations must be eliminated that are useless
or do not contribute beneficially to the process
result.
Acceleration: Specific measures for shortening
the overall process duration are vital, but not
at the expense of quality and cost.
Introduction of additional test steps: To ensure
higher quality, it is useful to integrate
additional steps for checking the process.
From the perspective of an employee, there are three
possibilities to be considered when setting out to
optimize work processes using IT:
to reduce people’s workload through
automation (resource: “software”)
to support human work as for example using
interactive applications (resources: “software”
and “knowledge”), or
to improve people’s work qualifications
(resource: “knowledge”)
Industrialization and automation were so
successful in the previous decades that it is very
advisable to revert our efforts with respect to the
listing above. With globalization in mind as well as
taking into consideration our worldwide division of
labor, we should “invest much more in education
and as little as possible in further automation
efforts.” Technological progress cannot be stopped,
but a world which is becoming increasingly
compact, can only cope with progress, if it is flanked
by human education.
6 OUTLOOK
In Applied Computer Science, from a global
standpoint, service-oriented architectures constitute
a new paradigm, but do not result in a paradigm
shift. Managing data and managing processes are
complementary and lead to entirely new job
descriptions. In the expert languages of globally
interacting IT-enterprises these new professions are
called:
IT-Architect
Business Analyst
Application Developer
Service and Solution Tester
Software Developer
Deployment Manager
Integration Developer
Solution Architect
Code Developer
etc.
Nevertheless, people, who perform these jobs
throughout the world, have the least say in who
performs which kind of work when and where.
PROCESS-CENTRIC ENTERPRISE MODELING & MANAGEMENT (ProCEM®)
97
There is nothing more important for our survival
than that the humanities take up the challenge to
newly enter in a process of enlightenment. Logic,
Mathematics, Linguistics and Computer Science, for
example, are studies of the humanities. “Normative
Logic and Ethics” (Lorenzen 1984) as well as their
advancement to an “Encyclopedia Philosophy and
Philosophy of Science” (Mittelstraß 1996) provide
us with the necessary fundamental education and
terminology, in the sense of a Universal Literacy, to
fulfill this task.
Therefore, we appeal for constructive computer
sciences (Mittelstraß 1996) to become basic
education for all citizens. As a matter of course, this
basic education should be graded and differentiated
into interdisciplinary (rather universities) and
infradisciplinary (rather schools) knowledge.
The root of the matter is teaching a disciplined use
of language.
Anyone who is a democrat and who is interested
in participating in remodeling our pluralistic
democracies into republics with a “plurality-
tolerating form of life” (Lorenzen 1994) all over the
world is well-advised to try this in a language-
critical way. This form of life is characterized by the
fact that it teaches people how they can think
correctly instead of teaching them what they should
think. – Parlemus!
REFERENCES
Berbner, R. et al., 2007. Management of Service-oriented
Architecture (SoA)-based Application Systems. In
Enterprise Modelling and Information Systems
Architectures, vol. 2, No. 1, pp. 14-25.
Cockburn, A., 2001. Writing Effective Use Cases,
Addison-Wesley, Boston, MA.
Corallo, A., Passiante, G. & Prencipe, A., 2007. Digital
Business Ecosystems, Edward Elgar Publishing,
Cheltenham.
Ghani, H. et al., 2007. Concept for the BITKOM
University Challenge 2007 “Best Process
Architecture”. http://www.bitkom.org.
Grollius, T., Lonthoff, J. & Ortner, E., 2007.
Softwareindustrialisierung durch Komponenten-
orientierung und Arbeitsteilung. In HMD-Praxis der
Wirtschaftsinformatik, vol. 256, pp. 37-45.
Hamel, G. & Välikangas, L., 2003. The Quest for
Resilience. In Harvard Business Review, Sept. 2003.
Jablonski, S., Petrov, I., Meiler, Ch. & Mayer, U.. Guide
to Web Application and Platform Architectures.
Springer Verlag. Berlin.
Lehmann, F.R., 1999. Fachlicher Entwurf von Workflow-
Management-Anwendungen, B.G. Teubner Verlagsge-
sellschaft, Stuttgart, Leipzig.
Lorenzen, P., 1984. Normative Logic and Ethics, B.I.-
Wissenschaftsverlag, Zurich, 2nd annottated edn.
Lorenzen, P., 1994. Konstruktivismus. Journal for
General Philosophy of Science, vol. 25, no. 1, pp. 125-
133.
Mittelstraß, J., 1989. Der Flug der Eule – Von der
Vernunft der Wissenschaft und der Aufgabe der
Philosophie, Suhrkamp Verlag, Frankfurt.
Mittelstraß, J. (ed.), 1996. Enzyklopädie Philosophie und
Wissenschaftstheorie, J.B. Metzler Verlag, vol. 1
(1980), vol. 2 (1984), vol. 3 (1995), vol. 4 (1996),
Stuttgart, Weimar.
Nussbaum, D., Ortner, E., Scheele, S. & Sternhuber, S.,
2007. Discussion of the Interaction Concept focusing
on Application Systems. In Proceedings of the IEEE
International Conference on Web Intelligence 2007. In
press.
Oberweis, A. & Broy, M., 2007: Informatiker disputieren
über Anwendungsnähe der Disziplinen. In Computer
Zeitung, no. 29, Monday, 16.07.2007.
Ortner, E., 1997. Methodenneutraler Fachentwurf – Zu
den Grundlagen einer anwendungsorientierten
Informatik, B.G. Teubner Verlagsgesellschaft,
Stuttgart, Leipzig.
Ortner, E., 1999. Repository Systeme, Teil 1:
Mehrstufigkeit und Entwicklungsumgebung,
Repository Systeme, Teil 2: Aufbau und Betrieb eines
Entwicklungsrepositoriums. In Informatik-Spektrum,
vol. 22, no. 4, pp. 235-251 resp. vol. 22, no. 9, pp.
351-363.
Schienmann, B., 1997. Objektorientierter Fachentwurf –
Ein terminologiebasierter Ansatz für die Konstruktion
von Anwendungssystemen. B.G. Teubner Verlags-
gesellschaft, Stuttgart, Leipzig.
Wedekind, H. & Ortner, E., 1980. Systematisches
Konstruieren von Datenbankanwendungen – Zur
Methodologie der Angewandten Informatik, Carl
Hanser Verlag, Munich.
ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering
98