Beyond Software Architecture[c] Creating and Sustaining Winning Solutions

Common choices for software deployment architectures are discussed in the following sections.

Customer Site

This type of deployment is the most traditional and the most common. The software is installed at the customer's site and is configured, operated, and maintained by the customer. For common packaged software for the consumer market, such as I'm using to write this book, it means I've purchased, installed, and configured it on my laptop. Enterprise-class software, such as corporate finance system, warehouse management, and customer relationship management (CRM), is almost always controlled by the corporate IT department.

Enterprise-class software is usually installed and configured through a consulting assignment. The system vendor may provide professional services to the customer or subcontract them to a major consulting firm (such as EDS, Bearing Point, or Accenture). The duration of the assignment is often a function of the system's effect on existing corporate processes, any or all of which may have to be substantially modified before, during, and often after the installation.

Application Service Provider

An application service provider (ASP) operates an application for the customer, offering a limited set of services, and rarely a complete solution. For example, the ASP may provide "24/7" system monitoring, routine backups , and automatic access to additional internet bandwidth, but not application technical support. The specific services provided by the ASP must be negotiated.

ASPs are slightly more common for business applications, although that is changing. For example, many early ASPs offered large enterprise applications to smaller customers. Newer ASPs offer consumer applications, such as estate or tax planning software, as a service.

I'm not making a distinction between a software publisher that offers its application as an ASP and a software publisher that licenses its application to a third party that then offers it as an ASP. These distinctions, while important for the publisher and the third-party provider, are largely irrelevant for the purposes of this chapter.

Managed Service Provider

A managed service provider (MSP) extends the concept of an ASP by offering an array of services in addition to the operation of the application. In marketing terms, an ASP competes at the level of the generic/expected product while an MSP competes at the level of the expected/augmented product. The exact services offered vary, but usually they include extensive monitoring and backup, and possibly call center support, commerce operations/management, and security/firewall management. Early MSPs targeted the business market. Some recent ones target very specific consumer markets, such as corporate e-mail hosting or digital photo appliances.

MSPs focused on very well-defined specialized hardware market niches will continue to emerge. For example, in the financial services industry some very large MSPs offer online banking services to millions of consumers. Of course, you don't know this because the MSP has allowed the bank offering these services full branding control.

In both ASP and MSP, relationships it is common for service level agreements (SLAs) to precisely define acceptable performance parameters. Also, when the application is a traditional software system, at least some customer data is stored at the service provider. This has important tactical and strategic implications for security and operations that extend far beyond the service actually being offered.

Transactional (Web Service)

A transaction deployment is one that computes an answer in a single, whole transaction, often through Web service protocols. It commonly provides services to individual users, such as when you ask for a map on the Internet. In certain cases end user data may be stored at the service provider, but this is rarely corporate data. This style of system is not yet common in enterprise software, but recent efforts to build complex systems around collections of transactional Web services may dramatically increase its use. Web-service based application architectures will eventually become common for every type of application. This does not mean that they will "win," because they are not appropriate to every market segment. It does mean that we are going to be faced with increasingly sophisticated choices.

The four broad categories just outlined capture the basic deployment options. Savvy marketects have created subtle variants to gain a competitive or positioning edge. For example, some service providers classify themselves as "Internet business service provider" (IBSPs), focusing on a single element of a complex solution (e.g., loan portfolio management for banks). Others define themselves as enterprise application providers (EAPs) and focus on a single kind of enterprise-class system, in the hope that they can leverage that experience across their entire customer base. In the framework presented above, IBSPs and EAPs would be classified as either managed service providers or application service providers, depending on the specific services they offer.

The Hybrid Deployment Architecture

I've been presenting deployment architectures as relatively exclusive choices: either ASPs or MSPs. In fact, there is no technical requirement that the deployment architecture be all one way or another. As is true with other aspects of tarchitecture , it is often best to let your customer and the problem guide you in your choice.

One of the more successful tarchitectures I helped create was a true hybrid. In this case, customers needed realtime access to more than five terabytes of data and required certain kinds of private transactional data. The solution was straightforward: Put some parts of the design, such as the transactional data, at the customer's site; put other parts , such as the five terabytes of data, at a service provider. Making this hybrid architecture work was a bit of a challenge, but the benefits to our customers were worth our efforts.

Related

Категории