SOA-based Applications and Infrastructure--The Next Frontier?

SOA, The Next Frontier

The current, rapid pace of global business places a unique set of challenges on all enterprises looking to improve and automate their operations. At the same time companies must also be poised to adapt quickly to change. Growing competition, deregulation, globalization, compliance requirements, merger and acquisition activities, and outsourcing, coupled with supply chain structures and stringent mandating requirements from dominant customers, such as Wal-Mart are some of the main challenges facing companies. These are critical changes, but are often slow to implement because of the complexity of making their information technology (IT) systems support the new business model. In many cases, the workhorse IT systems need to be completely bypassed and provide no support at a time when that support is most critical. Consequently enterprise software buyers have increasingly realized that product architecture plays a key role in how quickly vendors can implement, maintain, expand and customize, and integrate their products.

Product architecture must do much more than simply provide technical functionality, user interfaces (UI), and platform support because it will determine whether a product will endure, be scalable to a large number of users, and whether it can incorporate emerging technologies to accommodate evolving user requirements. As a result, most application vendors are now preaching integration, advanced functions, and technology. However, these should not only be a part of the new enterprise structure, but should offer us lessons for the future.

In a past series of well-received articles, called What's Wrong With Application Software? we discussed the realities of agile business versus the ability of contemporary application software to cope with those realities. Those realities included

1. Economics. Across the application life cycle, there is a high cost of development, support, and enhancements. Money, time, and quality limit how installed software can meet the many demands of business. While older product architecture is a technology problem, the cost, in terms of time, money, and quality is a business problem. For these very reasons, modifications, for example, are considered bad. Yet, with the changing economics, custom or modified approaches may still be more practical, although they will always cost more in the long term. For more details, see What's Wrong with Application Software? It's the Economics.
   
   
2. Business change continually. Software must be an enabler (rather than an impediment) of business change, both during initial deployment and across its life cycle. The current state of the market is "standard, configurable" applications, because of the fallacy that applications can bring "best practices" and be flexible enough to accommodate the majority of businesses without significant modification. Although through complex tables, parameters, and switches, software can be pre-configured to handle a large number of pre-determined, "flexible" options, this flexibility means choosing from a list of existing, predetermined options. Thus, while the issue of flexibility might have been solved for an initial implementation, it is not be the case for the ongoing business innovation. The next generation of enterprise architecture must allow for change on-demand as a business evolves. For more details, see What's Wrong With Application Software? Business Changes, Software Must Change With The Business.
   
   
3. Businesses are unique. All businesses have unique elements. Yet, instead of evolving, one-size-fits-all application software tries to supports too many conflicting features for different industries. Furthermore, many of the added functions apply to only a few of the various industries it caters to, meaning that other industries must suffer the consequences of software bloat resulting from non-essential features. Complex program logic is needed to determine which of many paths the program must take, instead of executing functionality. To remedy this, vendors need to build lean products that serve specific sets of customers plus allow the customer to build in their own, individual needs. For more information, see What's Wrong With Application Software? Businesses Really Are Unique—One Size Can Never Fit All.
   
   
4. Business processes, not application boundaries. The next generation of application architecture must address the reality that business processes cross application boundaries. Business processes must be enabled across the artificial boundaries of disparate applications that must work together to support business processes. The architecture will need to provide business process integration, application integration, and application extension in to give companies the full potential of their current applications. With all of these capabilities, the new architectures will initially be used to pull together diverse applications to create an effective composite application. Eventually, the next generation of enterprise applications will also embrace these architectural capabilities in the application itself. For more information, see What's Wrong With Application Software? Business Processes Cross Application Boundaries.

Apparently, many vendors in the enterprise applications community recognize these needs need to be met and are attempting to offer solutions. Also, for some time now, the likes of Microsoft and IBM have been telling customers it should soon, if not already, be possible to build integrated, cross-functional applications without investing in major new packaged systems. By using existing and new Web services and components, and new technology and services from these vendors, companies will supposedly have as much flexibility they need.

This is Part One of a three-part note.

Part Two will discuss SOA as a foundation for a universal desktop for all the Web-based applications of an enterprise.

Part Three will look at the future.

Accelerated Pace of Software Development

The software world is becoming one where powerful new applications with all the functions of underlying business software suites need to be built in days or weeks. Business people, rather than nerdy programmers or territorial technical personnel, have control, and the functions from many diverse applications are frequently combined. To build an intricate, cross-functional application based on disparate extended enterprise resource planning (ERP) software, users may also want to only use standard, intuitive, customer or end user-facing tools, such as the portals, business intelligence or analytics tools, Web browsers, forms integration, Microsoft Exchange, Microsoft Excel, or various search tools. They will not have much use of underlying proprietary and cumbersome routines, languages, or interfaces, which have traditionally been part and parcel of current enterprise applications. Hardly any enterprise application will remain completely inside Microsoft Office or a particular ERP product. It is highly likely that any application built in the future will have to touch many disparate but necessary applications.

Consequently, almost the entire software industry has been abuzz with the concepts such as the service oriented architecture (SOA), also known as enterprise services architecture (ESA) in SAP's jargon). Composite or cross-applications (or SAP xApps, again is SAP's terminology) and business process management (BPM) are also afloat. All of these should give customers more power over their software and business processes. See Understanding SOA, Web Services, BPM, BPEL, and More.

The move to SOA is one of several enablers that will help enterprise applications handle and even accelerate business change. For one, most of the relevant technology players have come together for the first time with an agreement on the standards and protocols that enable Web service communications. Hence, systems based on Microsoft, Sun, or IBM technology now have the "plumbing" to interoperate. An analogy is that a reliable phone line has been established and calls can be made by direct dialing between platforms, although callers still have to agree what language they will speak in.

Secondly, and equally important, is the granularity that Web services target. The general model is a document-centric approach, not a lower level granularity proposed by previous, less successful component models, such as common object request broker architecture (CORBA) and common object model (COM). To make communication between disparate systems practical, the level of granularity is critical. If one can think of systems exchanging documents the same way business people exchange the yellow copy of a five part order form, one might achieve a model that can effectively be built and maintained. Web services is well-suited for this model.

While it is not practical to look at every strategy and every vendor's nuance, Oracle and SAP seem to be on a collision course with their respective Fusion (a recently re-branded middleware stack) and ESA endeavors. Microsoft Business Solutions (MBS) may be on the same track, although its equivalent code, called Project Green, seeking to converge all disparate MBS ERP products into a single code, has seemed to have backpedaled right now. This is, in part, because of delays in finishing Longhorn, the parent Microsoft's next-generation operating system (OS) environment. More importantly, it has been redirected from an effort focused on delivering a unified code base on one that embraces the focus on process, change, and service orientation.

Microsoft .NET Ecosystem in the Lower-end of the Market

As a means of giving customers the flexibility that extensible markup language (XML), Web services-based Microsoft .NET promised, many smaller vendors like Intuitive Manufacturing Systems, Epicor Software, Made2Manage Systems, and SYSPRO, are converting existing functionality within their ERP suites into Web services. These can be linked with other applications to create new business processes fairly easily. These vendors may only differ in terms offering solutions completely from scratch, or in a more judicious manner (for more information, see Rewrite or Wrap-Around Old Software?).

Interestingly, MBS is taking a deliberate approach when it comes to moving its own applications to the .NET framework. So far, it has a new Microsoft CRM (customer relationship management) product completely developed on .NET. For ERP and accounting solutions, which includes Great Plains, Navision, Solomon, and Axapta, the focus is on .NET's ability (with the support of Web services) to provide a unified environment for partners that develop product extensions. Moreover, at a recent MBS customer partner conference, MBS announced that the waves caused by Project Green will enable partners to use .NET tools and its languages to build extensions for ERP Web interfaces. Also, by targeting Web service interfaces, MBS partners will be able build these extensions in such a way that will provide simpler portability for future releases. The second Green wave will move the core logic of the ERP application and all of the tools to .NET. Right now, MBS is using .NET technology indirectly. It is exposing current applications through XML and Web services to allow customers and independent software vendors (ISV) partners to integrate their current applications with .NET. Such a strategy allows middleware and integration tools built on .NET technology, such as the Microsoft SharePoint Portal Server, and Microsoft BizTalk Integration Server, to be leveraged.

Yet, from all of these developments, one thing is certain: all leading and relevant vendors believe it is important to quickly complete the transition from large, monolithic client/server architectures to SOA. For the "Big Few" (large vendors with a notable customer base) it is also important to intensify the "stack" race, which includes applications, databases, application server, and middleware. Having seen Oracle's research and development (R&D) team bolstered by the recent PeopleSoft's acquisition, SAP reportedly plans to add another 1,000 developers in 2005. The timetable now calls for SAP 's ESA roadmap to be completed by 2007, with the entire product suite and all industry-specific products available in a future version of SAP NetWeaver that will support BPM and orchestration. SAP's grand ESA project will expose underlying functions and data from deep within its extended-ERP mySAP Business Suite of applications (mySAP CRM, mySAP PLM, mySAP SRM, mySAP SCM, mySAP ERP, etc.) It will make them available as services (software components) which can be plugged together—along with those from other applications.

For the next three years or so, SAP will also embark on breaking its enormously broad collection of application functionality into a manageable portfolio of configurable process components. SAP developers, customers, and business partners will be able to use SAP NetWeaver to create tailored processes that fit a specific need, integrate to an existing environment, or offer a differentiating value proposition. This way, customers and partners can build new, composite applications, and find more flexible ways of working with existing applications.

Technology Infrastructure and Applications Functionality

The main battleground will be "appli-structure", which, as the name implies, is a combination of technology infrastructure and applications functionality. In SAP's case, this is currently defined by SAP NetWeaver and mySAP Business Suite. In the future, it will be defined by a componentized, process repository-driven, Web services offering sitting atop a significantly enhanced SAP NetWeaver. NetWeaver will thereby evolve from a mere technical application integration platform to a business-oriented process integration platform, referred to as composition platform or business process platform (BPP).

In other words, SAP is continuing to change SAP NetWeaver into a BPP that will eventually provide a set of ready-to-use enterprise services and will be an infrastructure capable of deploying and managing enterprise services to create composite applications. Its vision, which will unfold over the next few years, will be determined by the SOA and process modeling environments, which, in turn will define the future of enterprise software. The aim is to create reusable processes at the application level that will combine with the platform (hopefully SAP NetWeaver). This with the idea of mastering data and process integration to support innovative and agile business strategies.

Despite being regarded as a stodgy giant, the vision of breaking the enterprise application suite into a portfolio of configurable process components has been a key part of SAP's strategy for many years. Work began on this radical renovation as early as 2002. The strategy has been to turn mySAP Business Suite into an SOA application within five years. This endeavor is driven by the integration hub, SAP NetWeaver, formerly known as mySAP Technology. In fact, SAP NetWeaver is the evolution of mySAP Technology with major modular enhancements, such as master data management (MDM) or knowledge management (KM), all on open standards. The next step is to move from SOA-enabled to SOA-based business solutions. This move is a change from data level integration to a message-based level, which becomes more complicated when the architecture has to include customers, suppliers, channel partners, and other trading partners.

Additionally, it is not widely known that the "necessary evil" of opening up SAP's enterprises suite has been going on for almost a decade, in one form or another. Namely, Hasso Plattner, the former chief executive officer (CEO) and technical visionary of today's SAP, announced to an unconvinced and astonished audience at a 1995 user conference that monolithic SAP R/3 would be opened up and broken down into smaller pieces. SAP made it possible for parts of the monolithic suite to run separately, but the interfaces were still proprietary, and the binding between the programs was tight and at a low level.

Later, the business-to-business (B2B) collaboration surge of the early 2000s inspired SAP to open up its applications even further. Its product suite, then temporarily called mySAP.com allowed non-SAP applications, such as Microsoft desktop productivity tools or Internet marketplaces, to be closely incorporated into the user experience, as though they were a part of mySAP.com. But again, this required hard-coding links and functions into each participating system.

To put this into context, one must remember that an application program interface (API) is a set of routines, protocols, and tools for building software applications. A well-designed API makes it easier to develop a program by providing all the building blocks, which a programmer should be able to put together. Most operating environments provide an API so that programmers can write applications consistent with the operating environment. Although APIs are designed for programmers, they are ultimately good for users too, because they guarantee that all programs using a common API will have similar interfaces, which makes it easier for users to learn new programs.

SAP's 2001 takeover of TopTier, a US/Israeli portal software company, provided SAP with a key part of its integration and componentization hub. It also brought Shai Agassi, a current SAP executive board member who is generally seen as a new technical visionary at SAP (see SAP Acquires Top Tier to Further Broaden Its Horizons). An indicator of SAP's commitment to SAP NetWeaver, ESA, and BPP came in a recent company-wide reorganization, when Agassi, who had been heading up development of SAP NetWeaver, took over product development and marketing for all of SAP's business applications as well.

Web Services

But greater, or at least equal, importance was the emergence of widely accepted Internet standards such as XML, Web services, .NET, or Java Messaging Services (JMS). Thus, emerging Web services technology standards should generate more awareness about the component-based applications concept and speed up its still fledgling adoption. Endorsement of Web services technology by large vendors may even help them make up for their latency in endorsing the component technology several years ago.

As previously mentioned, Web services has the potential of becoming the latest evolution of application integration technology or even a revolutionary new application design model. It can enable developers to create or enhance applications by connecting granular components that are accessed via platform-independent Web protocols. While developers leverage the established concept of objects' reusability, they may finally offer an extra mile by adhering to standards that are taking hold—the support for standards is indeed what we see as the key difference between the less successfully adopted CORBA architecture and the more promising Web services. CORBA was developed by an industry consortium known as the Object Management Group (OMG), and enables pieces of programs, called objects, to communicate with one another regardless of what programming language they were written in or what operating system they are running on. Web services, however, can wrap around virtually any type of existing business functionality. Further, Web services tends to be simpler, partly because of Internet standards, and because it also tend to be a higher-level abstraction, implying a greater likelihood of platform independence and "mixing and matching" opportunities for developers.

Accordingly, the strategy will help the likes of SAP and Oracle further open or componentize their products, as standards like XML and extensible stylesheet language (XSL) make it possible to share data and have a common look-and-feel across an application, without necessarily dreadfully digging in the source code.

This concludes Part One of a three-part note.

Part Two will discuss SOA as a foundation for a universal desktop for all the Web-based applications of an enterprise.

Part Three will look at the future.

About the Authors