* Building a business case for SAP: BW
* Building a business case for SAP: Netweaver
Q: "I'm the IT director for a mid-sized business. I have to give a presentation for the front office next month,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
where we'll discuss whether service oriented architecture is the right choice for our organization. We are already running plain-vanilla SAP R/3. Can you help me design a business case for SOA?"
SearchSAP.com expert: SAP NetWeaver, ESA and EAI
If you're working with NetWeaver or considering SOA or ESA, you'll love the advice from our resident expert Axel Angeli. Axel has worked with SAP since 1991. He is the founder of Logos! Informatik (www.logosworld.com), a platform for a small group of technically-oriented freelancers. After working for many years in different IT-sectors in Europe, South-East-Asia and North America, Axel is now dedicated to SAP-centric Enterprise Application Integration (EAI) and complex messaging and automation scenarios in the SCM arena.
Click here to browse SAP NetWeaver, ESA and EAI advice
A: Today I'll cover, in a nutshell, the essentials of SOA and ESA and why you need to rely on it for the future of your business. I'll provide a brief on SOA and ESA for the IT director or CIO of a mid-sized business.
You can follow along with a PowerPoint presentation available here. Simply reference the slide numbers throughout this text presentation.
"Whether it is nobler in the mind to suffer the slings and arrows of outragous fortune or to take arms against a sea of troubles and by opposing end them."
-- W. Shakespeare: Hamlet, Prince of Denmark
What is service-oriented architecture (SOA)? (Slide #4)
SOA is the effort to transform software applications into small services so that their functionality can easily be used by external applications. The key to achieve this is to agree on common interface standards while simultaneously breaking applications down to self-contained modules.
Today we have a situation where most applications are wildly-grown hybrids where detailed functionality is hardly reusable and interfaces have to be explicitly written for every new communication. Breaking applications down to modules is the declared goal of the Object Oriented Programming (OOP). The SOA caters for common interfacing and communication standards in addition to a standard set of service functionality for public use.
The era before SOA (Slide #5)
The promised benefits of ESA (Slide #6)
SOA will not only eliminate redundancy but also dramatically enhance data quality, accelerate data discovery and allow for innovative customer services. Ergo -- save money and get more sleep!
The two main reasons to transform your IT for SOA are enhancing the reliability of work and erasing unnecessarily redundant technologies. Both goals are mainly achieved through establishing a common reusable infrastructure ("services") along with a flexible common interfacing standard ("traffic code").
An analogy: Communities (Slide #7)
Airplanes are steered with wired rudders, and go carts with pedals, but automobiles are controlled by a steering wheel everywhere. The greatness of civilization is the creation of habitats or communities that share services and infrastructure for common needs. It saves a lot of money if a road is built and houses are erected along side instead of building a private road to disparate farms. The set-up of common traffic rules guarantees safer and efficient flow of circulation. It is also not a law of nature that the petrol all over the world adheres to a common quality standard or that the tires built for Volkswagen in Germany can also be mounted on a GM vehicle in US.
Today we have a situation that we can liken to the situation of having vehicles that are all completely different to operate. One automobile might have a steering wheel while the next one is steered with wires (like airplanes) and another one accelerates with a manual gear and the direction is controlled with some pedals.
An analogy: IT habitats (Slide #8)
Any IT habitat can benefit from common standards and a growing number of services. The areas where the infrastructure comes in are the exchangeability of programming languages, the portability of code across hardware technologies, common communication protocols for distributed service calls and a harmonized way to access low-level services via APIs (e.g. database are accessed via openSQL or ODBC, which in turn translates the data access requests in the database's native language).
Business cases (Slide #9)
With the benefits of real-life infrastructures in mind we can easily discover a number of business cases where the introduction of enterprise services caters for a similar symbiosis. Depending whom you addressing there are different areas where a clear and nominal benefit of SOA lies compared to traditional static and insulated IT.
Consolidation of interfaces (Slide #10)
Current landscapes are dominated by wildly-grown and loosely-coupled interface activities that make efficient resource housekeeping nearly impossible.
The most evident and immediate return of an investment would be in IT administration by reducing the number of technologies to look after. The benefit will not only be a reduction of costs but also a push in quality because your powers are concentrated to some few sites.
Traditional application integration (Slide #11)
Traditional interface landscapes are dominated by proprietary interface formats and an abundance of peer-to-peer interfaces. Most of them are wildly grown over time and need to be cleaned-up in the near future.
Many interfaces are not state-of-the-art anymore, relying on offline data delivery via uploads and downloads of files along with subsequent FTP file transfers. Most interfaces are developed on demand and do not reuse common components, leading into a complex maintenance trap.
Steps to interface consolidations (Slide #12)
The first step to consolidate interfaces is to reduce the number of peer-to-peer connection by routing communication through a middleware. This will make the interfaces comparable with each others and clear the way for delegation of common services to reusable components like archiving and monitoring. Ideally the number of interface formats should be reduced to a minimum, but this something that is not realistic when dealing with legacy applications. Finally you will introduce automated procedures and patterns to fulfil repetitive tasks and ease the work of the administrators.
Benefits from consolidation (Slide #13)
The two main benefits of consolidating interfaces are the reduction of administrative work and enhancing the quality by reusing components. The fewer components exist and the more often they are used from independent sides, the better they can be tested and their reliance guaranteed.
Business activity monitoring (BAM) (Slide #14)
SOA is the pre-requisite to allow a real-time discovery and tracking of business activities. Management will delight in a completely new dimension of BAM. The keyword is "real-time." Other than many current BI systems, the SOA-based BAM will not copy data in batch mode from one data tank to another but analyze, aggregate and spider data right at their original source and the very moment the data occurs.
Benefits of BAM (Slide #15)
Process automation (Slide #16)
Automating processes is the elementary goal of a SOA. Compatibility and real-time data provision are the dear grounds on which process automation can be built. Some might see automation primarily as a job killer, intended to reduce labour costs at any price. In fact, automation is not more than a crutch to assist humans where the capabilities are limited. Automation caters mainly for speed and accuracy of data flow. RFID, barcodes and 24/7 data observation are the real applications for automations, fields that you might never consider tilling if you required humans for it. And where computers talk directly with each other there won't be a need to print a document on one end and type it in for another applications.
Benefits of process automation (Slide #17)
Automation bears a lot of obvious and hidden benefits. Of course will it accelerate the data flow and also enhance the data quality. But it will also allow the use of innovative data sources, think of RFID, OCR, sampling devices or electronic vision. Common protocols, development and debugging tools are just a side-effect but one that tremendously facilitates t administration and development work.
Innovation enablement (Slide #18)
SOA will build the infrastructure for completely new business that are not possible with traditional means. Once you get beyond the thinking that dismantling your business by reducing the number of staff is a way to prepare for the future, you are set in the winner's lane! Automation and real-time data discovery will enable you for innovation.
Where is innovation? (Slide #19)
Business like eBay and Amazon.com are setting the trend. Close your eyes and surrender to your boldest dreams of what your business could look like by using automation and pervasive information to pioneer into new areas. Innovation will position your business for the future, it will make you lead your niche and those who stand behind will face a heavy sea. Innovation means agility, and agility is the core virtue of SOA.
Examples of innovation (Slide #20)
Automation and a good SOA framework will allow you setting up market places. Businesses that collaborate intensively with suppliers, e.g., using KANBAN or JIT strategies, could extend their already present data orchestra to a sales engine where not only your assembly lines will reorder and refill their supplies. All your suppliers along with your company could publish their offers in the web and open their logistics to the public, generating a new sales line.
An even better market place would be to offer your goods together with your competitors through a virtual market. That is mainly of interest for high-tech producers where technical details and not the price decide on the usability of a product or service.
Online services like live tracking, visualization of configurable assemblies and document self services are already today within the expectations of customers.
Risks (Slide #21)
There are few risks in implementing SOA, but painful penalties in failing to do so. As for the question, SOA or not SOA?, SOA is one of the new upcoming technologies where it is not a question of doing it or not. SOA bears a lot of chances and the risks contained are surprisingly low. SOA will be a necessity, and that means that failing to implement the ESB in time will hurt your IT efficiency and business capabilities painfully.
SOA technology is still in its infancy, so waiting for software to mature may be wise. The art is to find the right moment -- coming too early might be expensive, coming too late disastrous.
Compared to this the factual risks are laughably minor. Information abundance might tie up hardware, software and human capacities that could be needed otherwise. Security risks with all their consequences and liabilities are common to any networked environment, hence they cannot not be generically attributed to SOA.
Is SAP NetWeaver ESA a wise choice? (Slide #23)
Although SAP's current SOA activities around XI are behind the competition we assume that it will be the technology leader by 2009.
The SAP Exchange Infrastructure (XI) is currently a middleware tool like many others. Compared to the technology leaders it is not too thrilling and if you needed a simple mapping and workflow tool XI would probably not be the leading edge. But it appears that while the lions are asleep SAP is planning the big bang.
XI today (Slide #24)
Today, SAP XI is still an ordinary middleware that needs to defend its place against strong specialized players like TIBCO, IBM (Datastage TX/Mercator, WBI, Notes etc.), Microsoft BIZTALK, SUN SeeBeyond, Seeburger, Fiorano, MantaRay, VSB (Very Simple Bus) and a good hundred of others. XI is a heavily developing and changing system. The hybrid concept between ABAP and J2EE is not a plus for XI -- wouldn't it require skills in both worlds? The design and mapping tools are definitely not state-of-the-art compared to what is possible and the installation procedure is far from satisfaction. Anyway, the engine is ready but a market for ready-to-use solutions is still sparse. Although the price of XI is pretty competitive, it appears strange that SAP does not have the courage to pack it immediately with ERP what would make it ready-to-use.
ESA tomorrow (Slide #25)
Under the code name "New York," a new middleware framework emerges based on SAP's reliable runtime paired with a visionary service infrastructure. Assuming that NetWeaver ESA will be available by early 2007 we expect a walkover of NetWeaver ESA to take the uncontested leadership in SOA by 2009. A visionary approach with a message queue, an Enterprise Service repository and the XI workflow engine and adapters will deliver a transparent and easy to handle SOA framework. With its integration into the SAP ABAP runtime, users will benefit from the unique features that made SAP the uncontested leader in ERP.
We expect ESA to be available for a broader audience sometime in 2007. Giving them a lead time of two to three years, we presume to see SAP leading the pack by 2009.
How complicated is an ESA implementation with R/3? (Slide #26)
Let's take a look at the road map to ESA to help you understand how easy or complicated an SOA adoption might be for your enterprise.
ESA enablement of existing R/3 (Slide #27)
Any R/3 system is already well-prepared for the service-oriented architecture (SOA), naturally for ESA. The built-in workflow engine is present in release 3.1 and later, BAPIs cater for a wide degree of automation, RFC allows calling BAPIs and more functionality and the Internet Connection Framework gives access to HTTP in both directions. If this all does not help then you may create RFC proxies on the OS level or simply install XI as the middleware proxy.
ESA prerequisites for non-SAP systems (Slide #28, 29)
What do you need to make a legacy application fit into an ESA landscape? Legacy applications and R/3 systems are best connected through a middleware that understands the generic protocols of all the participating applications. This means the middleware should be able to make RFC calls and also act as RFC server. Applications with shrewd protocols are assumed that they at least can communicate via HTTP in both directions. And if nothing helps data can be exchanged through up_ and downloading files while shuffling them around with FTP.
Good luck to you,
Learn more in the PowerPoint presentation for this tip available here.
About the author:
Axel Angeli has a reputation as platinum EAI mentor and Netweaver evangelist. He is an SAP old-timer since R/2 times and waves the ABAP banner convincingly. His knowledge is founded on his legacy as lead IT architect in process industries (chemicals, steel). He shares his insights and analyses as author of best-selling books and whitepapers. His publications appear on sites like. SAPtips.COM, SDN.com and SearchSAP.com. As an international speaker and with his own expert column in SearchSAP.com, he is known for his brutally honest opinions when it comes to sort sense and nonsense in IT technology. Axel is a part of The Blue Elephant League.
About The Blue Elephant League:
The Blue Elephant League is a group of business analysts and advisors that have specialized in the fields of ESA and EAI.