If I look at the service-oriented architectures (SOAs) my clients have implemented over the past three years, I find that technology has advanced faster than business thinking has. Today, technology can drive the market and provide new ways of modeling business activities for one reason – services. IT has the tools and capabilities it needs to build service-enabled systems, and businesspeople describe their own value in terms of the services they offer. Now, you can pick and choose the software components you want to use to build solutions.
For example, the Web reporting deployed in SAP NetWeaver Business Intelligence (SAP NetWeaver BI) is a feature you can access via SAP NetWeaver Portal simply by installing it as a service. Both the portal and SAP NetWeaver BI have the same infrastructure and platform. You don’t need to assign portal roles or install another server; just choose the services you need to design your solution. SAP NetWeaver 2004s contains an advanced integrated set of components with the building blocks you need to construct Web and enterprise services for both business and technology deployments.
Timing Is Everything
A service-oriented approach requires you to question each and every business function and existing business process in a way that leads to creating new models based on more independent encapsulated services. IT can Web-enable a service and then deploy it using standard Web functionality. Services that support business practices can bring IT into precise alignment with the business’s needs. Existing business processes that an application supports can stay in place, but services built on top of applications enable enhancements.
For example, the railways comprise an industry isolated from the just-in-time (JIT) transportation movement that primarily affects trucks. Railroads by nature have a regional presence, and shipping departments lack the ability to schedule movements across these regions unless they have interline agreements with other carriers. With trucks you just drive from point A to point B. Typically, nobody owns the road. If shippers could compare rail expenses to truck costs when writing the orders and then contract for the right equipment, car connections, storage, safety, costs, and so on across regional rail carriers, confirm equipment, and track shipments, they could create excess capacity and achieve lower shipping costs.
With a service-oriented business model and architecture, this capability is just a composite application (xApp) that invokes a series of enterprise-level Web services. In this way, you can extend your business model and your business agility. You can also see the enterprise in terms of its services – both the internal and external services. An airline’s booking model, for example, might be enhanced with a service that allows the user to book an exit-row seat or a bulkhead seat at a premium price, which would create a new revenue model as well.
Justifying the Move
My research and client experience lead me to believe that you need to consider at least three major topics when estimating the return on investment (ROI) for SOA:
- Lower application-development costs are the result of reusable business and programming logic. SOA-based applications are designed to change according to standards and the granular definition of a particular service. For example, if you look at SAP Financials, you can think about credit management as a functional business component; you can consider credit-limit monitoring to be an enterprise service, and “approve credit limit available” and “extend credit limit” could be two of its possible operations.
You can encapsulate various pieces of enterprise functionality into services and later reuse them by combining them with other services to meet a new set of requirements. You can also expose business functions within SAP as services, such as invoice processing, personnel time management, and returns processing. In fact, you can expose any SAP R/3 or core function as a service; it’s no longer a “closed” world.
- Flexible deployment increases the choices that application managers have and provides many different benefits; for example, if a set of services supports the submission of a product design change, you may be able to use services to redirect the flow of functional (material, packaging, and pricing) modules without changing the original design-change request. By converting this request into granular services, you can route each functional element directly to the department or application that processes that particular design change.
- User-productivity and ease-of-use functions are common candidates for enterprise services and are particularly appropriate for building role- or task-specific user interfaces (UIs). For example, imagine a task that requires a user to enter data on 10 different screens. Perhaps a service that collects the data and enters it into an enterprise application via the appropriate transactions could reduce that UI to one screen. Then, users could do their work in a fraction of the time. The easier a UI is, the more people will use it and the less training it will require. When you transform a UI from highly technical to simple and easy, more people within a company tend to use it, increasing the value that the business receives.
In another example, let’s say you expose a simpler UI to outside partners, suppliers, or customers who can enter their data themselves or check on the status of various processes. Maybe each group of users would have a special interface to meet their needs. This sort of transparency and self-service may reduce the time typically wasted on handling unnecessary phone calls or dealing with emails that request information. Be aware, the enterprise service doesn’t create a new UI; enterprise services focused on user productivity enable you to create a new and better UI.
Another possibility would be if a set of services allowed different roles to each have their own UIs. To set them up, you would have to separate the UI components from the business logic. Such a functional decoupling would then let companies reuse business logic to a large degree, making it easier and cheaper to implement many role- and task-specific UIs.
Making the Move
Both technical and business-related components affect the ROI for SOA. To some companies the inherent value in a new technology is obvious and justification is a non-issue. For others, the ROI for a new technology varies with the maturity of the market. Understanding the topic and considering some of the various usage scenarios possible are both critical elements in making the move to SOA.
|Adolf Allesch is the global SAP NetWeaver lead partner at IBM Global Business Services. A pioneer with the Web and an early adopter of mySAP.com, he is now the SAP NetWeaver evangelist for IBM. He specializes in technology-enabled business transformation using SAP and is a frequent presenter at SAP events worldwide. You can reach him at firstname.lastname@example.org.