The Next Wave of the web

Customer Resource Management in the post-boom era

As markets mature in many industries, attracting new customers is becoming increasingly difficult. Post net-boom companies are compelled to offer low rates to lure customers away from their competitors.

Enterprise Applications

Lots of people write computer software, and we all call it all software development. Yet there are distinct kinds of software out there, each of which has its own challenges and complexities. This comes out when I talk with some of my friends in the telecoms field. In some ways enterprise applications are much easier than telecoms software - we don't have very hard multi-threading problems, we don't have hardware and software integration. But in other ways its much tougher. Enterprise applications often have large and complex data to work on, together with business rules that fail all tests of logical reasoning. Although some techniques and patterns are relevant for all kinds of software, many are relevant for only one particular branch.

In my career I've concentrated on enterprise applications, so my patterns here are all about that. But what do I mean by the term "enterprise application"? I can't give a precise definition for them, but I can give some indications.

I'll start by example. Things that are enterprise applications include: payroll, patient records, shipping tracking, cost analysis, credit scoring, insurance, accounting, foreign-exchange trading. Things that are not enterprise applications include: automobile fuel injection, word processors, elevator controllers, chemical plant controllers, telephone switches, operating systems, compilers, games.

Enterprise applications usually involve persistent data. The data is persistent because it needs to be around between multiple runs of the program - indeed it usually needs to persist for several years. During this time there will be many changes in the programs that use it. It will often outlast the hardware that originally created much of the data, and outlast operating systems and compilers. During that time there'll be many changes to the structure of the data in order to store new pieces of information without disturbing the old. Even if there is a fundamental change and the company installs a completely new application to handle a job, the data has to be migrated to the new application.

There's usually a lot of data, a moderate system will have over 1GB of data organized in tens of millions of records, so much data that managing it is a major part of the system. Older systems used indexed file structure such as IBM's VSAM and ISAM. Modern systems usually use databases, mostly relational databases. The design and feeding of these databases has turned into a sub-profession of its own.

Usually many people access data concurrently. For many systems this may be less than a hundred people, but for web based systems that talk over the Internet, this goes up by orders of magnitude. With so many people there are definite issues in ensuring that they can access the system properly. But even without that many people there are still problems in making sure that two people don't access the same data at the same time in such a way that would cause errors. Transaction manager tools handle some of the burden of this, but often it's impossible to hide this from application developers.

With so much data, there's usually a lot of user interface screens to handle this data. It's not unusual to have hundreds of distinct screens. Users of enterprise applications vary from habitual to regular users. Usually they will have little technical expertise. The data has to be presented lots of different ways for different purposes.

Enterprise applications rarely live in an island. Usually they need to integrate with other enterprise applications scattered around the enterprise. The various systems are usually built at different times with different technologies. Even the collaboration mechanisms will be different: COBOL data files, CORBA, messaging systems. Every so often the enterprise will try to integrate its different systems using a common communication technology. Of course it hardly ever finishes the job, so there are several different unified integration schemes in place at once.

Even if a company unifies the technology for integration, they run into problems with differences in business process and conceptual dissonance with the data. One division of the company may think a customer is someone who has a current agreement with the company, another department also counts those that had a contract but don't any longer, another one counts product sales but not service sales. That may sound like it's easy to sort out but when have hundreds of records where every field can have subtly different meanings, the sheer size of the problem becomes a challenge - even if the only person who knows what this field really means is still with the company. (And of course all of this changes without warning.) As a result data has to be constantly read, munged, and written in all sorts of different syntactic and semantic formats.

Then there is the matter of what goes on under the term "business logic". I find this a curious term because there are few things more less logical than business logic. When you build an operating system you strive to keep the whole thing logical. But business rules are just given to you and without major political effort there's nothing you can do to change them. The rules are haphazard often with no seeming logic. Of course they got that way for a reason: some salesman negotiated to have a certain yearly payment two days later than usual because that fitted with his customer's accounting cycle and thus won half a million dollars of business. A few thousand of these one off special cases is what leads to the complex business illogic that makes business software so difficult.

For some people the term "Enterprise Application" implies a large system. But it's important to remember that not all enterprise applications are large, even though they can provide a lot of value to the enterprise. Many people assume that since small systems aren't large, they aren't worth bothering with. To some degree there's merit here, if a small system fails it usually makes less of a noise than a big system. However I think such thinking tends to short-change the cumulative effect of many small projects. If you can do things that improve small projects, then that cumulative effect can be very significant on an enterprise, particularly since small projects often have disproportionate value. Indeed one of the best things you can do is turn a large project into a small project by simplifying its architecture and process.

Kinds of enterprise application

When we discuss how to design enterprise applications, and what patterns to use, it's important to realize that enterprise applications are different, and that different problems lead to different ways of doing things. I have a set of alarm bells that go off when people say "always do this". For me, much of the challenge (and interest) in design is in knowing about alternatives and judging the trade offs of when to use one alternative over another. There is a large space of alternatives to choose from, but here I'll pick three points on this very big plane.

Consider a B2C (business to customer) online retailer: people browse and, with luck and shopping cart, buy. For such a system we need to be able handle a very high volume of users, so our solution needs to be both reasonably efficient in terms of resources used, but also scalable so that you can increase the load you can handle by adding more hardware. The domain logic for such an application is pretty straightforward: capturing orders, some relatively simple pricing and shipping calculations, and notification of shipments. We want anyone to be able access the system easily, so that implies a pretty generic web presentation which can be used with the widest possible range of browsers. Data source includes a database for holding orders and perhaps some communication with an inventory system to help with availability and delivery information.

Contrast this with a system for automating the processing of leasing agreements. In some ways this is a much simpler system than the retailer because there are much fewer users, no more than a hundred or so at any one time. Where it's more complicated is in the business logic. Calculating monthly bills on a lease, handling events such as early returns and late payments., validating data as a lease is booked - all of these are complicated tasks since much of the leasing industry competition comes in the form of yet more little variations over deals done in the past. A complex business domain such as this is challenging because the rules are so arbitrary. If you design an operating system or a telephone switch at least are trying to develop the processing in a logical way. Business rules often defy all logic, and are subject to regular changes over time.

Such a system also has more complexity in the UI. At the least this means a much more involved HTML interface with more screens and more complex screens. Often these kinds of systems have UI demands which lead users to want a more sophisticated presentation than a HTML front end allows - so a more conventional rich client interface is needed. The more complex user interaction also leads to more complicated transaction behavior: booking a lease may take an hour or two during which the user is in a logical transaction. We also see a complex database schema with a couple of hundred tables, and connections to packages for asset valuation and pricing.

A third example point would be a simple expense tracking system for a small company. Such a system has few users and simple logic. It can easily be made accessible across the company with an HTML presentation. The only data source is a few tables in a database. Yet even a simple system like this is not devoid of a challenge. You have to build it very quickly. You also have to bear in mind that it may grow later as people want to calculate the reimbursement checks, feed them into the payroll system, understand tax implications, provide reports for the CFO, tie into airline reservation web services, and so on. Trying to use the architecture for either of the other two systems will slow down the development of this system, and add complexity that will probably harm its future evolution. And although this system may be small, most enterprises have a lot of such systems, so the cumulative effect of an over-complex architecture can be significant.

Performance

It's always difficult to talk about performance in a book such as this. The reason why it's so difficult is that any advice about performance should not be treated as fact until it is measured on your configuration. Too often I've seen designs used or rejected due to performance considerations, which turned out to be bogus once somebody actually did some measurements on the setup actually used for the application.

I've given a few guidelines in this book, including minimizing remote calls which has been good performance advice for quite a while. Even so you should verify every tip by measuring on your application. Similarly there are several occasions where code examples in this book sacrifice performance for understandability. Again it's up to you to apply the optimizations for your environment. But whenever you do a performance optimization you must measure both before and after, otherwise you may just be making your code harder to read.

There's an important corollary to this: any significant change in configuration may invalidate any facts about performance. So if you upgrade to a new version of your virtual machine, hardware, database, or almost anything else - redo your performance optimizations and make sure they are still helping. In many cases a new configuration can change things. Indeed you may find that an optimization you did in the past to improve performance actually hurts performance in the new environment.

Another problems with talking about performance is the fact that many terms are used in an inconsistent way. The most noted victim of this is "scalability", which regularly gets used to mean half a dozen different things. To my, rather cynical eye, most comments about things that affect scalability are vague threats about ill-defined future fears about performance - and of course since they are future threats it's rather hard to verify them with measurements. As a result here's the terms I use.

Response time is the amount of time it takes for the system to process a request from the outside. This may be a UI action, such as pressing a button, or a server API call.

Responsiveness is about how quickly the system acknowledges the request, as opposed to processing it. This is important an many systems because a people may get frustrated if a system has low responsiveness, even if it's response time is good. If your system waits during the whole request, then your responsiveness and response time are the same. However if you indicate you've received the request before you complete, then your responsiveness is better. Providing a progress bar during a file copy improves the responsiveness of your user interface, even though it doesn't improve the response time.

Latency is the minimum time required to get a any form of response, even if the work to be done is non existent. Latency is usually the big issue in remote systems. If I ask a program to do nothing, but tell me when it's done doing nothing, then if the program runs on my laptop I should get an almost instantaneous response. However if the program runs on a remote computer I may get a few seconds just because of the time taken for the request and response to make their way across the wire. As an application developer, there's usually nothing I can do to improve latency. Latency is also the reason why you should minimize remote calls.

Throughput is how much stuff you can do in a given amount of time. If you're measuring copying a file, throughput might be measured in bytes per second. For enterprise applications a typical measure is transactions per second, but the problem with this is that it depends on the complexity of your transaction. For your particular system you should pick a common set of transactions.

The load of a system is a statement of how much stress a system is under. This might be measured in how many users are currently connected to the system. The load is usually a context for some other measurement, such as a response time. So you may say that the response time for some request is 0.5 seconds with 10 users and 2 seconds with 20 users. The load sensitivity is an expression of how the response time varies with the load. A system that has a response time of 0.5 seconds for 10 through 20 users has a lower load sensitivity than a system with a response time of 0.2 seconds for 10 users that rises to 2 seconds for 20 users. The capacity of a system is an indication of a maximum effective throughput or load. This might be an absolute maximum, or a point at which the response time dips below an acceptable threshold.

Scalability is a measure of how adding hardware effects the performance. A scalable system is one that allows you to add hardware and get a commensurate performance improvement, such as doubling your server capacity doubling your throughput..

The problem is that design decisions don't affect all these performance factors equally. Say we have two software systems running on a server: swordfish has a capacity of 20 tps, while camel's capacity is 40tps. Which has better performance, which is more scalable? We can't answer the scalability question from this data, and we can only say that camel has a higher capacity on a single server. Now if we add another server we notice that swordfish now handles 35tps and camel handles 50tps. Camel's capacity is still better, but swordfish looks like it may scale better. Let's say we continue adding servers and discover that Swordfish gets 15tps per extra server and Camel gets 10tps per extra server. Given this data we can say swordfish is more scalable, even though Camel has better capacity for less than five servers.

When building enterprise systems, it often makes sense to build for hardware scalability rather than capacity or even load sensitivity. Scalability gives you the option of better performance if you need it. Scalability is also often easier to do. Often designers do complicated things that improve the capacity on a particular hardware platform, when it might actually be cheaper to buy more hardware. If Camel has a greater cost than Swordfish, and that greater cost is equivalent to a couple of servers, then Swordfish ends up being cheaper even if you only need 40 tps. It's fashionable to complain about relying on better hardware to make our software run properly, and I join this choir whenever I have to upgrade my laptop just to handle the latest version of Word. But newer hardware is often cheaper than the price of making software run on less powerful systems. Similarly adding more servers if often a cheaper price then adding more programmers - providing a system is scalable.

Enterprise Application Integration (EAI)

Enterprises across all industry sectors need to implement EAI. Different industries and sectors have different requirements and use concepts that are specific to their individual problem domains. This complicates the design of EAI solutions, and means that solution architects must develop industry-specific EAI offerings.

However, as one examines EAI solutions more closely, it is clear that there are common concepts across industry solutions. In fact, many of the underlying functional concepts, services, and products are common across different industries. The differences between industries tend to focus on business-specific scenarios that fit into common categories, rather than on functional EAI issues.

With this in mind, this document seeks to distill the essential template or pattern for a common (and thus reusable) EAI architecture. This pattern extends to the use of CORBA, Tibco Java and .Net technologies to meet the generic EAI solution needs.

The advantage of creating a pattern for the common elements of the EAI offering is that it allows industry-specific solution providers, partners, and customers to build tailored EAI offerings on the reusable architecture components without having to redefine the common implementation patterns and practices for each solution.

By building this pattern we can focus on the logical services that are required to implement the generic or pattern EAI architecture. We can then examine the implementation specifics as separate topics in the "Physical Services" and "Implementation" sections.

Tools for Knowledgee Management in the post-Internet Era

Knowledge management has various approaches and definitions according to the perspective and discipline of the individual or organisation that engages with the concept. These include management, individual and organisational learning, communications, information systems and technology, artificial intelligence, intellectual assets, and so on. Each discipline approaches KM with a different perception, for example, computer science focuses heavily on technology, human resources takes an individual and organisational approach emphasising learning and reward factors, and intellectual assets focus on the explicit capture and registration of knowledge.

Knowledge management involves people, processes, activities, technology, and the broader environment that enable the identification, creation, communication or sharing, and use of organisational and individual knowledge. It is about the processes that govern the creation, dissemination, and utilisation of knowledge to attain organisational objectives. It requires a mix of business awareness, creative attitudes and practices, systems, tools, policies, and procedures, designed to release the power of information and ideas.

"Knowledge management is about:

• supporting innovation, the generation of new ideas. and the exploitation of the organisation's thinking power;

• capturing insight and experience to make them available and usable when, where, and by whom required;

• making it easy to find and re-use sources of know-how and expertise, whether they are recorded in physical form or held in someone's mind;

• fostering collaboration, knowledge sharing, continual learning and improvement;

• improving the quality of decision-making and other intelligent tasks;

• understanding the value and contribution of intellectual assets and increasing their worth, effectiveness, and exploitation"

KM must focus an organisation on improving its actions to exploit the power of knowledge. Knowledge management is concerned with the creation, generation, codification, and transfer of information and ideas. The power of knowledge management is in allowing organisations to enable and support explicitly these activities to leverage their value for the group and organisation as well as for the individual.

When accumulating knowledge there is a conscious choice to learn or discard the knowledge of others. Very often you choose that with which you already agree and that does not challenge your own assumptions. This is a form of self-prejudice. In fact the mind always follows a certain pattern—knowledge can therefore gradually become formulaic. Experiences give us memories and values that guide and discipline us and therefore condition our minds. We use 'dead' memories and values to understand new experience.

It is essential for organisations that some suggestions are promoted and developed that lead to organisational knowledge being used for timely decisions that lead (among other things) to true competitive advantage for the organisation. (See the comments from Xerox.) The emerging focus in management and system literature on the importance of organisational knowledge is, due to six specifics for organisations:

• the pace of change itself (fast);

• the nature of goods and services (an increasing emphasis on intangible goods);

• the scope of the typical firm and its market (ever increasing with the increasing use of the World Wide Web);

• the size and attrition rate of employee bases (shrinking or growing according to the market forces);

• the structure of organisations (under change as circumstances change and thus increasingly fluid); and

• the capabilities and costs of information technology (increasing capabilities for decreasing costs).

These specifics affect most of the organisations operating in the developed economies and often many in the developing economies too. The issue here is that a problem is always new (otherwise it would not be a problem!), so if we approach the problem with existing knowledge and actions, formed into patterns by memory, our responses will be conditioned by our past. Therefore we cannot solve the 'new' in the problem—we cannot understand through the barriers of past thought. Thus to understand the new we need wisdom, we need to be free of the past conditioning, and we need creativity.

Small Bio

In the last 10 years I worked mainly in developing software systems for large corporations, both in the CTI and in the banking field.

I spent the last two years working for a large multinational company whose core business was system management for the largest italian oil company: my work being integration and management of etherogeneous systems, (products like TIBCO, BEA WebLogic, IBM WebSphere, WebIntelligence, BroadVision)  and SSO technologies, like Policy Director and Siteminder.

I set up and taught courses on (among other subjects): C++/STL, Java, middleware technologies (CORBA,DCOM, TIBCO-RENDEZVOUS, SOAP), EJB development on application servers like BEA WebLogic, IBM WebSphere, IONA iPortal, Jboss.

Key competences:

• Multi-year experience with UML and instruments like Together-J and Rational Rose
• More than 10 years of C/C++. Deep knowledge of the C++ ISO standard and of STL implementations.
• 9 Ys. Of Java  experience (projecting, developing and teaching since 1996)
• Strong and constantly updated experience on the Java ecosystem as a whole
• Strong multi-year experience  On J2EE and EJB (WebLogic,WebSphere, Inprise/Borland EAS, JBoss). Knowledge of the inners of the source code of some of these AS
• Very strong CORBA experience  (IONA Orbix, Visigenic Visibroker, RT ORB+)
• Strong TIBCO experience, both developing (C++, Java) and mantaining systems built with TIBCO Rendez-Vous, TIBCO Adapters, TIBCO Business Activity Monitor, TIBCO Hawk Monitoring System, TIBCO Integration Manager, Business Connect
• Experience  of PDA Palm, Windows CE, Symbian C/C++  development.
• Ten years of development under Unix (C,C++,POSIX,ANSI).
• Ten years (or more) of development under Windows (C,C++,Delphi,Visual Basic, Access, SQL Server, IIS,ASP,COM/DCOM)
• Experience of 7 Years  with Web-oriented  technologies (Apache, IIS, ISAPI, ASP, JSP, Perl, PHP, Python, CGI C/C++,XML, HTML, SOAP)
• Deep knowledge of C/C++ and Java source code of Apache, OpenSSL, ACE/TAO, JBoss, Tomcat technologies.
• Knowledge of mainstream DBMSs (Oracle, MS SQL Server, Informix) e OODBs (PSE ObjectStore).
• Experience with Workflow and Project Management technologies (MS Project et similia).
• Broadvision, Web Intelligence and PeopleSoft HRM system management knowledge
• Knowledge of Dynamic Systems Programming and of software like PowerSim, Witness et al.
• Strong competence about on-line banking & trading application development