Yesterday we had a meeting with f5 guys at HP’s office at Stockholm. HP is now investing a lot on Networking and trying to dominate the enterprise networking market. While at the same time F5 helps organizations create an agile IT infrastructure that aligns with their business demands.
They demonstrated what f5 WAN Optimization might be able to do for international companies. Just like most IT organizations with multiple locations connected by WANs, networks are stretched beyond where they should be, and they suffer from latency issues. The result is poor user performance for the kind of applications (Exchange, SharePoint, SAP etc.) that run in nearly every enterprise. (more…)
I made an easy to understand definition of what internal (private) cloud and public cloud are. As I mentioned in my previous entry, I personally believe that we will see more and more internal cloud projects coming up in the market soon. Once this step is done, people will start connecting their internal clouds to each other or to external clouds. Then this will be the real cloud hype; a mix of internal and external clouds.
I think a sushi piece is a quite good example of an internal (private) cloud. Because it is a unit, which consist of server, storage, network, power& cooling, management software, infrastructure consultancy and support services and they all work perfectly together. Since business is changing because of some reason; competition, market regulation or any other reason, internal clouds will not be enough for business requirements. Once people need to connect it with other cloud stacks in the future, other internal and/or external clouds, then they will create their own plates, depending on their requirements, filled by different types of sushis, which will work perfectly with each other.
I have presented my master thesis last week and started to work for HP as a junior product chef. I have spent more than 4 months to complete my master thesis and the most single difficult part for me was the writing part. I think it is crucial to have good communication with your academic supervisor, since he/she decides how you should write and how much you should write. After this master thesis I began to abhor the communication problems. Giving an example, I wrote 100 pages at the beginning and spent almost 3 weeks to write it, then my supervisor wanted me to cut it down to 30 pages (max.). It was a very big hassle. Moreover, my supervisor did not want me to do those changes with alacrity. Because of that I had to wait two more months before I present my master thesis. Any way it is still good that I have the rights to decry my supervisor and my own work. By the way, my academic supervisor was Gustaf Juell-Skielse from KTH and he is a very experienced Accenture consultant. I have learned a lot from him and he has incisive comments which make me work harder and harder. But my recommendation for those of you, who will write master thesis, is that; talk to your supervisor very very clearly at the beginning. What he/she wants you to do, how much and how does he/she want you to write and so on. Because time management is difficult and you might waste your time if your supervisor changes his/her mind.
However, it was a priceless experience to work in one of the biggest energy companies at Europe and has an experienced academic supervisor back at school. Even if I had some difficult times to finish my thesis, I liked it and enjoyed a lot. In case you need, I am sharing my final master thesis (believe me, this is the real final version:) ) and my final presentation down here:
I have written my master thesis about SAP systems integration at one of the biggest energy companies in Europe. The company is called Vattenfall and owned by Swedish government. Since the size of the company is large, so that the data size which will be transferred within and outside of the company is also large. Thats why systems integration plays a very crucial role in Vattenfall’s IT concerns. The company is very much SAP centric and the SAP systems are increasing in number and size. This increasing trend intensifies the need for SAP systems integration and an integration platform, which is the most plug and play integration engine for SAP systems, could be of benefit. That’s why I made a qualitative study to evaluate SAP NetWeaver PI to help Vattenfall Nordic to decide whether it can be used as main integration platform at Vattenfall Nordic instead of BizTalk.
SAP PI is coming! I think the product will be used more commonly once SAP solves the core problems. For example SAP PI is a dual stack product and complex to configure, use and manage. The product is very much based on hub and spoke, centralized architecture. But I think it must be (will be) 100% java based, distributed product. Also SAP NetWeaver BPM and PI are emerging more and more. These are all good things for the future of the product. As I mentioned before, PI is coming and will be used commonly in SAP depended companies!
I finally finished my master thesis and wrote my final report. Originally it was 100 pages and now I am trying to cut it down to 35-40 pages. As a summary my final thought about SAP PI are that;
It is crucial to understand the companies’ application landscape and then make a final decision to go for one integration platform. Because in fact, it is really difficult to say PI is definitely better than BizTalk or vice versa. Giving an example, many large SAP customers already selected an integration platform. But, they also know that PI (XI) is required component of some SAP modules. Therefore they try to understand the product and decide how much they are going to use it. As far as seen on the market, they are introducing SAP PI along with their established integration platform, mostly to support SAP-to-SAP integration scenarios. Where this looks like an advantage, most of the other companies do not want to deal with two different integration platforms. In this case, if a company wants to adopt their integration platform strategy with SAP, gradually moving to SAP PI is the best way to go for by 2009. Because, as a result of the research, SAP NetWeaver PI will have a revolutionary change and this might cause serious problems for old PI investments. In addition to this, it is for sure that replacing all BizTalks with PI is not really a strong business case, because PI is still not a perfect product and needs a bit more real life experience.
After 4 months of research about SAP NetWeaver PI, the researcher makes two predictions about future of SAP PI;
1- PI will be 100% Java based product. It means, SAP will re-write the ABAP part or make an OEM agreement to replace ABAP with an already available solution in the market.
2- Currently, PI is based on hub and spoke, centralized architecture. First development of XI (PI) started as a part of MySAP technology but right now SAP has NetWeaver which is more distributed, SOA oriented base technology. So, XI is not a perfect match since it does not support distributed architecture. Because of SAP’s eSOA strategy they need to make integration based on more distributed architecture. By doing that they can dramatically reduce the total cost of owner ship and increase availability and performance. So, this will also cause a major change on product.
These changes can be done in two ways;
1- SAP will outsource PI to some other middleware company but will continue to development of this product. Because they already sold PI or XI to 50% of their large SAP users and they cannot suddenly stop supporting the product. Also, PI is playing a centric role for SAP’s ESOA strategy. So that, if SAP wants to be successful on this, they have to pay more attention to integration since this is one of the most crucial part of ESOA mentality.
2- SAP will buy another middleware company or make an OEM agreement to add their solution to PI in order to make it 100% Java based and distributed architecture based more open product.
So, it is important to keep all these in mind before making a buying decision. As mentioned before, a radical architectural change on PI, rather than an incremental evaluation, is expected. In order to mitigate the risks, it is recommended to be careful where companies use PI right now. For the time being, it is recommended to use PI within SAP landscape and for opportunistic applications, which means not mission critical projects. Also, make a good calculation about ROI. If it is 10 years, changing already established integration platform to PI is not recommended.
To sum up, both integration solutions have bad news – good news situation. As PI adoption grows, SAP will invest more into this technology. But if they want to penetrate into the main market, they have to enrich the functionality of their solution against competing integration platforms. Because current picture clearly shows that PI is dominantly used only by SAP customers. While this can be seen as a success, there are still lots of miles to go for SAP. Both integrated middleware approach (SAP PI) and best of breed approach (SAP PI + MS BizTalk) has pros and cons. So, it is up to company to decide which way to go. As mentioned earlier; unlike “Who Wants to be a Millionaire,” there is not a “final answer” to this ongoing debate.
I am working towards my master degree thesis about SAP systems integration and at some point I needed to learn the easiest way to explain what is SAP NetWeaver and what is the systems integration. While looking for some boring PDFs I have found this video, which is much more fun to learn from, and wanted to share it with you. Enjoy !
Adoption of SAP PI platform is growing rapidly, primarily for SAP’s application customer base. However, despite SAP’s crucial improvements, PI is still lacking of most-advanced platforms’ abilities. But it will still be used commonly by SAP base customers.
Graph below, shows the roadmap of SAP PI starting from SAP XI versions. From my point of view, there are 3 major versions of product. Phase 1 is SAP XI 2.0 and SAP XI 3.0, phase 2 is SAP PI 7.0 and phase 3 is SAP PI 7.1. SAP invested a lot of engineering hours for PI and tried to provide the most up to date features in it. But, like all the products in integration platforms market, PI has some pros and cons.
Graph 1: SAP PI product versions
In particular, SAP PI is proven as SAP oriented product and is widely used by SAP customers. According to a statistic from SAP, only 5% of the PI or XI users are non-SAP customers. So, it clearly shows that PI is very SAP centric product and fits better to SAP product portfolio.
On the other hand, well known vendors like IBM, Microsoft, Tibco, Sun Microsystems are functionally richer than SAP PI because they focus not only to SAP but also to other application packages. For example they provide much complex event processing, business activity monitoring and other advanced integration features. However, PI is highly optimized for SAP systems and provide much more pre-built integration metadata and it is more similar to SAP systems.
SAP PI license for SAP-to-SAP usage is included in NetWeaver 2004 suite license and MySAP license. For SAP to Non-SAP integration PI base engine is priced based on the overall processed message volume expressed in Gigabytes (GB) per month. For some large SAP customers, special discounts are available and price mentality of SAP is “more you use less you pay” (we can also call it progressive scale).
To match PI with Microsoft BizTalk technology, please refer to the graph 2 below.
Currently I am working on my master thesis at a Swedish energy company, called Vattenfall. One of my responsibility is to gather customer requirements and evaulate them. I just started to work on this topic and i am not the expert (yet). But, I want to share some important tips that I observed how things happening.
1- People factor and communication skills are the most important things.
2- People are busy and they dont like having extra meetings, until they really need it.
3- IT people does not uderstand Business people and vice versa.
4- Use the power of questions.
By capturing correct and complete project requirements, you can better satisfy your project stake holders’ needs, manage their expectations, banish scope creep and assure project success.
And finally recognize the difference between requirements and design specifications