The expectations of IT tools have grown dramatically. Nowadays a company wants all its processes (planing, production, controlling,...) to be supported by tools. Big parts of the business processes of a company are caste nowadays into IT applications. The design of business processes and IT applications supporting them interact. The success of companies like SAP, I2, BAAN, etc. show that the demand in this area is even going on. In Supply Chain Management the processes of several companies building a supply chain are connected. If big companies merge often databases have to be consolidated in huge data warehouse projects. All these demands require an consistent view of business data across companies and departments and functions or applications. The concept of Business Objects arises (17). A Business Object is a component representing an item out of the business process. Examples for such items are customer, contract, product, inventory, bill or resource. Additionally an Business Object has several views for the different functions it is accessed. More and more these Business Objects are distributed on several computers (database on main server, local views or copies on local workstations and PC's). So these Business Objects are embedded in a framework controlling distribution and data consistency/ security (f.e. San Francisco TM from IBM).
Business object frameworks are a powerful tool for creating IT applications in a company or even for a whole business area (f.e. banking, insurance, steel,...). Companies selling customizable applications or development tools (f.e. SAP) using this possibility of parallel modeling of processes and applications. Not all of them are using object oriented methods. When using an object oriented approach business objects are a result of a business process reengineering activity.
The work with business objects have a lot of advantages:
One problem when reengineering processes and applications is the connection of legacy systems to the new concept. Tools for this exist.
The area of distributable objects is an interesting and wide field but will be not part of this lecture. It can be handled independently from the aspect of business object design. The field addressed here is the analysis and design of business objects.
When designing a global set of business applications a system architect is very often also a work flow designer. The applications often define what has to be done in which sequence.
Example:
Company A has a department receiving the orders from the customer. This department is still working with paper forms. The form to be filled for every order contains several sections. The first section is for the customer data, the second for the global order data such as entry date etc. and the last section contains the ordered items. Each employee of this department has his own way to fill out the forms. The most common sequence is to fill out first the item list and checking the inventory in parallel. In the next step is checking customer data and global order data and writing the acceptance letter to the customer.Now the software company X delivers a application for supporting this work. A lot of time the employees used for searching customer and inventory data in the databases. This will no be supported by the new application. So everybody hopes that order entry will be done much more efficiently than before. When working with this application the employees are very disappointed. The old workflow is not supported by the new application. On the first panel the customer must be specified or defined. Without finishing this panel the employee can not enter the items or check the inventory. This first panel takes a lot of time if a new customer has to be defined. Often the employee even must phone the customer to get detail data not contained in the order before the items can be processed. In the end the employees have the feeling the new application does not support their work.
As described in the example above the workflow of people often changes when new software is implemented. Therefore it is important to really understand the working environments and working behaviors of the users when designing software. We get an interaction of:
Design of work flows Business Process Analysis Business Process Reengineering The work of consultants and application architects grow together. Unfortunately software engineers are involved very late when business process analysis and reengineering plans are already finished. Therefore often the software designers have very few chances to discuss with the users and get a good imagination of the workflow. Another problem is that software engineers have difficulties to understand the business process and workflow descriptions created by a consultant company and the consultants have low knowledge about the technical realization of software solutions. In the future the interaction of both parts will become stronger and both parts must understand the language of the other one.
Assume we have a company called "CD Connection" selling CD's. A customer orders a number of copies of a CD. If it is available in storage it is shipped to the customer otherwise an order must be sent to the supplier of the ordered CD. With the shipment of the CD a bill is sent. Below it is shown the traditional process.
The process is very old fashioned. All communication in the company is done via paper forms. For every order received the administration completes a form and sends it to the inventory. The people in the administration department have no further information about the process of the order. Therefore the information they can give to a customer calling is very few and normally unsatisfactory. The inventory administrator collects all these forms and decides which parts are o be shipped and what to be ordered from the suppliers. When a shipment is done the finance department is informed via a form. Here the payment process is tracked. The inventory administrator has no IT tool for planning. The inventory administrator works in the company for twenty years and has an excellent experience in doing his job. He does the planning with help of his excellent intuition. The company is aware of the fact that this person will go into pension soon.
Widely used for business process modelling today is the Method of Prof. Scheer called ARIS(18). It starts from a functional view of the business process. A model consists of:
The organization chart for the company CD Connection is very simple:
ARIS uses as basis a functional decomposition of the main functions in a company:
Each Function can be described in a Process Chain containing a sequence of functions and Events.
There exist other descriptions very similiar to the process chain with various detail levels in various areas. So the whole as-is process can be described very detailed. In the end a simulation can be done of the process and bottle necks can be identified. Alternative processes can be modeled and compared with the current one.
We can model this old process by using use cases (15,16) from Jacobsson. Traditionally a use cases are used for an IT application; i.e. the use case describes how an application is used. In (15) Jacobsson tried to port use cases to business process reengineering. In (15) a use cases describing the interaction with a company are introduced. When designing architecture of a business application environment supporting most business processes in a company use cases focus on one application only will not be appropriate. So we follow here mostly the ideas of (16). In the future it might even be necessary to work with use cases focusing on a whole supply chain.
A business process model in this method consists of
The organization chart for the company CD Connection is similiar to ARIS:
Next step is to find out the actors communicating from outside with the company. In our case a customer orders for his shop CD's. Here the end user want to listen to nice music can buy the CD's later in the shop once they are delivered to the customer. CD Connection itself gets the CD's from various factories called supplier in the model.
A use case now describes the main transactions the actors do with out company. They define the behavior of the company from outside.
CD Connection has only two transactions in the nowadays process - one for each actor:
The two transactions are not totally independent. Their interaction defines the delivery time in the inventory costs. Both are important objectives to minimize. Unfortunately these two objectives work against each other. A short delivery time can normally only be achieved by having a huge inventory to prevent CD's running short in inventory when ordered. On the other hand if the inventory is kept small the chance that a full purchase transaction must run between order and delivery is very high. So the average delivery time will increase. But here exactly lies the problem CD Connection wants to solve.
For a better understanding transactions can be decomposed. There exist two relations between transactions.
The transaction 'buy CD' is processed by two subsequent transactions 'order' and 'ship & bill'. So 'buy CD' uses these two transactions. CD Connection would also sell cassettes there might exist an additional transaction 'buy cassette' having a common part 'buy' together with 'buy CD'. In this case 'buy CD' and 'buy cassette' extend the transaction 'buy'. This is comparable to subtyping. This is not the traditional definition of the extends-relation in (16). But in a lot of projects a subtyping or inheritance relation was found more useful than the original extends relation defined by Jacobsson.
The next step is to describe how the transactions are implemented internally in the company. This is done via the object model. In the object model the relations should be described and not the sequence of action. An object model used the following object and relation types:
The object models of the various transactions look as follows:
For every order exactly one delivery request form is created. Therefore the delivery request is not necessary in the process. The order itself would be sufficient to provide all information necessary for delivery. A delivery request might be effective if orders are sorted or consolidated in a delivery request. The delivery request as created today is a view of the order provided to the inventory administrator.
The transaction Purchase CD's contains the inventory planning influencing time for delivery and inventory costs. The inventory administrator must track and analyze stock level and delivery requests and from this decide which CD's have to be ordered.
For the critical objects used we can draw a transition state diagram. This is especially done for an object having a complicated life cycle. As done below for the object 'order' having the states 'sent', 'accepted', 'procesed' and 'rejected'. The state 'rejected' can only be reached if the state 'processed' is not achievable.
Draw a state transition diagram for an euro-cheque automata.
Additional also an interaction diagram can be presented to show the workflow of a transaction. Such an interaction diagram is needed for any transaction where the time has to be minimized. Generally a workflow description is helpful for all transactions, because it is often the only one the customer understands.
Below is the interaction diagram for use case 'order':
NVA denotes non value adding activities. VA value adding activities are all activities adding something to the product ordered by the customer. Here also the paying of the bill is marked to be VA. This is not always done. But it is an activity also not removable from the process and needing resources in the company.
Of course we also have to check where the handlers occurring in the object model are located in the organization. Each handler can be realized by one or several persons. One person also can do the job of several handlers. In our example every handler is one person.
In more complicated business processes each handler has a skill profile and role is assigned. Thereafter roles are assigned to organization units and persons.
The company found that a lot of customers are dissatisfied because of long delivery times and bad customer support. So the company decided to restructure the processes. The company sees that a third transaction called 'information' has to be introduced. Customer support besides processing of customer orders was not implemented until now. The customers want information before they sent an order and want to have detailed information about the status of their orders. This request leads to the most radical change. The new installed customer support needs access to most business objects. So the old host transactions must work together with new PC software having access to all host databases. To minimize the delivery time all internal paper formulas are removed. Notifications and confirmations are done via PC in the future. Additionally the inventory administrator shall get a prognoses application to balance the inventory more efficiently.
The new use case 'information' looks as follows:
For implementing this transaction a new department will be implemented. The order handlers from the administration will be moved to the new customer support department and will need training to do their new job. Additional people will be hired when the new process is fully implemented.
The customer support will consist of persons working as information handlers in the new process and as order handlers in the transaction 'order'.
In the beginning of computer technology computers were mainly used by scientists. The industry believed computers are toys in research. A scientist worked generally alone on his program and he was the only user. Coding was done in machine code. Even an assembler was not available. The computers of this time were 'tube machines'. Working with these machines also included the finding and exchanging of defect tubes.
Before electronic computers were available in research institutions mostly women were employed doing the necessary computation work by hand. When electronic computers were introduced these human computers became the first programmers. So in the beginning of computer science software engineering was a female area.
The development of assembler languages was the first big step in software engineering. The programmers got the first abstraction tools. Variables used as abstraction from the value and storage location and macros for encapsulation of functions are available in assembler languages.
The first computers allowed no multiple user access. Therefore coordination between the programmers was necessary to organize the access times on the machine. There was little communication needed to discuss contents or interfaces of programs because everybody worked on independent programs.
In such an environment every programmer can code in her own style. The only requirements for the program are that the programmer herself must be convinced that the program is running correctly, fits into the storage of the machine and has a reasonable performance. Usability was not considered to be a problem. An amount of 128K was huge. All dirty tricks were allowed to archive the goal under these hard hardware restrictions. To save storage often self-modifying code was implemented. Nobody except the programmer herself and perhaps on other person working closely together with the programmer could read such programs.
In research this 'one-person-for-his-own' style remained the usual case for long and still exists. In industry it quickly became different.
The industry detected computer in the 60's. This was the start of the first big methodology change in software development. The industry had own expectations what software should do. In research an application was written for one project and then never used again.
In industry an application (for example finance applications) must
The first programmers in industry still produced some sort of 'Throw-Away' software. But the successor in the job had to maintain the code and normally had big problems to understand what was done there. The 'Throw-Away' software became a product with a lifecycle and additional components (documentation, distribution path, service, life cycle).
Software as a product might include the following:
Therefore development processes were developed. They define:
In the 70's the first programming libraries where developed (for example for solving linear equations, statistics etc.). This sort of software had to fulfill additional requirements:
These requirements in software development lead to structured programming and the waterfall process.
In industrial development the waterfall process was developed. The process from analysis to shipment was decomposed into steps. Each step was ends with a validation to assure quality. The people defined this process had the dream that the specification will be finished before the design starts and that during the design phase the developer can structure everything correctly without caring about details. If in later steps corrections have to be done on results of previous steps they were declared as 'errors' and tracked.
In reality a specification never keeps stable during the implementation phase of a project. Often during the work on the details in the coding phase additional properties of data types become known and lead to changes in the design. Therefore in praxis a pure waterfall process is difficult to handle. But this process is easy to track for a project manager. It only has to be checked, if the planned steps of the project are finished in time. But this planning security is treacherous. A lot of risk of the project is put into the last steps coding and testing. The test phase in a waterfall process often is as long as all previous steps together.
On the other hand the applications developed in the 70's were quite homogeneous. Most of them were transactions in COBOL or Assembler on a host system. User interfaces were minimal. Before 1975 terminals were seldom used. All input was done via punch cards and tapes. Output media were printer and tapes. Therefore the application developers had not to worry about complicated user interfaces and the applications were far less complex than nowadays.
The functional model used in structured programming was represented by:
The specification phase is the first phase in the waterfall process. Target is to describe all important properties of the system to be delivered. At this stage the system must be described from the customer view. The specification defines the deliverables of the system and often is base for the contract.
This phase might consist out of several stages. For huge projects several teams are working on two or three stages might be necessary. In this phase the system is subdivided into subsystems or components to be handled by different teams. The teams must agree on interfaces between the components.
Each team works independent from the other teams in the following stages. The component to be developed by the team is subdivided into modules to be handled by one developer.
Each developer works mainly on his own until the final test phases start. The algorithms and detailed data structures needed to implement the modules are specified in this stage. Parallel to this the test department (if existent) can already design the test environment. The test environment is developed based on the specifications of the components.
In this phase the code is tested, documents reviewed and found problems fixed. This is a validation step in itself. According to the size of the project the test devises into one or more levels (normally one for each design level). Normally the developer does the first testing level (function test) himself. When more and more components and subsystems must be integrated the tests are done outside the development department.
The system is delivered to the customer(s). Now the customer has to do the last validation of the product. In some cases the customer is also involved in the test phase by getting a 'Beta' version of the system.
All the steps above are done in the sequence describes above. Normally the analysis phase for the next version/ product does not start after shipment of the previous version but during implementation or test phase. The last test phases and high level design normally run in parallel.
Small teams or often one person alone developed the first applications in industry. Therefore team structure and communication were problems of minor importance.
With OO methods a new process was defined. Prototyping was done in more and more projects. In the old waterfall process a design correction done after coding was defined as a fault and measured like this. The development environments changed extremely in the 80's. The computers were much more powerful and the expectations of the customers increased even more. Applications were much more complicated. Nowadays every office application on a PC works with a graphical user interface and a database. Only very few development teams can start from scratch but have to extend old systems or at least use their interfaces. So the design of each system is done on the base of pre-assumptions about existing systems or customer input which are normally incomplete. Therefore the design of an application bases on incomplete information and more an approximate than a reliable description of the items to be implemented.
This gives a total different view on changes to be done after coding started. Here no faults are corrected but new insights are evaluated. Which does not mean that ordinary faults do not occur too. In principle the iterative process is a better description of the working style the development teams really did when working with the waterfall process. The whole testing phase in the waterfall process contained the 2nd to last iteration you might say. Actually test phases were mostly longer than design and coding.
Measured with the new process definition most time is spent in design and consolidation phases. Coding and testing time becomes shorter. This partially is effected by the new measurement (corrections or extensions of design where counted as "error correction time" during test in the old process) and partially by new more powerful programming environments (class libraries, code generators).
For the project managers the change to this new process is difficult. When teams started to switch to this new process obstructions from management had to be overthrown. The iterative process has no fixed number of steps known from the beginning of the project. This process is more flexible and therefore more difficult to track. Because of this managers believe that the iterative process includes more risk than the waterfall process. But this is an illusion. The iterative process risks are visible earlier than in the waterfall process. If a hole in the design is found an extra prototype step might be inserted in the middle of the project. Then extra resources needed for the project become known quite early in the project and delays can be handled with lower costs. In the waterfall process it might prolong the test phase endlessly. Delays in the last phases of a project are the most expensive ones.
The object/class model is described by graphics and diagrams showing class /object relations.
In this phase requirements of the system to be developed are defined. Often a consulting project analyzing the business process has been done before or will be part of this phase. All methods described in the section
Do not to use traditional OO notation in this phase but free style and or use case/ ARIS models. Try to describe the problem domain in the language of the customer. From this description first candidates for classes and relations are archived.
If necessary prototype the user interfaces. The customer can verify this. Prototyping is a popular method of verifying and analyzing requirements for database applications.
Verification of documents and prototype by customer.
Example of a rough domain analysis:
In a document all planning rules and detailed definitions would be described. Additionally all abstractions necessary to work with the model will be described.
A step forward to design level our model would look as follows:
Here the whole project team still works together.
In this phase the first auxiliary classes are modeled:
During this phase of a prototype every developer works on his work item.
The last prototype is the code to be shipped to the customer.