Tarchitectural Support for the Business Model

If your total offering is based on a combination of business models, check for key interactions between the various elements. Review these factors every time the business model changes, because these changes may invalidate prior assumptions and/or choices and motivate one or more changes to the tarchitecture .

General Issues

The following sections describe the general issues that are present for every business model.

Capturing the Necessary Data

Assess your business model to ensure that your system is capturing all of the data required to make it work. Here are two primary categories of data capture:

• Direct : The system captures and manages all data necessary to support the business model. It is "self-contained."

• Indirect: The system must be integrated with one or more other systems to create a complete picture of the necessary data.

To illustrate , a transaction or metered business model will either capture all of the necessary data or work with other systems to capture it. A service-based business model often has to be integrated with other systems, such as payment processing or client management systems, to capture the full set of data needed to create a viable business model.

Reporting/Remittance Requirements

Somewhere along the line your accounting department is going to require that information be submitted for billing purposes. Your job is a lot easier if you can define the format, security, and audibility requirements of these reports .

Business Model Enforcement

What happens when the license to use the software is violated? Does it stop working? Should an entry be made in a log file? Is an e-mail sent to a key person? Should a new billing and licensing cycle be automatically initiated?

Focusing ility Efforts

In an ideal world, the tarchitect's "ility" efforts (reliability, stability, scalability, supportability, usability, and so forth) are congruent with the key objectives of the business model. Suppose your business model is based on processing various transactions, such as check clearing and/or processing in financial services or in health care claims processing for large insurance carriers . In these cases, reliably and accurately computing a lot of transactions quickly is critical to your success. Performance matters, and faster really is better. Who cares if the product is a bit hard to install or upgrade as long as it's the fastest possible? If your tarchitect and the development organization with building the system also care about performance, you're doing great. If not, you may have some problems.

Of course, performance is not the primary criterion of every business model. In a service-based business model, great performance with lousy customer support may not be good enough to succeed. Instead of focusing on performance, your development team may need to focus on service elements such as ease of installation and upgrade. A key goal in a service-based business model is to reduce and/or eliminate phone calls to technical support, so it is best to find a tarchitect and a development team who care about these issues. Tradeoffs are determined by how the software will typically be usedapplications used infrequently should be easy to learn, while those part of a daily routine should be fast and easy to use.

Increased Revenues or Decreased Costs

Once you know your business model it is easy to focus tarchitectural efforts on activities that increase revenues. Don't forget the costs your tarchitecture imposes on your customer. Any time you can reduce those costs, you have more revenue potential. You can reduce costs by making installation and/or upgrade easier or by improving performance and/or backward compatibility so that your users won't have to purchase expensive new hardware every time they upgrade to a new version.

Copy Protection/Antipiracy Protection

All software is subject to illegal copying and distribution, although certain kinds of software, such as that inside a video game cartridge or cell phone, are more resistant to piracy because of the hardware dependency. Even so, hardware is not a strong deterrentjust check out the number of places where you can find replacement software that can boost the performance of your car! Most software, however, is trivially copied , as proven by the many online services that provide easy access to pirated software. Depending on the amount of money you may lose from piracy (some companies estimate several million in losses) you should consider a copy protection scheme, as described further below.

Verifying Business Model and License Model Parameters

Many of the business and licensing models involve setting one or more parameters. For example, an annual license has a definite end date, a concurrent user license has a specific number of concurrent users, possibly further divided by type, and a consumptive, time-based license has the amount of time available for use. Whenever you set a value that is important to your business model, you have to understand when, how, and where this value is set, who can change it, and how its value can be verified . These are nontrivial matters, discussed later in this chapter under enforcing business and licensing models (see also Chapter 16, on Security).

Time-Based Access or Usage

Time-based access or usage business models make few special demands on the tarchitecture, unless you're going to strictly enforce the business model. If this is the case, you're going to need a way of being able to disable the software when the time allotted for use has expired . Many subscriptions don't actually stop a program from working if you fail to remain current in your paymentsyou just don't get updates (which has the effect of converting a subscription to a perpetual license).

Transaction

Consider the following when dealing with a transaction-based business model.

Define the Transaction

The definition of a transaction, or the unit of work that is the foundation of the business model, must be clear and unambiguous. Once you've defined the transaction, make certain that the tarchitecture can support it and that it is clearly stated in the software license. This is not easy, but it is essential. As you define the transaction, consider the role that each component is playing with respect to it. In distributed transaction systems, the manner in which an element participates in the transaction must be defined, including which participants are the basis of the business model.

Define the Relationship between the Transaction and the Business Model

I've heard some people say that the first step in starting a phone company is purchasing billing software. While this may not be true, the complexity of the plans offered by cell phones for completed transactions requires sophisticated billing management systems. More generally , it is absolutely essential that you can map the completed transaction to the business model. In the case of the phone company, where the transaction is a phone call, key data include who originated the call, who received it, and how long it took.

Keep Audit Trails

Many transaction-based business models require audit trails that can be used to prove /disprove specific charges. This can be especially vital when attempting to reconcile differences between participants in the transaction. You may also need to cross-reference the transactions created by your system with those created by other systems.

Make Certain that Transactions Are Uniquely Identified

Transactions must be uniquely identified. Be wary of simple database counters, which often won't work in today's distributed environments. Instead of relying on the database vendor, create a truly unique identifier through a reliable algorithm. I've had good luck with the built-in algorithms for creating universally unique identifiers (UUIDs) in UNIX-based systems or the globally unique identifiers (GUIDs) available on MS-Windows systems. Admittedly, these require a lot of space, and represent an extraordinarily large number of unique identifiers. Chances are good you don't need an identifier to be quite that long, and you may be able to safely shorten your unique identifier. Short identifiers that work well are based on alphanumeric codes, like "XR349" or "QPCAZZ." One advantage to these codes is that they are short enough to be used in phone-based self service.

Understand Transaction State, Lifecycle, and Duration

When I'm standing in line at the checkout counter about to make some purchase, my mind often leaps to images of mainframe computers processing hundreds of credit card transactions per second. Of course, there are myriad other kinds of transactions, many of which have complex states, lifecycles, and durations. Managing the duration of the transaction can be particularly complex, especially when a transaction can live over a system upgrade. The complete transaction lifecycle must be defined because it impacts your back-office systems that account for transactions.

Suppose, for example, that a transaction can last as long as one year and you bill your customer monthly. Normally, you bill for a transaction when it has completed. However, in this case you could be waiting a long time for money, negatively impacting your cash flow. If you know that 80 percent of transactions complete successfully, you could safely bill when the transaction is started, provided that your system can recognize a failed or aborted transaction and your back-office systems can properly adjust and/or otherwise credit your customer's account. Before actually doing this, check with your accounting department to make certain that you're not violating any revenue recognition regulations.

Metering

Metering business models entail many interesting challenges, especially when the metering is based on a concurrent or named user. The following sections address some of the issues that are common to both models.

How Do You Authenticate Users?

Authentication attempts to answer the question "Are you who you say you are?" There are many authentication approaches, from simple user names and passwords to simple-to-use but hard-to-defeat tokens to advanced (and costly) biometric systems. If your business model derives a lot of money from uniquely identifying users, you should consider employing any number schemes beyond simple user names and passwords. More generally, you should work with other, established infrastructure technologies to authenticate users (such as LDAP). Authentication is discussed in greater detail in Chapter 16.

How Many Users?

In a concurrent user system there is some limit to the number of users who can concurrently access it. The manner in which you specify that number is subject to considerable variation. I've worked on systems that span the gamut of managing this value. On the low end, we specified the number of concurrent users as a plain text entry in an INI filecompletely insecure but entirely acceptable for our requirements. On the high end, we specified the number of concurrent users in a signed license that was then stored on a hardware device using advanced cryptography. To the best of our knowledge, this approach has yet to be cracked!

How Are You Going to Count Concurrent Users?

While you can, and often should, rely on other parts of the infrastructure to authenticate users, you may not be able to rely on them to count users. This may be a function of your application, or it may be obtained by integrating a license manager into your application.

Are Users Gone or Inactive?

Session management is a key issue in concurrent and named user applications. Once a user is logged in, you can't assume that she will explicitly log out. Something might go wrong: Her client might crash; or she might not remember to log out. The general solution is to associate a timeout parameter that forcibly logs off the user or drops her session after a set period of inactivity.

Unfortunately, setting this value isn't trivial. It must be tuned on the basis of how your application is actually used. Consider an interactive voice system that is accessed by a cell phone. Is a period of inactivity caused by the user pausing to consider his next action or has the line dropped because he drove into a "dead zone"? If the user did drive into a dead zone, how will you reestablish the session so that he doesn't have to re-enter a long string of menu commands? It is important that you provide plenty of configuration parameters on these values so that your administrator can properly tune your application.

Consumptive resource management places severe restrictions on your tarchitecture, primarily because you have to maintain some kind of state. If your customer has purchased "100 hours" of total use, you need to record how long she has actually used the application. One approach is to store these data on a centralized server, which can work if you structure it so you can't be spoofed and you always have a reliable network connection. Another approach is to store usage locally. Be careful, however: It is often trivially easy to reset usage data by erasing previously stored values.

Hardware

The biggest issues with hardware-based models are defining what constitutes the hardware and how you're going to manage it relative to the business model. What, exactly, is a central processing unit (CPU)? In many ways the concept of a "CPU" is meaningless: Many personal computers and engineering workstations now come with at least two processing units as part of their standard equipment, and some new chip designs have multiple processing units in a single package. Arbitrarily picking one as central seems a bit silly. Still, per-CPU business models are common. To support them, you will have to define a CPU and how it will be enforced in your system.