All customers receive an overview of all installed updates including graphically displayed time histories via the BACKEND. In addition, numerous metrics for the respective Live System are visualized.

Updates and enhancements can be viewed at any time and from anywhere via our BACKEND

Why are UPDATES vital?

Modernization

The viewing habits through mobile surfing on smartphones and tablets have changed exponentially in recent years! The technical requirements are also constantly growing and changing, e.g. due to new web browsers on PCs and mobile devices, changed search engine specifications and current security requirements.

Modernization is a continuous process, which technically means that the backbone of the software (the technology base, the framework) must be continuously improved and further developed. A background noise of updates, which is financed by the monthly update lump sum.

Project progress

As an operator, a successful platform will be continually expanded and improved in order to maintain or improve the high level of customer orientation, individualisation and comfort.
On the one hand you will want to adapt them to modern viewing habits (e.g. autocompletion makes suggestions, optical redesign), on the other hand you will learn in dialogue with your customers and improve things or add functions.

Project development takes place technically in stages of sub-projects.

Overall picture

From a technical point of view, modernization and project development are interlinked because the project functions are based on central functions or are interlinked with them. Both development processes must therefore interact continuously.

What does release management mean?

Working with "Release Management" is familiar from many ERP systems and their major providers.

 

One release per month or quarter is announced and installed via a complex upgrade, including subsequent troubleshooting.

 

This approach has led many people to the conclusion that ERP systems are "insanely complex" and "much more complex than web systems" - which is technically not the case, because a modern web trading platform can compete with an ERP system in terms of software space or complexity.

 

One applicant once put it this way:
When a release is changed, problems are created and then heroically solved.

In addition WIKIPEDIA:

"The release management has the task to reduce the risks of the interruption of business processes with configuration changes of existing systems, which are caused by badly planned or not sufficiently tested system configurations."

 

For the customer of the platform, release management means that new functions are not implemented promptly, but only with the next or even the next but one release. Release changes are often associated with downtime and high error rates.

We don't like this approach at all!

How we work

Continuous Delivery

  • The software features are continuously (daily, weekly) installed on the live systems.

  • Per month we transfer approx. 600 software features to each staging or live system.

 

In order to achieve time-critical goals in a customer project, a further development of central areas is often required at the same time. These central changes are carried out and released in coordination with the quality management team just as promptly as the function updates of the customer project. The project teams and the quality management team work hand in hand.

We are able to make agile changes, extensions and further developments and bring them to the live systems in a timely and error-free manner. Thus the systems are very up-to-date, so that future development steps or prompt changes become much easier possible. The work for the software engineers becomes more pleasant, the efficiency increases significantly.

 

Software Features

We constantly create a large number of updates ("software features"), which together represent the further development of the overall system and the respective customer project; software features are comparable to the transport orders of SAP software development..

We make this procedure possible by

the human factor

  • Quality as a living example

  • Experienced, quality-conscious employees (10-15 years in the team)

  • Interdisciplinary team, consisting exclusively of academics - computer scientists, mathematicians and engineers

  • continuous internal training

  • Actively integrated quality management team

  • Thematic specialist teams

  • Efficient cooperation through good team communication

the technology factor

  • smart practices
    • Development branches switchable as central branch
    • Automated and manual software features possible
    • Routinely roll out non-downward compatible changes
    • Enable complex migrations through live branches

  • Automatic test procedures
    • Automated integrity testing
    • Continuous software operation on the development system via selenium-based system

 

  • multidimensional quality measures
    • Organized and documented "Hey-Joe" support for specialists
    • Internal monitoring and timely intervention
    • Extensive training of new employees
    • Continuous further development of joint process models
    • Continuous further development of the tools


  • specialized ticket and workflow system
    • Customers and developers work on the same ticket platform
    • High integration of the development tools with the ticket system


  • powerful development tools
    • Own tools for data synchronisation
    • Own metamodel for database modeling
    • Eclipse with specialized tool integrations

Faultlessness

No procedure (Release Management vs. Continuous Delivery) can guarantee 100% error-free software. A very low error rate can only be further reduced by considerable additional effort, e.g. through multi-stage staging systems and very time-consuming testing.

This, in turn, is bought at the expense of disproportionately high costs and time as well as significant losses in agility. A Mars mission is extremely expensive and extremely unspontaneous.

 

We are of the opinion

  • that agile development at the highest quality level (i.e. with a very low error rate) is the best basis for a sustainably successful platform.
  • Our credo is: Avoid mistakes as a matter of principle. Correcting errors quickly and effectively.

  • For years, we have been continuously striving for perfection, which is reflected in a remarkably low error rate.
  • that this is also optimal for the total cost accounting of the customers

 

From this point the relevant question is:

What happens if an error occurs on a live system?

We have perfected error detection and correction over many years:

  • technical errors are recognized by us immediately and can be repaired immediately.
  • Typical response times from error occurrence to troubleshooting are 30min (frequent) - 2 hours (rare), depending on complexity.
  • Content and logical errors are usually reported by the customer via our ticket system and processed with the highest priority.

In both cases, the high topicality of the live systems helps that bug fixes can be created and transferred quickly and effectively.

 

General failures (e.g. of the customer's network infrastructure) are monitored with a modern monitoring tool.

Keyword Migration

There are extremely extensive project enhancements that are created with a team of developers over many months as a whole, and make very extensive changes. Such enormous project steps typically have to be brought to a live system via a complex migration.

 

Our goal over many years was to keep the shutdown time of the live system even shorter during a complex migration.


We find

Developing a platform is like building a new plane in a hangar. No passengers, no environmental hazards, no stress. Now imagine that this airplane then climbs into the air and is never allowed to land again. The refuelling and repairs must take place in the air!

 

Impossible?

That is exactly what we do every day. 365 days a year. Sometimes also 366 days - maintenance, refuelling, repairs and extensions take place in the air, while you as captain fly and take your customers (= passengers) with you - without you noticing us!

Of course, we could stop the plane. But this is accompanied by losses for you: Google does not find your pages any more, your customers are annoyed if they want to order right now. And what if the platform goes online again, but the shopping baskets are empty again due to the repairs (the restart)?

No downtime, impressed customers

Our procedures are so refined that we are able to bring a complex new development onto a live system and test it there, so that we are ultimately visible to the customer. 

switch to the "new version" at the push of a button

Our References
Current brochures
The Elevator Pitch:
IconParc explained in two and a half minutes


- or -

12 REASONS
Design and build your digital solution
by IconParc
What ever your digitalization project is

Talk to us.
[text.sitemap_layer in ml_comp 'content' undefined]