Tailor-made software according to the Lego principle

For a long time, the credo of software producers read: “Adapt your company processes to the software”, although recently a remarkable change has taken place. In order to be able to react flexibly to fast changing market requirements, the call for a new software architecture has become louder.

It’s not only the market leaders among software producers who have now recognised that they need to offer their customers more. In the spotlight are users’ demands for greater flexibility, faster response times for adjustments and a significant reduction in rollout and maintenance costs.

What’s stopping this from happening?

For reasons of cost, and from a technical standpoint, too, manufacturers of standard software have in the past been forced to map as many processes as possible for different industries to as full an extent as possible and in a way that is legally compliant for use in different countries. This meant that the offering of the software solution grew continuously, the customer group expanded and the enormous investments paid off for the manufacturers. However, for the individual customer this gave rise to a surplus offering of functions that were not needed. In combination with the complexity of the company’s own business, this meant that the customer could no longer see the wood for the trees. The more detail the software producer goes into to meet the needs of customers as a whole, the more complex customising or parameterisation becomes. A customer from the textile industry is confronted with customising options for the production industry and many other sectors. As a result, the introduction of standard software becomes a costly undertaking, while operation and maintenance also take their toll. Minor changes become a risk to running operation and often incur major costs. There’s no doubt that the approach of delivering as much as possible so that the customer can set or create the right application using customising has reached its limits. From the customer’s viewpoint, the ideal solution would be to restrict the application software delivery to the scope he requires. This calls for an architecture that satisfies this approach. Evidently such an architecture is missing for the applications available on the market.

UML (Unified Modelling Language) and MDA (Model Driven Architecture) have been promising to improve the situation for years, while SOA (Service Oriented Architecture) and ESOA (Enterprise Service Oriented Architecture) are being prized as the future of software development. However, SOA or ESOA are still just visions and their protagonists are already finding it noticeably more difficult to convey their benefits. In reality, all previous approaches have failed to deliver when it comes to shorter time to market, agility and transparent processes. In particular, a consistent engineering-based approach, which has long been a matter of course in the automobile industry and other branches of industry, is sorely lacking. SOA and ESOA advocates rarely speak of the reusability of modules. When asked “how” it’s going to work, they’re stuck for an answer. This is fatal, as reusability is one of the core factors when it comes to creating highly adaptable applications with transparent processes in line with market requirements.

In practice, the majority of software projects exceed their timeframes and budgets quite spectacularly. While proponents of SOA and ESOA are still developing visions and puzzling over how granular software modules need to be, the tangro platform offers a solution that doesn’t just exist on paper or as a vision, but which is successfully being used as the basis for several products on the market. Those modelling business processes implement tailor-made applications. The tangro platform realises the age-old dream of software development: creating application software according to the “Lego principle” with reusable software modules.

By using graphical modelling for designing Event Process Chains (EPC), the dynamism of business processes is taken into account naturally. The tangro platform has no media breaks between modelling, development environment, workflow and documentation. The tangro Business Process Builder makes it possible to assemble granular reusable software modules into application software through graphical modelling. From purely specialist process modelling, the process designer approaches the detail level without leaving the modelling environment. If he/she lacks the technical experience needed to solve problems at detail level, a technical consultant can be called in. Time-consuming and error-prone intermediate steps such as IT process modelling, IT design and implementation are not needed. The secret is in the architecture – where else?

It’s the granularity of the software modules that makes the difference, as it determines the flexibility, adaptability and reusability of the software modules and, as such, the applications. Today, complex applications can usually only be adapted to a certain degree as they consist of relatively monolithic software modules. However, the adaptability of the software that the customer so urgently needs often affects the detail level, i.e. the inner workings of the monolithic software modules. Yet this is fixed in place by certain structures and functions. Logically, we clearly need to move towards small, manageable software modules.

As with building a house or a car, reuse also dwindles in software the bigger the modules are. Software modules should therefore be manageable and give only one answer to a question as far as possible. However, this implies a very large number of calls from software modules for the runtime of the applications, which would in turn appear to increase the need for interfaces for calling up the software modules. The hard-earned savings attained through reuse would be largely obliterated if the interface work required did actually increase in line with the software modules used. Such reflections, as well as the building block analogy, are simply asking to be refuted.

“I see two fundamental errors in the comparison with Lego. For a start, everything looks the same with Lego – the modules always have the same form for connecting with one another.

In business management, however, all interfaces are essentially different from one another. Integration for automating production, for example, is different from electronic payment integration with the bank. In order to coordinate these many thousands of different services, SOA provides a common construction principle. Secondly, SOA does not provide instructions for complete DIY. Sensibly, a customer will use 90% of a business management solution as it is. However, the areas where his processes need to differ from the competition are where SOA comes into play for him. SOA is predominantly used to expand software solutions.

"Services show where new functions can be added via standard interfaces”, says Peter Zencke, Board member of SAP AG. Now even though software modules or services require different information to solve different business management tasks, this certainly doesn’t mean that the software modules or services used need to have different interfaces. With its unique architectural approach, tangro has refuted all objections. Although software modules are designed for solving different tasks and their content therefore differs, with tangro there is no need for any interfaces for calling up the tangro software modules. What’s more, the requirement for using 90 percent of a business management solution as it is only stands up if this 90 percent doesn’t have to be modified. As already mentioned though, the adaptability of the software so urgently required by the customer often affects the detail level, which is to say the inner workings of the monolithic software modules, and hence also the 90 percent mentioned. In addition, it is this 90 percent which is often so complex that customising itself becomes a challenge – and for the sole reason that the customer gets far more than what he needs. The situation demands, then, that we give the customer what he needs – no more and no less.

Yet this requires an architecture that supports adjustments at every level, no matter how detailed. Alongside tailor-made applications, this includes the transparency of the process down to detail level, reusability and free combination of the software modules in line with the Lego principle. In delivering just this, the tangro platform goes far beyond approaches such as SOA and ESOA.

The benefits of tailor-made applications from tangro:

• The process model and application match
• Tailor-made applications lead to less complexity and minimal customising work
• Drastic reduction in the project duration and TCO for production, adaptations and expansions thanks to high reuse
• No need for interfaces
• Transparency of the processes
• Process modelling for documentation, standardised representation and development method
• High quality through reuse
• Successful projects because
• High reuse enables early feedback on the project status
• Process modelling as documentation and standardised representation increases common understanding
• Process modelling as the standardised development method increases common understanding and makes it easy to transfer work

tangro: simple and pragmatic

Automated processing of incoming invoices with the SAP add-on, tangro Invoice Management (IM): 

• Tailor-made solution
• Document analysis within the SAP system, not in upstream systems
• Analysis, validation, invoice verification with reference to goods receipt and possible posting in a single step
• No interfaces = no outlay
• No export and import of master data and/or transaction data
• Short project durations