*A piece of disclaimer, the views presented here are purely mine based on my experience and is not indicative of views held by any organization or entity.
SAP has put a great deal of thought and work into pimping Integration Repository- the result Enterprise Service Repository is truly a piece of art. Some might argue that ESR is nothing but a glorified IR, there is no denial in this fact. ESR is Integration Repository, but better yet we customers can now use IR not just for integration but beyond that we can use this as the common repository for all service development in the landscape, SAP and non-SAP alike. Customers in the past were innovate in using IR for this very purpose, but the general pool of customers were not aware of this design usage and were often mislead by the word “Integration” in IR. ESR now addresses this with a vigor, the concept of outside-in development will provide a great deal of advantage to all those who want to standardize the structures and services across the enterprise. For users of business suite this should sound like deja vu, who were used to the concept of unified data structures in Data Dictionary, think of ESR as a global data dictionary spanning more that one host systems abstracting the structures and service designs from the location of implementation. If there is a differentiation for SAP from the rest of the vendors (IBM, Oracle, Microsoft and the rest) in this space, it is ESR. SAP is sitting on a gold mine called ESR that with very little effort brings together both the business content from SAP systems and other vendor based products.
In the early days of XI3.0 SAP made an effort to support UDDI and released a very naive version on Netweaver. It lacked the most basic features offered by the other vendors but still showed a great deal of potential. In some of my past articles I took an effort to shed light over this little known component of XI that was needed direly. UDDI as such in the industry has been a failed attempt. In theory UDDI or UBR sounds really cool but practically these concepts and tools have not been successfully leveraged into the product line or embraced by the customers using different vendors. The problem in my view UDDI lacked the connection or the context with the business applications, and this is where SAP will have the advantage over its piers. Service Registry is SAP’s solution of finding and discovering services. In principle I agree with what SAP is doing but in reality SR has a long way to go and to be mature. An analogy to put things into perspective is an example of baby registry, where you know that your friends have registered at a place and their registry gives you information as to what they want. The pattern of discovery here is important, with registries we are aware of the existence of an entity and we are trying to find it. Unfortunately at this time SR is very technical in nature and defeats the purpose of discovery, in some places SAP may be doing the same mistakes its predecessors made with UDDI. SR has a lot of potential and a good future provided, it is more business and process friendly and integrated to ES work place.
if there was something that was missing in the SOA Revolution was usage of unique enterprise meta models that represented process entities and elements of operations tied to the process that were re-used across the landscape. Again for the business suite users this might sound like an old song, since this design pattern was used within the suite line of products for the last 20 years in the form of data dictionary. But in the world of web, in the name of flexibility and being nimble this critical lesson from the client server model of products was not picked-up and hence as a result many of us paid a lot of cost for standardizations in the industry. Innovation and being nimble is important but not at the expense of the company. With PI7.1 SAP is the leader in providing out of the box industry standard process structures to the customers. This is one of the pivotal tipping point for SAP when compared to other vendors. The pace of development and re-use of existing structures is remarkable. Unlike its piers SAP’s investment into global data types that are used within all its products will knock off the KPI scores and TCO numbers.
This is a home run for SAP, pre-delivered enterprise services content out of the box, this is too good to be reality. But this is true, you are not walking in utopia. Again SAP left all its opponents and its competitors in dust with this cool content. In fact in my opinion SAP is at least few years ahead of its look alike who are trying to emulate SAP’s design practices. Again for some of us this may come out as what is the big deal, R3 had BAPIs and Business Objects defined and available for everyone to use. Same concept applied at a more grander scale, this service content pattern can prove to be the next big gold rush for all those customers who want to realize the dream of SOA into dollars. Imagine about 500 services and related content provided to you with no effort from you. Some of this content is more industry driven so it actually reflects the structures used across companies and vendors.
The redesigned Integration Builder interface seems to lack the punch or lost its touch with its predecessor PI7.0. I agree that change is tough and takes time for people to accept change, but needed less change in some areas in the name of better user interaction seems to indicate of miss management of time and money by investing into places that have very little or no business value. 7.1 brings in very impressive new functionality that need a better organizational format, this is understood and makes sense in revisiting the layout that has practically not changed since the XI2.0 days, which is over 5 years. I only wish the designers were more astute in keeping the best of the features of the prior version instead of reinventing the wheel again. In particular the scenario view where all the objects are dumped into a grid for display cluttering the view and appearing to be more complicated. It would have been nice if even in the grid the objects based on their type were collapsed into a unit. This is just one example, overall I think it will come upon as a surprise to customers who upgrade, a piece of advice leave a sandbox server in the prior version, so that the developers can compare before and after while they try making sense to the interface changes. By some unofficial accounts we have actually seen the productivity drop due to the user interface changes. For those who might suggest training will resolve this issue, I would say what if the steering wheel of your Lamborghini was replaced by a square steering? will training help you be a better driver and get used to the square?
XI2.0 -> XI3.0 -> XI2004s -> PI7.0 -> ESB (PI7.1) Quite an integration journey. PI was in the past positioned as an integration hub and some of us strongly felt by having different names and presentations for integration SAP would end up cornered, defending that XI is not a proprietary technology and explaining integration buzz words they choose that were not in line with the industry best practices of integration. More than branding the future of integration is the pattern of ESB, integration hub which might do most of the functionalities of bus lacks the advatange of a bus with distributed computation, policy based message processing, on demand priority processing etc. These are some the know plain jane features offered by ESB based product lines. The features available now in 7.1 like advanced adapter, direction connection, centralized configuration, payload validation, identity support are the correct steps in the right direction.
If there is something that SAP needs to do to ensure it has the edge over all its competitors and market share, is to really lesson to the pains of upgrade. Upgrades in a huge installation are painful this is a reality, no one can expect a zero defect installation or upgrade. In spite of the best efforts and endless resources best of the best entities make errors. This is as true as being human. Now having said this the pains of upgrade are really expensive emotionally and financially. The collateral damages that an upgrade results in just not acceptable. Wonder what would our business users react if we were to deliver a process that is so painful. Lack of proper documentation, undocumented radical changes in architecture and significant parameter changes are some examples that we found out the hard way.
But the solution to eliminate problems with upgrade shouldn’t be the driver for a side car installation. Sidecar installation should be one of the options not the only one or the one strongly recommended. It is in this aspect that I strongly disagree with the SAP marketing machine that has set a tone in the market place that side care installation is the logical option. This might be an acceptable option for either very very big companies for whom money and time is of not significance or companies for whom PI7.1 is their first exposure or for companies who have a small foot print of existing assets in PI and wouldn’t mind having a parallel landscape to mitigate the challenges of upgrade. In many of the companies that have built their SOA strategy around PI and have huge investments into PI in terms of servers, high availability, failover the thought of sidecar will give jitters to justify the cost of upgrade.
In some published articles, it was claimed that the was upgrade completed and client went live with in a week! As much as I really want to believe this it sounds too good to be true. On an average, based on the past investments ,defined SLA and existing interdependencies I think it should take 1 month<upgrade<4 months. Any faster than this period in my world it is like walking on water.
Imagine you bought a house and decide to upgrade some parts of the house and the builder recommends you to build a new house (sidecar) adjacent to the existing house with the fancier kitchen you desire, have two kitchens and move stuff from one kitchen to other for a while and then convert the old kitchen into a bed room.
I doubt how many of us will have the patience to hear this option. Think about it
After you have endured the upgrade process and that’s when the rubber hits the road. You are live, your customers expect the same performance if not a better performance for their money. And in this aspect PI7.1 delivers as promised. Its core the Netweaver Web Server is rock solid and pounds RPM as desired. It is amazingly stable given the number of documented and undocumented architectural changes that were made to the core and the application stack running on it. The only reason I am giving 41/2 stars to this aspect is because of the fact that there are now tons of new parameters that can boost your performance but are not properly documented or don’t have proper recommendations.
Finally Netweaver Administration has been substantially beefed up and visual admin has been retired. You heard me right, Visual Admin is no more, rest in peace VA. In spite of the clucky look and feel of VA, it is one of the tools that the basis team love. I wish there was a more balanced approach of segregating things that the administrators have to do day in day out versus some features that could be used by others outside the basis team. Don’t get me wrong, NWA has all kind of cool bells and whistles that will make the life of those using it very easy to find and use features with in NWA. But the bottle neck to all this is the feature limitations due to the browser in which NWA is running. NWA locks up the browser many times which leads to few annoying minutes of going no where. And then we have the famous fortune wheel turning but have no clue as to why it would take so long in NWA things that were taken for granted in VA. NWA is a cool nifty tool that unlocks all the functionality once tied to VA that can only be accessed by few people, but watching NWA in action i strongly feel there should have been a think client version for those who work on it 80% of the time. But given the new features now available around availability check, performance monitoring etc. NWA still comes out on the positive side.
It would be nice to see features like remote compare, tracking parameter changes, intelligent errors bundling etc, which i am sure will be coming in the later versions.
PI7.1 has come a long way from XI2.0 days. But the challenging question that most of the customers will be asking themselves is what is the pressing business driver to support PI7.1 upgrade from PI7.0. The answer to this is quite simple, PI7.1 will be worth the cost of upgrade not for the cool features, not for governance, not for ESB, BUT for the enterprise services content that you will get out the box. Every requirement where there needs an integration with a backend SAP system has a related services content eliminating the need of custom development (this also requires the back end systems to up to the required Enhancement Patches). The biggest difference from 7.0 to 7.1 is advanced adapter and direct connection which when used in proper places will result in high performances. So is PI7.1 upgrade worth while? Sure if you want to leverage on SAP delivered content there by reducing the amount of custom development support costs. In the end you are the best judge on the decision of the upgrade, it is a wise investment into the future that would enable we the customers to be more agile and focus on business processes versus propietory interface development. To conclude PI ROCKS