| Software crisis |
|---|
In the late 1960s the third generation computer hardware became available. These machines were orders of magnitude more powerful than previous generations. Their power made large applications feasible. The implementation of these applications required large software systems to be built. Initial experience showed that existing methods of software development were inadequate. Techniques applicable to small systems could not be scaled up. Major projects were late, cost much more than originally planned, were unreliable, difficult to maintain and performed poorly. Software development was in a crisis situation. Now, 40 years later, the “software crisis” is still with us. There is still a need for better tools, techniques and methods. With the increasing amount of technical possibilities, software development has become an even more difficult task. The arrival of PCs has led to our present situation where many more people are involved in software development and some of them are repeating the mistakes made by software engineers in the early years of the “software crisis”. |
| Monolithic systems |
One of the fundamental lessons that software history has taught us is: Don’t build monolithic applications. When building a business application roughly two ingredients can be distinguished:
Experience shows that many software development methods result in systems which have no clear separation between plumbing level and business level. Calls to the database, details of sending messages over a network, and showing new windows are sitting in between business calculations, business rules and business data. The result is called a “monolithic system”. Long-lifetime software is subject to regular change. Making changes in one part of a monolithic system requires a thorough knowledge and understanding of both plumbing and business. Small adaptations can have implications for the reliability and efficiency of the system, so monolithic systems maintenance demands high software technology skills, resulting in high costs. Rebuilding the entire system is often easier and less expensive than changing the original system. Think of issues like “year 2000” and the Euro. Another maintenance issue is the need for systems integration. What if system A needs data from system B, or system C wants to use system D to perform some business processing? Sometimes the best solution is to get rid of all systems and buy one new system integrating all necessary processes. |
| Techniques in use |
Mainframes They may seem to be "from the past", but still, the mainframe spirit is very much alive. The advantage mainframes brought us was the way in which all business critical programs and data are safely situated in one physical spot, and have multiple users interact with these systems by means of terminal sessions. The last decade has shown a strong downsize trend towards PCs. This led to greater heterogeneity in software systems and networks, leading to integration difficulties and extra management and maintenance issues. Many companies have decided to turn back to this period by limiting PC use and returning to the mainframe approach. Client/Server model The client-server model offers a means to balance work between client workstations and the server. Letting client workstations perform more tasks is called the “thick client” approach, the reverse process results in “thin clients”. Whichever balance is chosen, technical difficulties remain the same. Client/Server as such doesn’t solve anything. RAD / 4GL tools Rapid Application Development (RAD) tools and fourth generation languages (4GLs) were originally meant for use in prototyping. Many of these tools have taken on the role of system development tools. The typical RAD / 4GL tool (Clipper, Visual Basic, Delphi, etc.) is built around a database facility and offers a database query language, a report generation package and a screen painter package to assist with screen layout design. For some classes of relatively small application, a prototyping approach can supplant the conventional models for systems development. When building large software systems using RAD / 4GL the usual monolithic systems appear. The user interface oriented approach forces the developer to combine “plumbing” with business. |
| Value chain: The need for a way out |
1950s The early application developer used to be in absolute control of the whole machine. Paper tape reader, printer, card puncher and console were controlled by the instructions provided by the operator. Only one job could be run at a time, and the operator would set the machine in motion by pressing the “start” button. 99 percent of the software consisted of “plumbing”. 1960s Operating systems were invented to enable the use of devices by multiple programs concurrently, at the same time hiding some of the plumbing details. To load a new program, store a file, or send characters to a printer, was no longer a great effort. The technical advance made larger software systems feasible. At the same time software complexity started to increase. This cycle has been repeated a number of times. 1970s Interactive terminal systems appeared with their command line interfaces (UNIX, DOS). The first windowed graphical user interfaces (GUIs) were constructed, which was a painful task for a programmer who had to know everything about drawing windows and orientation of the cursor on the screen. Above all, two programs could not share one screen. 1980s - today Runtime services were developed to take care of GUI details: drawing multiple windows, enabling several programs to share one GUI screen (Windows, X-Windows, Presentation Manager). All steps in this chain have one thing in common: offering new business solution visions through technical advance. All these steps have resulted in a situation where software complexity has reached a dramatic level. Although state of the art tools have become available to assist in the complex task of software development, a way out of the “software crisis” has not been offered. Building large software systems is still as difficult as it ever was. |
| Architectural basis |
|---|
To relieve software development of the difficulties attached to increasing complexity, we need to reinvent the way we build software systems. Let’s start with a comparison. When building a large block of flats we do not start building right away. Before the first bricklayers appear a lot of work is done. First the functional requirements of the building are gathered: what will the building be used for? how big is the spot where it should appear? how many people need to live or work in the building? how much space will each one require? Then the non-functional requirements are to be made visible: what is the budget? what style should the building have? Then the technical architects appear. They use all gathered input to work out a plan to be used by the construction company. Working according to this plan foundations are laid, concrete is poured, bricklayers, carpenters and steel construction workers apply their materials and tools. It’s obvious that the architect plays an important part. Without an architecture, the craftsmen cannot realise the project. When building a complex software system virtually the same steps apply. However, many of the current software development systems lack a decent technical architecture, if any. This often results in monolithic systems, read: disaster. Not having any technical architecture as a basis for a software implementation is like having a group of carpenters and bricklayers building a house having a raw outline only. The complexity of the building will be equivalent to the amount of problems the bricklayers will face. From a certain level of complexity the bricklayers will not be able to create anything useful at all. What is needed is an architecture. |
| System classification: Which technical architectures apply |
Information Technology entails a broad range of problem areas. Business Information Systems, Expert Systems, Real-Time Systems, Computer Operating Systems, Computer Graphics, etc. All these problem areas have their own characteristics. These differences require different technical architectures. For instance, a weather forecasting application will differ significantly from a relation management system, and so will their underlying architectures. Therefore, it is important to classify each system and to determine a solution adequate for that specific class. The ultimate solution will be derived from all functional and non-functional requirements. The first step towards this solution will be the definition of a technical architecture that most suits the requirements. This will provide a firm foundation for the rest of the project. |
| Class of technical architectures for a class of systems: The Technical Meta Architecture |
A technical meta architecture is a description of characteristics that will serve as a solution for a particular problem class. Each system belonging to the problem class needs a technical architecture with some or all characteristics of the technical meta architecture. In our research we’ve focused on the class of systems known as Business Information Systems. We have defined the technical meta architecture for Business Information Systems by summing up their joint requirements:
These requirements seem to dictate a wide range of architectures. The amount of work involved to build all different settings of Business Information Systems must be enormous. Is there a way out? |
| Ultimate Business Information System (UBizz) Architecture |
Our challenge was to design the ultimate architecture that would fit all Business Information Systems defined by the requirements.
If an architecture could be implemented which would fill in all these requirements, this would be a means to reduce the “plumbing level” work to doing it only once. The result would be a Business Information System which would suite Enterprise Scaled Business Information Systems. And so we did. |
| Configuring UBizz for business: Lazy or creative? |
If a person is laborious for years now in the area of Business Information Systems he or she should be tremendously bored now by doing the same “plumbing” job over and over again. Many decades of software development have passed without significantly changing the way of programming. In each project the same complex problems needed to be solved again. Instead of just having to concentrate on the business domain, most of the time is consumed in solving technical issues. But here we catch the phrase: “concentrate on the business domain”. We removed the plumbing level from the business solution developer’s domain. This was accomplished by solving all plumbing aspects in frameworks. What remains is a system that has a Programming Model which is equivalent to business modelling. A business model is a map of the user’s conceptual model of the business domain, which is created using standard business modelling techniques. For UBizz we use modern Object Oriented Analysis & Design methods. The moment we have started business modelling, the Ultimate Business Information System is ready for production. Application programmers are no longer needed. When the consultants leave, the entire system is ready. |
| From Architecture to UBizz Engine |
To accomplish an implementation of an architecture having the characteristics as described above, the implementation needs to fulfil the “patterns” loose coupling and separation of concerns to the utmost extent. If this is unconditionally carried through, the resulting implementation will be multi-tiered, layered, and based on objects. In other words, the result will be a set of platform independent frameworks, fully supporting all required characteristics. The UBizz Engine needs only to be fed with a business model to become a fully blown Enterprise Scaled Business Information System. |
| Business Modelling |
The Business Modelling phase will have to supply a complete model in a predefined form. First of all, the model needs to be based on Business Objects. This means that all modern Object Oriented Analysis and Design methods can be used to create this business model consisting of:
At any stage in the modelling and design process the (intermediate and incomplete) Business Objects could be fed to the UBizz Engine. This makes it possible to continuously monitor the progress of the project and to validate at any time the correctness of the model. From the moment the first Business Object has been delivered, a “real” Business Information System exists. At any time could be decided to enrol this (intermediate) Business Information System into the production process, because it is directly fully functional. Deployment of the system can be changed dynamically at runtime. Any type of client-server model can be arbitrarily chosen and combined. New users can be defined at any time and their workplace can be fully customised to their role in the organisation. Security rules can be assigned to groups of users or specific users. |
From the start of the company Pyrrho has focused on the implementation of the UBizz architecture. By creating several business implementations based on UBizz, Pyrrho has been able to constantly improve and extend UBizz. This has resulted in proven field technology for both architecture and the created business applications. |
| How does it work |
|---|
| Business applications based on UBizz are very flexible. Therefore, it is not very important to have the scope of the project very well determined from the beginning.
The UBizz development process looks totally different from the traditional waterfall approaches. |
| UBizz features |
The UBizz architecture incorporates a powerful set of building blocks.
|
| Example: UBizz Financial |
| UBizz Financial is an ERP solution for Financial Service Providers. After many years of continuously expanding its scope boundaries we still haven’t finished.
Currently we are adding the support for real-estate businesses to this system. To have a good understanding with the domain experts, the first modeling steps will be based on the description of Use Cases. Directly after the first session, a start with the next phase could be made: translating the Use Cases into a Business Object model. After the first objects have been created, a fully operational system can be generated. |
| Example: UBizz Process Integrator |
| Philips management commented on Pyrrho’s support contract proposal: Guys, one of the problems to base our budget for support on this system is that we never have any need for support. You’ve built a system that is too good.
If the system is fully operational it is not a fixed creature but an organism that can be subject to changes and extensions. It can easily be adjusted to growing business needs without affecting the robustness of the system. |
| Example: UBizz Trial Management |
| Philips Display Components have used ‘Use Cases’ to describe a new application called Trial Management.
For political reasons they had chosen to let their Brazil factory take care of the User Interface part. Pyrrho needed this User Interface to be able to test our modules, and was facing a six months waiting period. Within four hours we built our own system from the ‘Use Cases’ and could then immediately start full testing. Eventually Philips Brazil used this UBizz-created system too, to validate their own User Interface. Because every necessary component of the application is generated and provided by our architecture, deployment of the system can start from the moment any useful user functions have been modelled. This is not only important for fast system delivery, but even more so for immediate feedback from users. How the system eventually satisfies the business needs can at best be extracted from use in practice. UBizz is based on components that have proven their quality and stability for years now. Due to the high level modelling and re-usable components, maintenance and support efforts are kept to a minimum. |
| Example: Pyrrho consists of three people with two of them being involved in system R&D |
| These two persons have successfully developed the UBizz architecture, and implemented several Business Applications based on UBizz.
At the same time these two have to take care of all support requests. UBizz Financial is currently Pyrrho’s main income stream with more than a thousand office employees using it every day. However, the main effort of the two developers is still focused on creating new features instead of solving endless lists of outstanding problems. |
| Conclusion |
Building Business Information Systems has been reduced now to producing a business model by uncoupling all dimensions in the technical architecture. This makes sure that users and analysts never have to deal again with technical complexity in any situation. The role of a programmer has become superfluous and the application builders only have to concentrate on the business domain. The result will be a radical change in software development. The project duration will be minimised and the quality maximised. The objective of having flexible systems being able to react on market changes, integration of new business domains, incorporation of new technologies, and scalability with business growth has finally been achieved. |