Coming full circle
“Solutions from vision to implementation” was the motto chosen by the organisers of the DSAG Annual Conference 2010. The event for SAP users aimed to demonstrate how system environments will change in future, where innovations can add value and how new system architectures improve the quality of products and processes.
All exciting points, especially considering the delayed launch of SAP Business ByDesign. After all, this solution was developed according to the principle of Service Oriented Architecture (SOA) – one of the doctrines of salvation intended to offer a way out of the current software crisis.
Ever since the dawn of software, users have had to wrestle with software products which leave a lot to be desired in terms of process support, ease of use and maintenance. In the days before SAP there was only individual software, which was developed specifically for the particular needs of individual companies. It took a lot of time and money to produce and users had to wait a long while for a functioning solution. Then SAP brought its standard software onto the market, both to reduce manufacturing costs and to improve software quality.
For decades, users accepted standardisation as a solution and uncomplainingly adapted their structures and processes to the requirements of the IT manufacturer. However, at the same time they also had to put a great deal of work into modifying the standard software in order to achieve a certain degree of individuality. The rollout work involved took on mammoth proportions. That’s why a change of paradigm is just as urgently needed now as the development of standard software was back in the day. More than ever before, customers are again demanding individual software solutions which can be implemented quickly and affordably and adapted easily to new requirements. Now it’s IT that needs to gear itself to companies’ existing processes – and that’s just the way it should be.
However no proof has yet emerged that the various methods such as SOA, MDA (Model Driven Architecture) or ESOA (Enterprise Service Oriented Architecture) can actually lead to a considerable improvement in the quality of products and processes. All approaches to date have failed to deliver either a shorter time to market or greater agility. Software projects that manage to stay within the specified timeframe and budget are still just notable exceptions.
There's no question that software architectures play a big part in how successful development and IT projects are. What does a system architecture need to look like though to ensure that it benefits both users and developers in equal measure? Well first and foremost it needs to be fast and flexible. The faster software can be developed, the less work a manufacturer has to do to offer a tailored solution. And the more flexible a software architecture is, the more easily processes can be customised, new functionalities can be incorporated and special customer needs can be met.
Reusability is essential here. Well thought out code that’s already written is invaluable and should be reused to significantly increase effectiveness in software development. Reusable software modules make it possible to create a new application more quickly and adapt an existing solution to the customer’s specific needs with little effort. If an architecture permits modules to be reused, the benefits are tremendous. Development can be speeded up to allow more time for mapping the processes. Plus, reusable components ensure higher quality software, as the individual modules have already undergone extensive testing. If development follows the graphical modelling method, it can take place directly and very intuitively.
Attempts to reuse software modules in line with the Lego principle are in no short supply. Endeavours to date, however, have proven unfruitful. Reusability stands and falls with the degree of integration of the individual processes. Efficiency can only really be increased if the modules work together easily. And that’s exactly what the system architecture from tangro does. The development platform works with a visual programming interface on which granular reusable software modules are graphically mounted in line with the process. There are no media gaps between modelling, the development environment and the workflow because the tangro Business Process Builder uses graphical modelling to create the application software instantly. Without interface programming, arranging the symbols graphically and linking them together is sufficient to define the flow of a process. It means that the process model is a one-to-one replication of the application, which in turn enables a rapid response to change or new requirements.
The reusability of the software modules at tangro massively increases the quality of the software. And reusability increases with the granularity of the software modules. The reusability of masks, for example, is very low, while that of mask elements is high. tangro achieves reusability of 60 to 70 percent for applications that need to be coupled with other solutions. When it comes to standalone products, such as the SaaS solution currently being developed for IT service providers, we are able to achieve virtually full reusability of almost 100 percent.
The tangro method is geared exclusively to the images and language of the company here, and not those of IT. Requirements are formulated as far as possible in business management terminology and not in UML, methods and classes. Process knowledge and a certain understanding of technical matters are still needed, of course, as the processes made up of individual modules need to be logical within themselves in order to produce a functioning application. Support is given in this respect by special process templates that bundle several process steps for common or recurring applications such as reading and saving address data. What’s more, the tangro system architecture provides its own test routines which can be used to methodically test certain processes.
Another feature of the tangro system architecture is the encapsulation of processes. This ensures that extensions have as little effect as possible on existing processes. It stabilises the software and guarantees that users receive exactly the functionality they need – no more and no less. New features are activated as required and a release change only takes place if the customer really wants one. As a result, this keeps customising work to a bare minimum. Industry-specific products are also available as fully standalone applications – such as a packet specifically for IT service providers and one which is tailored to hardware providers.
And so tangro completes the circle. The past has clearly shown us that individual software is unmanageable and standard software requires massive rollout efforts. The tangro architecture succeeds in combining the benefits of both methods: efficiency paired with uniqueness.
