Begin defining a common platform and architecture for e-business application development

Common Ground

Alex Hawkinson & Brian Winter

In our inaugural column, “Optimizing Time-to-Value,” in the October 5 issue, we introduced the concept of time-to-value (t2v) and explained that, in order to optimize it, you need to adopt a standard platform. To review, t2v is quite simply the simultaneous need for speed and volume of results from an investment; not just ROI, but also velocity of both initial and recurring returns. The e-business developer today has an increasingly vital role in improving t2v, and in this issue we’ll provide more detail about how to begin the process of standardizing your platform for the best results.

A common platform and framework, termed a managed application system (MAS) architecture, is a collection of standards, best practices, and application architectures to which you can refer when building and deploying new applications. Its goal is to provide a highly manageable and uniform production platform giving all an organization’s developers a common application framework, thereby supporting code sharing and reusability. With a common framework and foundation on which to build Web-based applications, the IT organization will help maximize t2v by decreasing capital outlays, reducing project costs, increasing reusability and leverageability, and introducing consistency among all applications.

To build an MAS architecture tailored for your business, you must seamlessly integrate the top-level elements of an enterprise architecture — the business architecture, platform technology architecture, and application architecture and methodology.

Business Architecture

Your first consideration should be the business requirements your organization needs to address and the role a standard architecture will play in meeting those requirements. Far too often, businesses begin the application development process with a technology-based solution and risk finding out after significant investment that it was ill conceived.

As we mentioned in the October 5 issue, at a top level the business architecture:

•Drives the strategic decisions for the technology architecture

•Identifies what data is strategic to the enterprise

•Provides direction for the implementation of information technology

•Identifies strategic business services and applications.

You must know what data is important, who the audiences are, and from where the data originates. You also need to know what the business’s timelines are for new capabilities, as well as how often and how rapidly the business requirements change or evolve.

Starting with business requirements will help you avoid using technology for technology’s sake and focus instead on using solid business foundations for each initiative. It is important to note that this statement does not necessarily imply you should cut R&D efforts; properly focused R&D can be one of the most strategic initiatives an organization can undertake.

Platform Technology Architecture

The platform technology architecture is the predefined set of standards and technologies underlying every line of business (LOB) application you deploy. Done correctly, it will fully leverage your common technologies and components to deliver mission-critical business applications.

FIGURE 1 Platform technology architecture.


To review from last time, a top-level platform technology architecture:

•Provides open, vendor, and private standards for selecting technologies and APIs

•Provides base technologies and components, as Figure 1 shows, that support the following services: directory and security, management, network, and base

•Provides an outline of the enterprise’s base technology

•Provides a context for identifying skills acquisition and training needs.

Directory and security services. In a distributed computing system or a public network such as the Internet, users want to find and use many different objects, such as printers, fax servers, applications, databases, and other users. Administrators want to manage how these objects are used, and they can — with a directory service, which will:

•Enforce administrator-defined security to keep information safe from intruders

•Distribute a directory across many computers in a network

•Replicate a directory to make it available to more users and resistant to failure

•Partition a directory into multiple stores so it can accommodate very large numbers of objects.

Management services. Management is an obvious cornerstone to a complete platform technology architecture. Management services should include fault, configuration, accounting/cost, and performance management.

Fault management helps identify, analyze, and maintain logs of failures in network and application operation and should generate status information to keep users notified of changes in service-level agreements. Configuration management monitors the continuous operation of the network and service appli- cations daily, particularly the changes in the network configuration that occur over time. Accounting/cost management records users’ network load and charges them appropriately. Performance management measures the responsiveness and reliability of the network or application and controls network and application activities.

Security services. The architecture must enforce strong yet flexible security policies and technologies under a variety of conditions of authentication, authorization, privacy, integrity, and non-repudiation. The technology you choose must complement security policies, not vice versa.

Network services. The architecture must be able to link together numerous servers and applications across wide geographic areas and provide numerous types of services such as remote user access, bandwidth allocation, security, network management, addressing, and error recovery. It’s important to keep in mind that network services are tightly interlinked with all parts of the platform architecture.

Methodology and Application Architecture

E-business developers understand the value of a multi-tiered, or n-tiered, architecture. (See Microsoft DNA at microsoft.com/dna for an excellent example.) However, perhaps the most often neglected aspect of any enterprise architecture is the development methodology for building applications. Such a methodology will allow you to rapidly produce and evolve new LOB applications that provide the flow of new capabilities the business architecture demands, while fully leveraging all the elements of the platform architecture. Properly enforcing this development methodology will greatly improve your t2v as well as dramatically lower your TCO over the life of any application you deploy. Of course, the devil is in the details. So we compiled a list of guiding principles from the numerous published methodologies and application architectures, to help you select your own unique methodology and architecture:

•Internet readiness. Develop solutions that fully exploit the application platform’s flexibility and the Internet’s global reach and on-demand communication capabilities.

•Faster time-to-market. Develop and deploy solutions rapidly without requiring developer reeducation or a paradigm shift in how software is built. Expose services and functionality through the under- lying “plumbing” to reduce the amount of code that developers must write.

•True interoperability. Build interoperability into all tiers so you can add functionality to existing systems. Adhere to open protocols and standards so you can integrate other vendor solutions.

•Reduced complexity. Integrate key services directly into the operating system and expose them in a unified way through the components. Reduce IT professionals’ need to function as system integrators, so that they can focus on solving the business problem.

•Language, tool, and hardware independence. Provide a language-neutral component model so that developers can use task-appropriate tools. Build on the PC model of computing, wherein customers can deploy solutions on widely available hardware.

•Lowered TCO. Develop applications that are easy to deploy, manage, and change over time.

Remember, the goal of the MAS architecture is to provide a highly manageable and uniform production platform that fosters code sharing and re- usability, and balances business needs with a common platform architecture and development methodology. An MAS architecture that balances all these factors and is tailored to your business will let IT organizations deliver projects on time and under budget more often, delivering value back to the business faster and more frequently — thus maximizing t2v, the new measurement for e-success.

Alex Hawkinson is vice president of architecture and technology for USWeb/CKS’s e-services division. He has 16 years of experience at USWeb and was a founding partner of that company’s Washington, D.C. group. You can reach him at ahawkinson@uswebcks.com.

Brian Winter is vice president of service development for the USWeb/CKS e-services division. You can reach him at bwinter@uswebcks.com.