SOA projects are multifaceted. On the one hand, an increasing number of technical systems and distributed business processes need to be integrated. But on the other hand, less time and money and fewer resources are available for projects. And because products and services have to get to market that much faster, the expectations and wishes of user departments are also growing.
Cross-departmental processes are now common, meaning that access to a correspondingly large number of back-end systems becomes necessary. And as a result, compared with a classic IT project, more knowledge workers must be involved right from the planning process.
The planning phase of an SOA project is crucial for its success. Of particular importance here is the technical business blueprint, which precisely documents the business requirements and how they will be implemented. Using models, these requirements can be converted into clear graphical representations.
Don’t forget the feedback loops
IT projects can be divided into three abstract phases:
- Process design: receiving and documenting the process to be automated and mapped with its roles, process steps, dependencies, decision-making criteria, and data flow
- Technical business blueprint: Which systems are involved? How do they communicate with each other? How can the business process be projected onto this system? Mapping the functions in the system landscape and using the technology
- Implementation: programming, implementing a product, customizing, required solution enhancements
During the process design, the processes to be implemented are analyzed and the solution’s desired response is described. Modeling standards such as EPC (event-driven process chain) and BPMN (business process modeling notation) help project teams to compile important information.
In the technical business blueprint, the team members specify how the processes described can be technically implemented. The results of this phase are a set of instructions for the subsequent implementation. However, the process isn’t linear – feedback loops are the rule.
In other words, if certain requirements change during the implementation phase (for example, check steps, business responsibilities, or cardinalities between business objects), the process must be adjusted accordingly. And this means that the business blueprint must be adapted, too.
The later such feedback loops occur in the course of the project, the more expensive they are. The objective should therefore be to identify possible problems in advance and run through the related changes on paper beforehand. Here, it is useful if models describing the technical specifications can be generated as early as the blueprint phase. They are usually created based on general process descriptions.
Generating UI models
If a list of materials needs to be displayed on a screen, a “load materials” service is required. If the information required for this service comes from several back-end systems, a component communication model is created. This visualizes how the components are distributed, which component delivers which information, and how this can be aggregated to form a service.
However, the classic IT modeling methods such as Unified Modeling Language (UML) and BPMN are of limited help to business departments, because they require specific technical knowledge. UML, for example, offers many different models, such as sequence, class, and state diagrams, whereas BPMN centers on the processes themselves and the roles that execute them.
UI models (mock-ups of the user interface) enable much clearer communication. They involve the user interface that will be implemented later being visualized using templates in Visio or PowerPoint. With such graphical representation, employees can see how they will use the system once it’s finished. What’s more, mock-ups help the user departments to identify any gaps in the functions.
At the same time, the model becomes the set of instructions for the subsequent implementation. Metadata – such as field lengths, required entry fields, and validation and consistency conditions – is incorporated into the mock-ups. This information gives the developers the required level of detail for their development tasks later on. Nevertheless, UI models cannot replace classic forms of modeling, but rather supplement them.
Screen flowcharts are produced when the individual screens are arranged in order. With them, the functional need for services can be identified, which acts as a starting point for modeling enterprise services at a later date.
Once all the functional services have been identified, SAP’s governance methodology steps in to model and reuse enterprise services. If an existing service can be used, a check is run to ascertain whether all the required fields are there. Loose coupling facilitates service stability, so that unknown applications can continue to work with the published services.
If a service does not yet exist, it is modeled in accordance with design governance. This method describes how services should – ideally – be modeled, so that they can be found and reused. For such purposes, SAP provides detailed information.
The UI models are regularly validated by the user departments. In other words, the user departments declare that they agree to implement the application according to these models.
At the same time, any technical pain points identified are gathered and resolved in a prototype. These may entail, for example, connecting non-SAP applications or special end devices (such as time recording, production machines, or sensors).
In addition, involving the user departments at an early stage means that another review takes place – because this is where the end users are. With these loops, changes and adjustments need only be made “on paper”, before the solution is finally mapped in the system.
The procedure described helps companies address the critical aspects in an SOA project at an early stage – thus generating sustainable value. The methodology cannot reduce the task’s complexity, which is intrinsic to the projects and goals themselves, but it enables a project to be structured in manageable units and, as a result, improves transparency throughout the entire project.
Business departments become involved in the project at a very early stage. Consequently, the benefits of the application are verified promptly and the project team can ensure that the final result meets users’ expectations.
The results documents in each project form a logical chain of conclusions. Problems and inconsistencies are identified in good time, maximizing the productivity and efficiency of the project. The required feedback loops can be worked through using mock-ups rather than code.
SOA: act flexibly, react innovatively
With the concept of service-oriented architecture (SOA), companies can develop new applications based on existing business solutions, thus maximizing the value of their current systems and automating new processes.
SOA is based on the business process platform. SAP NetWeaver forms the technological foundation, while SAP ERP is the functional core, giving companies all they need for service-oriented IT.
Business functionality is represented using enterprise services. Technically speaking, enterprise services are series of Web services and are shipped as SAP products, so that they can be used right away and do not need to be developed first. Enterprise services increase transparency for externally accessing complex software modules that are provided and called using the Internet and other data networks.
Using open, standardized interfaces (for example, based on the metalanguage XML), they can execute defined tasks, provide services, and map complex business functionalities. Enterprise services can be combined and enhanced to form new business processes according to needs.
In addition, various development tools are available. SAP Composite Application Framework (SAP CAF) and SAP NetWeaver Business Process Management (SAP NetWeaver BPM) play a key role here: Applications no longer have to be developed from scratch, but can be created from existing applications like building blocks.