Is Visual Composer just another tool for creating business applications?
In my second blog of the Visual Composer blog series, I would to find the answer for this question on the basis of the paradigms of business software. You are probably wondering what have the paradigms of business standard to do with Visual Composer. This is a legitimate question; you probably are now thinking that I only want to move the drum for our Visual Composer book and find it perhaps even arrogant, that I associate with Visual Composer, the paradigms of business software.
Presumably you also have heard the rumors at events like the SAP TechEd events or ASUG/DSAG that Visual Composer is just another tool of the SAP portfolio that will soon become extinct, such as the BEx Report Designer. It is also obvious, because with Business Objects Xcelsius you have another nice tool that allows you to conjure up within a few seconds beautifully animated Flash applications. At this point, however, I must disappoint the Visual Composer opponents, because Visual Composer will not substituted by Business Objects Xcelsius. To answer our question, we therefore now consider first the historical development of business software and the paradigm shift in recent decades.
Historical development of standard software
In the 1960s there were only individual software and no standard software. In the 1970s, the first individual packages were developed as standard software; however, these were not developed as integrated standard software as we know it today. At that time, SAP was founded and began developing its first business applications with a focus on payroll and accounting. This software was designed as standard software, i.e. this software could be used by other customers. SAP is also referred to as co-founder of the standard software. SAP put in contrast to IBM at the input on the screen rather than on punched cards, so the SAP software as its founder called real-time system. Many of SAP software products have been characterized thus by an R in the name chosen for real-time. This paradigm shift was certainly one of the reasons for the growth of SAP.
In the 1980s, more and more individual packages of business applications as standard software were offered. These individual packages of standard software were not integrated; however, that is, each individual package had its own database. As a consequence, were in the literature often called "island solutions" designated systems. These isolated applications have resulted in data redundancy that existed in the respective system and data must be entered several times for the respective business processes, which in turn had the effect input errors and data inconsistencies.
This has been recognized in the 1990s and the "island solutions" were brought together into integrated standard software. It supported almost all internal processes from order entry, material planning to invoicing, and had a common database as a basis, thus avoiding data redundancy, multiple inputs and data inconsistencies. These software systems are described in the literature very often as integrated Enterprise Resource Planning (ERP) systems. The IT architecture has undergone at this time also a paradigm shift towards client-server architecture away from the mainframe architecture. Probably the most prominent representative of the integrated ERP systems based on client-server architecture is SAP R/3. These systems were the basis for a significant optimization of internal business processes across the various departments and across the integrated standard has prevailed. The business processes along the value chain are characterized by the fact that they run across corporate boundaries.
In the 2000s these cross-company processes were then supported by standard software, such as to optimize the supply chains of so-called supply chain management (SCM) systems or to optimize the procurement processes of an enterprise through supplier relationship management (SRM) systems that includes the supplier relationship management, i.e. strategic planning and central control of a firm's relationships with its suppliers. In these cross-company processes were initially individually developed and implemented non-standard interfaces between the respective companies. These interfaces have been very costly to implement and maintain. Mergers and acquisitions also led to a heterogeneous system landscape in the companies. This was another reason for the development of the high cost individualized interfaces between heterogeneous systems. This problem is not new in the IT world, and in order to eliminate this dilemma has been attached importance to standardization. Data exchange standards such as Extensible Markup Language (XML) and standardized interfaces via Web services laid the foundation stone for another paradigm shift, the service-oriented architecture (SOA).
Is SOA the jack of all trades device?
The SOA make sub-processes and functions as services available through standardized interfaces so that new IT based business processes can be implemented quickly and flexibly by existing functions and sub-processes are combined into new innovative business processes across corporate boundaries. In the literature this is called the integration and orchestration of business processes. In theory, this sounds as if the SOA is the jack of all trades device. I would agree with that, if the process responsible within the departments could identify a computer science study in his curriculum vitae. This corresponds, however, almost never the reality. Why do we still need a computer science degree with SOA?
Quite simply, while SOA means that you do not have to reinvent the wheel each time, since functions and sub-processes are delivered as services through standardized interfaces, and thus the business logic can be reused. However, when implementing new IT based business processes based on SOA generally written code is still needed. Depending on the IT platform it is mostly ABAP, Java or C#. As a result IT projects are implemented according to the classical approach, i.e. the business departments have to define the requirements in the form of functional business blueprint (FBB). On the basis of the FBB, the IT specialist will define the solution business blueprint (SBB) that describes more or less detailed, which requirements will be implemented in the system. This SBB must then be signed off by the responsible business process owner. Then the implementation and testing will take place. If all goes well and the communication between business and IT is not too bad, the business department will experience no bad surprises during the first test after months or even years after the project start. SOA resolves the problems of the heterogeneous system landscapes, and bring cost savings in implementation of new applications through the reuse of services, but unfortunately you cannot say that SOA is the jack of all trades device, despite the hype around SOA.
Application creation based on SOA
Certainly, the SOA is a step towards the jack of all trades device, but you should profit from the benefits of SOA. You should ask yourself the following questions. Would it be cool if we could create new applications without programming? - By combining existing services into a new application with a user interface that is created via drag and drop based on existing elements. Presumably, this would not only save time but have also a positive impact on the project budget. If the users could develop their applications themselves, they would probably be much happier with the new applications and to accept them rather than the results of FBB and SBB, which most likely remind them to whisper down the lane.
The answer to these questions and problems of the traditional application development is Visual Composer. This tool allows you to develop SAP business applications without a single line of coding. In contrast to traditional application development, the applications are modeled with Visual Composer. This includes both the dataflow and the User Interface. After a short training period the staff from the business departments can begin to create new applications with Visual Composer. The service-oriented architecture of the SAP NetWeaver platform enables the modeler access to a variety of data sources and services. The use of business standard software based on an SOA, combined with tools for model-driven application development, such as the Visual Composer, enables companies and their departments to adapt fast and flexible their business processes according to the market situation by orchestration of their existing processes.
Conclusion
The possibility that users from the business department can create and deploy their applications themselves without having a computer science degree represents a paradigm shift in application development. The first question asked whether Visual Composer is just another tool for creating business applications must therefore quite clearly negated. Despite the hype about SOA and my enthusiasm for creating applications with Visual Composer; I have to confess in all fairness that usually still code must be written by developers, because often not all required services are available. The possibility that business users can create business applications within a very short time by model-driven application development raises the question whether the traditional practices in application development like the waterfall model are still adequate. This is what I would like to discuss in my next blog.
The german version of this weblog can be found in the FIVE1 Blog.
- SAP Managed Tags:
1 Comment
