In essence, a ‘Duet Enterprise custom scenario’ development project is not different from other application development projects. The customer – either the real end-user, or product management for package software -, has an idea about what to achieve and functional + non-functional (quality) requirements to underline the idea. Often this idea is still vague, and the requirement set far from complete and on aspects also contradictionary. The waterfall approach to yet start with application development (specify, build, test) typically ends up with wrong or failed end-results: the application does not live up to the real customer needs and expectations, and the budget is largely overrun as consequence of responding on the requirements changes. The agile movement came up to improve on this bad practice. Central is the structural involvement of the user (representative) during the full course of the development project. Continous, the user is in the lead about the specifics and the behaviour of the application functionality to be delivered. In Scrum, this responsibility is formalized within the product owner role.
Application mockup
A proven approach to enable the product owner to validate, correct, and ultimately confirm the application functionality is by make it experiencable, ‘touchable’. Provide the product owner with a realistic impression of the application behavour + feature(s) that the project will build: a clickable prototype / mockup.
Based on multiple positive experiences (also within non-Duet Enterprise project, e.g. BI Dashboards), we strongly believe in the added value and power of application mockup. We regard the role of UX / UID expert crucial for customer involvement, and thus for delivering the correct application functionality.
Meeting of 2 worlds
Yet, a Duet Enterprise project also is very much different from ‘normal’ projects. The cause lies with the meeting of 2 very different environments: IT technology, platform concepts, and human nature. The tradional SAP environment is transaction oriented, with focus on structural business process executions. The Microsoft environment, and in particular SharePoint, is far more loose. Ad-hoc processes are the norm, the individual user decides how to perform a specific (business) action. When these 2 worlds + thinking come together in a Duet Enterprise project, the first outcomes are often dramatic. SAP versus SharePoint architects, business analysts and developers do not understand each other (concepts). Both ‘parties’ disagree on how and where (that is, on SAP or on SharePoint side) custom development should be done. The personal preference on how to achieve the SAP+SharePoint integration is influenced by one’s own technology frames and familiair concepts. This has the risk that the user is forgotten: the user interests must be central, deliver an optimal user experience.Align through Blueprint Duet Enterprise scenario’s
To break through this, we utilize in our Duet Enterprise development process a blueprint step with the focus exclusive on the Duet Enterprise specific scenarios. This blueprint is derived and agreed by a mixed group of SAP and SharePoint representatives. The goal of this step, and its endresult, is to come to a mutual understanding of the solution direction for each of the Duet Enterprise scenario’s. Self-employed constraints are to stick as close to the standards of both the SAP business package and SharePoint platform. Where feasible, we do allow custom development. Here we apply Duet Enterprise integration patterns that we have identified and defined: Consumer-oriented, Provider-oriented, and XML-Funneling pattern.Of course, the discussion and preferences about where to make custom adjustments still manifest within the Duet Enterprise blueprinting step. However, as it now has the full focus of all involved, mutual agreement is earlier and more effective reached. This is the so-called ‘workshop effect’. Also, in this focussed approach, comparable application situations are easier to recognize. And where so identified, the earlier agreed solution approach can be reused. Starting point for the blueprint derivation is the User Interface Design as validated and confirmed by the product owner.
In the blueprint we derive and define per identified Duet Enterprise scenario the following pieces:
- Global descripion of the scenario: screenshot of the mockup screen and textual explanation. The purpose is to facilitate on high level a common understanding of the functionality in the scenario. There is no intend to compete with or replace use cases.
- Derivation, explanation and justification of solution direction. At minimal explanation of the proposed solution direction. But whenever applicable, also the rationale of why an alternative solution direction is dropped.
- SAP / SharePoint interface
- SAP Gateway datamodel(s)
- SAP building blocks: standard RFC’s, BAPIs; identification of needed custom SAP building blocks
- SharePoint building blocks: standard and custom webparts, SharePoint Service Applications, …
Blueprint validation by Design Authority / Authorities
Justified mantra nowadays within SAP and Microsoft IT departments is to avoid unnecessary or otherwise avoidable custom development. Instead stick close to the standard delivered functionalities of both landscapes.It is also evident that fully excluding custom development is not feasible when you are developing company custom scenario’s.
We facilitate the consistency and continuity in the Duet Enterprise solution directions by confirming the blueprint to Duet Enterprise Rules, Conventions and Guidelines. The Design Authorities of both SAP and Microsoft IT departments validate the blueprint against these agreements. Derivation can be allowed, but requires the formal approvement of the respective Design Authority (SAP, Microsoft, and in some cases both).
SAP + SharePoint realizations based on the blueprint
With the blueprint accepted and delivered, from here on SAP and SharePoint teams in the project can start with their own development activities for the Duet Enterprise scenario’s. Since representatives of the teams were involved in deriving the blueprint, the concrete software design + development can be done relatively independent of the other party. Of course the data contract details of each SAP / Duet Enterprise interface are input for the SharePoint consumption. Regular sharing the SAP design with the SharePoint developers can achieve this.
Duet Enterprise Development Process
|
|
Step
|
Responsible
|
Consulted
|
Approach
|
Input
|
|
1
|
Business analysis
|
Business Analyst
|
Business representatives
|
Interviews
Workshops
|
Business vision
|
|
2
|
Mock-Up
|
UID / UX expert
|
Business representatives
Business Analyst
|
Sketching
Prototyping
|
Style guide
|
|
3
|
Blueprint
|
Duet Enterprise Solution Architect
|
SAP Business Analyst
SharePoint lead
|
Workshop
|
UID
Duet Enterprise Rules, Conventions, Guidelines
|
|
4
|
FoTo’s
|
SAP Business Analyst
|
SAP developer
SharePoint developer
Duet Enterprise Solution Architect
|
|
Blueprint
Duet Enterprise Rules, Conventions, Guidelines
|
|
5
|
Build
|
SAP developer
|
|
|
Blueprint
FoTo’s
SAP Build – Rules, Conventions, Guidelines
|
|
SharePoint developer
|
Duet Enterprise Solution Architect
|
|
UID
Blueprint
FoTo’s
SharePoint Build – Rules, Conventions, Guidelines
|
|
6
|
Integrate
|
SAP developer +
SharePoint developer
|
|
|
Operations – Rules, Conventions, Guidelines,
|
