An Extranet-Based Customer-Centric

An Extranet-based Customer-centric Enterprise Model

ZELJKO PANIAN

The Graduate School for Economics and Business

University of Zagreb

J. F. Kennedy Sq. 6

CROATIA

Abstract: - An extranet-based customer-centric model that enables the enterprise to develop a virtual value network linking it together with its business partners and customers is presented. The key to the success of this model is for the enterprise to be able to rapidly create new customer-oriented applications that build upon the existing information systems infrastructure. There are several crucial characteristics that make an extranet application framework effective, and they are briefly discussed. Finally, the appropriate methodology for an extranet-based customer-centric model implementation is explicated.

Key-Words:- extranet, customer-centric model, virtual value network, software development, security, performance

1 Introduction

The rapid growth of the Internet created a ubiquitous network that can link every mainframe and/or server within an enterprise to the client computer, the desktop or even PDA of everyone of its business partners or end customers. Technology-aware and savvy managers can quickly recognize the opportunity to create significant competitive advantage by extending business processes to directly include business partners and customers.

While the Internet and the Web are about connectivity and access to information, the Web architecture also enables a new model of enterprise applications. Namely, an application on the server can play a dual role:

as a Web server application that interacts with Web end-users, enabling them to accomplish their tasks and satisfy their business needs

as a client that interacts, on the end-user’s behalf, with existing enterprise systems in order to exploit the proven business logic and harvest the information content found in those applications and databases

In this way, an enterprise extends its functions beyond its physical, logical and organizational boundaries, transcending to a form of extendedenterprise or extraprise. According to Kalakota, the extraprise describes multienterprise supply and demand chains with shared information infrastructure [1]. It enables supply and demand chain integration, more effective outsourcing, and self-service solutions for both internal and external users.

The extraprise is, in fact, a virtual value network linking together several business partners and/or customers that allows for sophisticated online business processes interweaving line-of-business applications with other internal and external information or sources. The goal is a profitable growth, which some companies accomplish by providing customer-tailored products, services, and value-added information. Thus, the extraprise is, by its very nature, customer-centric.

While extending the current capabilities of enterprise systems out to Web users is useful, much greater value is realized when these extranet applications are enhanced with new business logic to integrate the information and processing of multiple sources into a brand new application that is customized to needs of the end-users. The resulting user-oriented. i.e. customer-centric enterprise model can be free of the constraints and limitations of the underlying applications that were created in a different time and for a different end-user audience.

The extranet-based customer-centric model is shown in Figure 1.

The key to the success of this model is to be able to rapidly create new customer-oriented applications that build upon the existing information systems infrastructure. Extranet applications are ideal for merging a lot of existing “employee-facing” information systems into “market-facing” systems that provide enterprise information directly to business partners and, that is even more important, to customers.

Figure 1: The extranet-based customer-centric model

2 The Basic Model Features

A key technology for enabling the development and implementation of the model shown above is the framework used for creating and deploying customer-centric extranet applications. An effective extranet application framework must enable the representation of vital business information as objects that can be combined with other business objects in new ways that may not have been possible before.

There are several crucial characteristics that make an extranet application framework effective. These features are:

multi-tiered architecture

time to market
additional effectiveness features

2.1 Multi-tiered architecture

Tools must be designed to fit within the environment where they will be used. To make the design of extranets straightforward and “natural”, an extranet application framework must reflect and facilitate the fact that an extranet solution involves at least three distinct layers of processing. Layers of processing are differentiated by groups of people with different background, knowledge, experience, and skills, and with different business needs, who are accomplishing specific tasks.

These layers are:

enterprise connectivity
integration business logic
information delivery

Schematically, these layers are shown in Figure 2.

2.1.1 Enterprise connectivity

An extranet must be able to interact with many different kinds of internal, back-end systems to retrieve or update the enterprise information that it uses. Programmers familiar with the back-end systems must be able to do two things:

define connections to the necessary information or processing within the existing and/or legacy systems, and

make that information available in a reusable form such that application specialists (who, in principle, know nothing about the back-end data resources) can use it in multiple heterogeneous extranet applications.

2.1.2 Integration business logic

Integration must be done at the information level, not at the data level. Line-of-business application specialists who are experts in the information needs of the target business partner or end-customers must be able to create business logic that defines the information produced by the extranet application. They also must know how this application uses the information and processing within existing and/or legacy systems.

These business programmers need high-level tools that allow them to define how different information or processing elements are related to each other, and how they are combined to produce the required information output.

Figure 2: The Three-tiered Extranet Architecture

To make the information usable in multiple environments and different extranet applications, the business logic has to be totally independent of both the presentation logic and arcane details of back-end data source formats and access methods.

2.1.3 Information delivery

Information produced by the extranet must be independent of how it is delivered to the business partner or customer end-user. The same information must be available as a component to be used by various programmers, like Web, client/server, Visual Basic, Java, and even other e business programmers.

2.2 Time to market

The competitive advantage of an extranet solution in today’s business world is often directly associated with getting it into market quickly – measured in hours and days instead of weeks and months. The extranet application framework must accelerate the development of extranet applications, while concurrently minimizing potential risk exposure that might occur.

The most important features of such a framework are as follows:

Ease of programming. The extranet application framework must automatically handle all the mundane but crucial details of a high-performance, multithreaded, multi-user component-based server environment to focus on adding value in the business application [2].

Leverage skills. Programmers can be most productive using languages and tools, such as

Visual Basic and Java, which are already familiar to them.

Visual Tools. Complex relationships and actions can become simple to understand and create by manipulating visual elements on the screen rather than manually encoding everything in the text form.

Standards support. The fastest, lowest-risk way to build applications is not to write them at all, but to assemble them from business objects, applications, and databases that already exist and are known to work [3]. Therefore, the extranet framework must provide support for other languages, protocols, applications and data sources through industry standard interfaces. Applications within the framework must themselves be easily invoked from other programming and application environments.

Reuse. The application framework must make it possible and easy for new applications to reuse business objects originally built for a different application. Similarly, when changes have to be made to low-level business objects, all applications that share that object must be automatically reorganized and updated.

Extensibility. The extranet application framework must allow applications to start small, then rapidly and iteratively expand the functionality and level of integration they offer [4].

2.3 Additional effectiveness features

By definition, extranet e-business solutions that involve business partners and customers are mission-critical enterprise applications. They must be rock solid and managed just like any other application, and probably deserve even more care.

Therefore, the extranet applications must have some additional effectiveness features, such as:

Scalability. Successful extranet applications must be able to grow from small, single server pilots to large, high performance multi-server deployments in a predictable way.

Security. The application framework must provide the extranet application with an access control mechanism, or make it fit into existing security mechanisms within the enterprise [5].

Reliability. The application framework must isolate each user and extranet application from failures in other companies or applications [6].

Management. The application framework must allow the run time environment and the extranet applications, to be monitored, measured, and controlled.

3 Technical Details of Model Implementation

In technical sense, the model implementation efforts should be concentrated on three key points:

server environment
security
performance

Each of them deserves somewhat broader explication.

3.1 Server environment

The server supporting the extranet-based customer-centered enterprise model should be a runtime container in which information rules are to be executed. I could be run as a stand-alone server, or in conjunction with other infrastructure technologies (e.g., IBM WebSphere Application Server or Microsoft Transaction Server). Either way, the server should work the same – the only thing to be changed is the pathway through which requests to run applications are received.

Important technical characteristics needed for the server environment supporting the model are:

Multi-user. All applications should automatically be multi-user applications. This should require no special preparation or programming. As each new user logs in, the implementation should create a new context that is to be completely isolated from every other user.

Multi-threaded. Each information rule should be run within its own thread, so that at any time a single user can have multiple threads executing concurrently. The server should automatically handle the sequencing of the information rules by using the metadata that describe relationships between the rules.

Robust. The error recovery procedures should ensure that if one component fails, only that specific instance of that component is affected. No other users or applications would be affected, although their instance of the component might also fail for the same reason.

3.2 Security

Security is multi-faceted issue that can affect the use of the server or applications. To work effectively under varied implementation scenarios, the model implementation should integrate seamlessly with existing enterprise security mechanisms.

The important security aspects include:

User authentication. An administrator should maintain a list of valid user names. At logon, the end user should supply a valid user name, to be authenticated by using the associated password. This mechanism is intended to provide a basic level of security.

Access control. The server supporting the model should use access control lists of single users and user groups. Each individual information rule should be restricted to being executed by specific user or by a specific user group. Although this allows very fine control of access to information, typically these access controls should be only assigned to the highest-level information rule that represents the entire application, since in practice most servers have to be dedicated to a single application and access controlled via the user authentication process.

Context-based security. A special type of information rule has to be created, which can cause different logic to be automatically executed for different users. This would allow the business programmer to create a single information rule that, for example, summarizes data, but have it return different content different content depending on the user or group name.

Back-end security. Servers should be located in a physically safe environment and be considered “trusted” by the back-end systems with which they communicate. It is important to note that server should never directly connect a front-end, end-user session with any back-end sessions. All access to back-end systems should be done by the model implementation software, not by the end-user, thus providing a higher degree of protection for the back-end systems.

3.3 Performance

As with security, many factors can affect the performance of the implemented model. Some of these are as follows:

Scalability. A key performance issue is the ability to predictably scale from a small pilot system with a handful of users on a single server, up to a multi-server system supporting a lot of users. To achieve this, information rules should be very atomic. Each rule should be loaded only when it is required to run, and as soon as it has finished executing, it should be deleted and its resources freed.

Load balancing. Applications need also be scalable across multiple servers. The external load balancing application should be used, using real-time information from the operation system performance monitor to distribute new incoming users to the server most capable handling the additional load.

Single system image. Multiple servers should share a common repository where all applications are stored. This can ensure that when a new server is brought up, it will be running exactly the same application as the other servers.

4 Applications Development

Any integrated development tool must have very close ties with its corresponding runtime environment [7]. Thus, a component model should be available to business programmers, and the business logic engine should implement the same model to execute components.

Building component-based applications involves three fundamental activities:

Component definition. Defines components and their functionality, whether they are new components or component wrappers that represent the information or functionality within existing systems. Together, the properties that define each component (name, parameters, usage. etc.) are known as metadata or “data about data”.

Component interaction. Describes how components are organized and work together to implement an application. The description of relationships between the components is also metadata.

Components execution. Uses the run-time container and services needed to execute the new component-based application. This may be a set of run-time libraries, a stand-alone run-time server environment, or a set of run-time services hosted within an existing server environment.

All three activities must take place and the metadata from each step is needed in order to perform the next step. However, sometimes the steps are implicit and the metadata are not explicitly stored. Often, particularly with smaller projects, all the information about the components and the way they interact to each other is only stored in programmers’ heads – it is just information that they “possess” and “know”.

A programmer will encode that knowledge into a program by writing the Java, C++ or similar code that provides the appropriate parameters, makes calls to the components in a certain sequence, uses the output from the components, etc. Another programmer can look at the code and deduce the metadata for the components, or at least the subset of metadata that the program used.

It is good for the program logic to be represented in visual manner. Namely, complex relationships and actions can become simple to understand and create by manipulating visual elements on the screen or drawing them manually, rather than encoding everything in a kind of text form.

For instance, when another person asks what the application does, the programmer goes to a piece of paper or a whiteboard, draws a set of boxes representing the various components and the lines between them to indicate which one calls another. In other words, the programmer creates a visual representation of the metadata that defines the components and the relationships between them.

Clearly, organizations do not want this knowledge to be lost when programmers go away for any reason, or when a projects grows so large that the metadata about the components and the relationships between them becomes too big and too complex to keep in one person’s mind. Therefore, an appropriate software tool should be used to create, preserve and use metadata about the information rules.

5 Conclusions

An extranet-based customer-centric model is presented, which enables the enterprise to develop a virtual value network linking it together with its business partners and customers. To goal of the enterprise is a profitable growth accomplished by providing customer-tailored products, services, and value-added information.