Introduction
The rapid pace of global business nowadays places a unique set of challenges on all enterprises looking to improve and automate their operations, and at the same time, remain poised to adapt quickly to change. With increased competition, deregulation, globalization, and mergers & acquisition activity, enterprise software buyers realize that product architecture plays a key role in how quickly vendors can implement, maintain, expand/customize, and integrate their products.
The product architecture is going to do much more than simply provide the technical functionality, the user interface (UI), and the platform support. It is going to determine whether a product is going to endure, whether it will scale to a large number of users, and whether it will be able to incorporate emerging technologies, all in order to accommodate increasingly evolving user requirements. If one is to listen to most application vendors today, they are preaching integration, advanced functions, and technology. These are lessons what should be part of any new enterprise architecture.
In TEC's recent intriguing series of articles, named "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, the high cost of development, support and enhancements
in term of money, time, and quality limit the ability of installed software
to meet many demands of business. While the aged product architecture is
a technology problem, it is not the business problem, which considers time,
money, and quality. Focusing on modifications as an example, the reason
that modifications are bad is that they take too long, cost too much and
often have quality issues. However, with changing economics, although custom
or modified approaches will always cost more, albeit less sharply, what
was impossible with traditional architecture may become practical for the
business with next enterprise architecture. For more details, see What's
Wrong with Application Software? It's the Economics. |
| 2
Businesses change continually |
Change
is a fact of life and software must change with the business. 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, since the fallacy is that these
applications can bring best practices to a business and be made flexible
enough to accommodate the majority of businesses without significant modification.
Although through the use of complex tables, parameters, and switches, the
software could be pre-configured to handle a large number of pre-determined,
"flexible" options, in truth, the flexibility is only to choose from a list
of existing, predetermined options. Thus, while the issue of flexibility
might have been solved for an initial implementation, it would not be the
case for the ongoing business innovation. The next generation of enterprise
architecture must allow for business change to be adopted on an on-demand
basis as the business evolves. For more details, see What's
Wrong With Application Software? Business Changes, Software Must Change
With The Business.
|
| 3
Businesses are unique |
Industry to
industry, company to company, all businesses have some uniqueness, and the
idea that one-size-fits-all does not materialize. Application software has
grown increasingly complex because it is trying to support too many conflicting
features for different industries. Application software needs to evolve
so that it recognizes the reality that businesses are unique, but not by
adding software bloat' to existing products. Many of the added functions
apply to only a few of the various industries addressed meaning that most
other industries must suffer the consequences of these non-essential functions.
Bloat, in the form of complex program logic is required not to execute the
function, but to determine which of many paths the program must take. Thus,
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 |
Business processes
must be enabled across the artificial boundaries of disparate applications
that must work together to support business processes. The next generation
of application architecture must address the reality that business processes
cross application boundaries. The architecture will need to provide business
process integration, application integration, and application extension
in order to allow companies to realize the full potential of their current
applications. With all of these capabilities, the new architectures will
initially be used to pull together diverse applications in a way that the
resulting composite application is better than the sum of its parts. 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 in the enterprise applications vendors' community recognize these unmet
realities and many are attempting to offer solutions that will deal with them.
While it is not practical to look at every strategy and every vendor's nuance,
let us look at some important examples representing distinct strategic approaches.
This
is Part One of a three-part trend note that will discuss three Strategies, as
follows:
-
Part One: Strategy One Evolve
-
Part Two: Strategy Two A New Framework
-
Part Three: Strategy Three A New Approach
Part
Three will also make User Recommendations.
Strategy
One Evolve
Most vendors have naturally chosen to evolve their existing application framework to meet these market needs. Evolving means a slower process where incremental changes are made to the existing architecture such that it eventually meets these demands. However, if history helps us predict the future, it is very difficult to execute this strategy effectively, and only the most resourceful and/or steadfast vendors are tipped as winners in the long run.
As
an object case, SAP's 3-tier client/server architecture introduced
in 1992 provided the fundamental structure upon which client/server enterprise
systems enabled information and process integration at the user, application,
and data levels. The 3-tier client/server architecture remains a highly-scalable
framework which provides the foundation for SAP business solutions today at
more than 19,000 companies worldwide. While the 3-tier client/server architecture
then abruptly replaced existing mainframe based systems, the latest SAP's technology
framework named ESA (Enterprise Service Architecture)
is instead devised to allow companies to gradually add important new levels
of flexibility while allowing customers to maintain and build upon their existing
solutions investments through Web services.
SAP's
recent announcement of xApps (read "cross-applications") would
also be an excellent example of an evolutionary strategy. With xApps, SAP is
enabling composite applications to be built more easily since xApps uses SAP's
NetWeaver infrastructure to tie other applications into SAP
applications (see SAP
Weaves Microsoft .NET And IBM WebSphere Into Its ESA Tapestry).
However,
SAP is leading a large pack of vendors that are also all headed in the same
direction. Namely, Oracle with its 9i Applications
Server (9iAS) Enterprise Edition, PeopleSoft with
its AppConnect, J.D. Edwards with its eXternal
Process Integration (XPI)/eXternal Business Process (XBP), Baan
with its OpenWorldX, IFS with its IFS
Connect, and Siebel Systems with its Universal
Applications Network (UAN) have all laid out pieces of their enterprise
platform roadmaps. Even some Tier 2/Tier 3 vendors like Cincom Systems
or Exact Software have been ringing the changes of their Business
Process Management (BPM) platform roadmaps with new intelligent capabilities
allowing the system to respond automatically to inputs or requests for information.
The role-based BPM component acts as an information broker, dispatching requests
and new inputs across the loosely coupled disparate applications and alleviating
(or completely eliminating) the need for dreaded point-to-point integration
programming.
However, the status of almost all above composite applications is that mere announcements have been made and we are now awaiting delivery. Building composite or cross-applications has not been an easy feat as shown by only a few of, e.g., SAP xApps developed so far. Most of them are still a figment of someone's imagination and will require much custom work until becoming tried-and-true and reusable. Each individual cross-application will involve sophisticated process modeling and process-level, data-level, and UI integration, and often it will involve creating and supporting a system of record that comprises data from multiple systems. Even after all that effort beforehand, the wide variety of technologies and formats of various independent software vendors' legacy solutions one can encounter in any new application for some cross-application, will inevitably mean some tweaking anew. The mitigating factor for some vendors, though, could be their narrow focus (not necessarily the case for SAP that targets 22 industries) and the longevity and a repetitive nature of their multiple partnerships.
What Winning Products Will Demonstrate
Winning enterprise products will demonstrate deep industry functionality and tight integration with best-of-breed bolt-on' products in a particular vertical. This also means adding sector-specific, fine-grained front-office or collaborative supply chain capabilities. Verticalization can be seen as part of a larger effort by enterprise application vendors to ease the implementation of their products. Software that combines industry-specific functionality with the flexibility to accommodate each company's unique processes goes a long way toward improving the functional fit and the speed of implementation. This pragmatic approach helps companies close the gap between system performance expectations and final results achieved
Another advantage lies in the fact that industry-specific, global enterprise solutions based on open architecture and proven technology standards facilitate faster integration of companies being acquired as part of a corporate growth strategy. Namely, while using implementation templates may provide a company with the jump start', these endeavors only support common processes that are likely emulated by the competition. For differentiation purposes, however, customers must give advantage to vendors that provide strong configuration & development tools and that have sound product interoperability strategies.
Thus, the above composite applications are a step further for customers that have long embraced the more open interfaces and improved integration capabilities that the enterprise applications vendors are providing, capabilities also intended for the product componentization (granulating) effort. During the past several years, enterprise applications vendors have opened up their tightly interwoven modules and created application programming interfaces (APIs) to connect to third-party best-of-breed systems. The vendors have lately been offering a broad range of open integration schemas, including extensible markup language (XML) messaging and proprietary connectors or open APIs, since easy integration to 3rd-party applications has become a key selling point for them.
SAP,
for example, had long created over 1,000 proprietary data access engines called
Business Application Programming Interfaces (BAPIs) for use
in integrating third-party products with the core ERP (enterprise resource planning)
system as well as its proprietary enterprise applications integration (EAI)
architecture called Applications Linking Enablement (ALE) via
SAP IDocs (Intermediate Documents), standard flat file formats
for common information exchanges. This requires open APIs to enable the integration
of third-party data reporting and analysis tools as well as other ERP extensions.
Instead of the costly, risky move to full componentization, most application vendors have selected a safer approach. They use component-based APIs to construct a "faade" for their existing application. When done properly, these APIs provide programmatic access to common business objects (e.g., an order, a business partner, a delivery), which are mapped to the existing application's functionality in a way that shields users from the complexity of the underlying code. However, APIs alone are not sufficient. To bridge the differing semantics and business processes enabled within each participating application in an extended ERP environment, either vendors or users must employ message broker technology (a special-purpose, preferably four-generation language (4GL) tool that can readily transform and route data as it moves between applications).
With
NetWeaver, SAP had thereby made a major shift from providing points of integration'
solutions through its BAPIs running over a proprietary remote procedure call
(RPC) protocol called RFC (Remote Function Call). SAP
Web Application Server (WAS) should provide a strategic integration
platform for its customers, allowing SAP to more elegantly offer possibly a
complete collaborative solution even when some of the component applications
are not natively provided by SAP (that was possible via multiple BAPIs though,
but in quite a cumbersome way). Furthermore, SAP Exchange Integration
(EI) superseded ALE that was mainly suited for asynchronous transaction
process needs, as a triggering mechanism to set again proprietary SAP IDocs
in motion as a means of data flow between SAP modules and/or to third-party
modules. Consequently, at first sight, NetWeaver addresses the major infrastructure
requirements of an exchange platform, including internal integration within
a single company and external between companies, business process workflow across
applications, identity/role management, and content management. The power users'
(rather than programmers' per se) ability to dynamically write business process
rules and to share them internally and externally, might give other vendors
pause and force them to come up with their equivalent solutions.
Analysis
of Strategy One Evolve
Nonetheless, the likes of SAP xApps/NetWeaver will mainly address the above issue No. 4 -- "Business processes, not application boundaries", but the other three burning issues will not necessarily be addressed with these announcements. In other words, hardly any composite product above makes the underlying product architecture future-proof' allowing developers to both add business functions and change underlying technology platform as justified. The next generation of enterprise architecture must allow for business change to be adopted on an on-demand basis within the existing architecture as the business evolves, and it must provide the cost, time, and quality characteristics to make change a practical choice for the business. It would be quite utopian to expect that from product instances based on outdated and/or very proprietary technologies like COBOL, RPG or ABAP.
To that end, while the evolution strategy might be safer in the short run for both the customers and the vendor, minimizing both investment and disruption, the evolutionary strategy has limits in how much can be accomplished. The existing product becomes a limit on the amount of innovation that proves practical. While the large vendors have the advantage of large resources, they also have the mixed blessing of a large customer base. Will the customer base support the move, and will it transition to the newer architecture? Can the big vendors adequately articulate the benefits of their new enterprise architecture to make the move critical/justifiable to the user base?
These vendors also have the mixed blessing of an existing product. They have to enhance and support that product while spending on a new technology. Business judgment tells them to minimize risk by evolving from the existing product to a new one, but that has proven very difficult for most in the past.
This
concludes Part One of a three-part trend note that will discuss three Strategies,
as follows:
-
Part One: Strategy One Evolve
-
Part Two: Strategy Two A New Framework
-
Part Three: Strategy Three A New Approach
Part
Three will also make User Recommendations.
About the Authors
Predrag
Jakovljevic is a research director with TechnologyEvaluation.com
(TEC), with a focus on the enterprise applications market. He has over 15 years
of manufacturing industry experience, including several years as a power user
of IT/ERP, as well as being a consultant/implementer and market analyst. He
holds a bachelor's degree in mechanical engineering from the University of Belgrade,
Yugoslavia, and he has also been certified in production and inventory management
(CPIM) and in integrated resources management (CIRM) by APICS.
Olin
Thompson is a principal of Process ERP Partners. He has over 25 years
experience as an executive in the software industry. Olin has been called "the
Father of Process ERP." He is a frequent author and an award-winning speaker
on topics of gaining value from ERP, SCP, e-commerce and the impact of technology
on industry.
He
can be reached at Olin@ProcessERP.com.