of the development processes are case based
Because ICONPARC is manufacturer (Independent Software Vendor) and integrator. The ICONPARC B2X E-Business Suite is based on a multi-layer architecture:
This results in different development methods according to layers:
Theoretically, the multi-layer architecture of a basic technology prevents its integrators (agencies, IT service providers, ...) from working on the same code as the manufacturer of the basic software, consisting of application server and development framework with library and application modules. In practice, however, the aspects described below make the interaction between separate manufacturers and integrators problematic.
Even though the different levels of a multi-layer architecture largely ensure a clean separation of the areas of responsibility (manufacturer and integrator), there are areas of code that are processed by both sides - with different objectives: This is where a first source of danger lies for the long-term stability of an application.
The second type of dangerous place for cooperation between manufacturers and integrators is in all those situations where the same code is not worked on overlapping, but where there are transfer interfaces between the parties involved. These are explicit APIs on the one hand, and design patterns in the code on the other, which are regarded as established - until the manufacturer changes them (usually without announcement) in a release. It is highly probable that this approach will lead to a situation where the basic software developed by the manufacturer and the application individualization contributed by the integrator do not fit together permanently.
The software and implementation methodology of ICONPARC does not have exactly these breaking points, because we as manufacturer and integrator act in the interest of the greatest possible compatibility: Therefore, our solutions are also stable in the long term, especially with regard to the interaction of basic technology, framework and highly individualized application components.
Development methodology according to the Stacey Matrix
One Size fits all? Every fashion fan knows that only the right size of a garment is really fun. The situation is similar in software development: challenges at different levels can best be mastered with the appropriate development methods. In addition to the individual levels of the multi-layer architecture of our technology (each with a standardized scope of services), the project business (with a customer-specific, individualized approach) in particular requires a different approach to ensure the best results. In this section, we introduce you to the development methods we use - and explain why which methodology is particularly suitable for the respective task.
The figure shows how the optimum development methodology can be derived from the degree of clarity of the requirements on the one hand and the technical implementation on the other. In this so-called Stacey Matrix, all methods relevant to us are presented - these are explained in the following sections. As a general rule, the more unclear the requirements and implementation paths are, the better agile methods are suited.
Design Thinking
Equally unclear requirements and implementation methods mean that we operate in an unstructured environment. What sounds frightening to computer scientists is a common scenario for creative people and design phases. It is only gradually that new order emerges from the initial chaos. With the help of Design Thinking, FRONTENDs in particular can be created that offer the best user experience (UX := User Experience) and make it available to users on all common end devices - using Full Responsive Design. Once a FRONTEND has been designed using Photoshop, we develop a prototype in HTML/CSS/JS on this basis, which makes the operating concept tangible and is refined iteratively in dialogue with the customer.
Waterfall
Requirements and technical implementation are relatively clear: This is about processes - whether in FRONTEND or BACKEND - which have already been described in a structured way in a technical specification. Proven paths are followed during implementation, so that few surprises are to be expected.
CIP - Continuous Improvement Process
In small steps, continuous improvements are achieved within a clearly defined framework. This approach is particularly suitable for optimizing the application server level (IPACT), where downward compatibility plays a decisive role.
Kanban
Now we move to the Library Layer, which is by far the largest part of the ICONPARC E-Business Framework. This is about optimizing processing times and quickly identifying bottlenecks. In particular, we want to prevent several developers from working hand in hand at the same point within the large library, so that they do not get into each other's enclosures or can work on as much space as possible in parallel. Since it can never be 100% ruled out that different developers (with different objectives) will work at one and the same place in the library, another method, which can be easily combined with the Kanban approach, helps to decouple parallel work from each other: complex extensions, which potentially have many repercussions for other places in the code, can be outsourced to a so-called branch. There, functionalities can be built and tested in peace - even by several developers - before these massive changes are finally merged back into the main development path (trunk).
Scrum
In perhaps the most popular agile method, the customer is hardly involved. Rather, it is an integrative process between developers. The E-Business Framework, which ICONPARC has been developing for about 26 years, is subject to a process of constant optimization and expansion, without it being completely clear where the journey is heading. A new intermediate result is created with each step: On the basis of these intermediate results, missing requirements and technical solutions can be found more efficiently than through an abstract clarification phase. At Scrum, planning develops iteratively and incrementally. The empirical improvement is based on three pillars:
- Transparency: The progress of a project is described regularly and transparently for all participants.
- Review: Project results and functionalities are regularly delivered and evaluated.
- Adjustment: Requirements for the project, plans and procedures are adjusted continuously and in detail. Using Scrum does not reduce the complexity of the task. Through structuring in the form of smaller and less complex increments, the complexity associated with the given task can be reduced to a minimum.
The basic layers are identical on all development, test & production systems - updates are made on a weekly basis.
- Framework
- Library
- ICONPARC Application-Server IPACT (based on JAVA V2164-Bit)
The different software layers are
- FRONTEND
- BACKEND
- Modul-Layer
- Framework
- Library
- ICONPARC Application-Server IPACT (based on JAVA V2164-Bit)
The layers that are customized and thus integrated into customer projects are
- FRONTEND
- BACKEND
- Modul-Layer
Derived from this, we work with two conceptually different Ticket-Systems which have also been developed by us and are constantly enriched with new features.
Which is accessible to customers and developers
Which is only available to developers.
