Since PI and SOA are very widely blogged areas, I am sure people involved in both understand what the purpose of this weblog is. Architecture and Technology Implementation have always been seen as two separate aspects of any Project till recently when Enterprise SOA opened up a whole new venue for Technical Consultants aspiring to get involved in the much higher and mystified concepts of architecture thereby maturing into Technical Architects.
But since the Netweaver Platform is used as a whole in enabling Enterprise SOA, from a technical consultant perspective, it is vast and practically impossible to conquer SOA technically. If a consultant tries to be an expert in Enterprise Portal, Webdynpro, Master Data Management, PI, CAF and all other Netweaver components that act in unison to make an application SOA enabled, he would end up being overwhelmed and exhausted. But at the same time the sudden transition from a PI (or any other Netweaver Component) consultant to a SOA architect also seems impossible.
Hence this topic, what does it take for a Technical Consultant to become a significant contributor to a SOA implementation.
PI and SOA
SAP PI as it is known now was rechristened from its earlier name of “Exchange Infrastructure” for a purpose. While XI was rolled out, the general presumption among the technical community was to position it in alongside mass data moving ETL tools. This caused not only some performance issues but also a gap is what XI was actually meant for and what it was currently being used as.
With SOA gaining prominence XI was aptly renamed as PI to actually give more clarity to the role it would play in SOA. My first realization was that the change is not much in the product; rather the change that had to be bought about was in the perspective of the XI programmers.
In SOA , PI would be involved at a much higher level of process orchestration. In an End-to-End scenario such as “Order to Cash” which will, in a real time scenario involve many systems, SAP and Non-SAP, PI would be one of the main players in managing the Condition based process routing of Business Scenarios. In a programmer sense it means that we must no longer talk “File to Idoc” scenarios in XI, rather we must talk “3rd Party Return Order Processing” Scenario. While this seems like just a change in jargon, it will surely reflect that way we actually convert this requirement, because now we are talking one level above the actual Data Flow, it will actually be more of Business Process Flow.
PI and Other Netweaver Components
Like it has been accepted that SOA is not only Webservices, it is also a reality that knowledge of all Netweaver Tools is required to understand and effectively implement Enterprise SOA. However there is an advantage here, to be an Enterprise Architect it is not required to have technical command over all the Netweaver Tools, understanding the role each of the technologies play in SOA and to ensure none of the technology building blocks are fitted into incorrect locations in your architecture is what is expected from an architect. Hence the answer is we need to have a thorough understanding of Netweaver Platform and the technical know how of each of the Netweaver tools are not required. The knowledge that one possesses about any of the Netweaver Components would help in making the solution more accurate.
One simple example is that, since we are dealing with webservices, it would now be the role of an architect to organise the huge number of services operating in your enterprise across various systems. While Webservices published from the application layer can be consumed from Enterprise Portals, Webdynpro, Adobe Forms, we must realize that if all the front end tools consume WS from Application layer, we would end up in a “Point To Point” scenario without actually harnessing the advantage of SOA. The important call would be to clearly define “Who does what” and the level of data abstraction that is required. As a PI Consultant, the responsibility would be to interact with the front end as well and abstract the entire underlying business application, route the flow conditionally and finally fetch and return the control with the information to the front end system.
PI: No More a Compulsory Gateway of access
Traditional Middleware tools transform the Landscape into a Hub and ensure that the application layer access in routed through them. I must confess that the mindset of many of PI developers is likewise. As PI consultants in SOA, we must allow the business requirement to decide whether the processes would be routed through PI or whether the Business Process would bypass PI to directly access the Application Layer.
For example, take a scenario when the business has decided to give a customer portal where customers can place an order and receive a confirmation. The underlying process as we all know involves a lot of steps starting from creation of SO, till the shipment and in some cases till invoicing and billing. If the business decides to have just one service that takes an Input from Customer and provides him the date when the requested item would be delivered to his location, this, even thought a very high level of abstraction, must be accommodated. In such a scenario PI is not required. The Front End systems can directly interact with the application that publishes the service.But a good design would be to break down the process into smaller blocks for reusability and for conditional orchestration. In such a scenario PI must be used to take control of the business process flow.Since I mention process orchestration, I must add that it is important to understand the process orchestration or modelling done at different levels. While PI does this as Business Process Level, CAF and GP do the same at a much higher level involving user roles and Composite Applications.
PI: As an Enterprise Service Bus
The role of PI as an ESB is pretty much the summary of what we have talked till now. A technical consultant must ensure that PI lives up to this role. The means to achieve it are the ones that we discussed above. PI must act a conductor and run along with the process across various systems in the landscape rather than being the central controller. I have come to see that this is an evolving skill for the PI consultant and would come with experience.
BPM: Popular Again
BPM lost its popularity with the PI consultant community for being very memory intensive and causing performance issues. SOA would again expose the actual usage of BPMs to conduct and control the flow of webservices across different systems. I have surely seen an improvement when the services are called and designed in a way to ensure optimal data exchange. The usage of BPMand Webservices simplify the scenarios and SOAP adapters make it easier. BPM would have to be given its due importance again to ensure that Business Processes are transparently managed in SOA.The concept of Enterprise Service Repository has been well received by the Technical Consultant Community and hence I am not explaining that part in detail.
ES Workplace, A very Good Starting Point
The ES Workplace in SDN is surely the best way to get started in SOA for PI Technical Consultants. Enterprise Services have been organised in a way that both the Technical and Business Community can understand. The published services from the backend systems (HU2 etc), can be used to design and develop an “End to End “ scenario and at the same time provides a lot of clarity as to what the business flow actually is. The comparison between the classification of services based on Process Components and ES bundles will clearly explain the difference between the way we view systems now and the way we must strive to categorize requirements going forward in SOA.
The conclusion that I gather is, with a little more insight into the other tools used in E-SOA and with correct knowledge of the role each would play in SOA, we can claim to be significant contributors in the SOA framework. From being a developer, out of the Box thought is required to get the bigger picture and virtually transform the work we do into business programming rather than just Data Flow Enabling. Falling in line with set guidelines laid down by SOA, which I think is the toughest part for the Technical Community, needs to be achieved to bridge the gap that currently exists between the architecture framework and the actual “On the Field” development activity.