- Object-Oriented Technology
- Component-Oriented Technology
- Technology Ownership
- Client-Server Technology
- Internet Technology
- Architectural Layers and When to Use Them
- Software Application Experience
- Technology and Application Architecture
- Applying Standards to Application Systems
- Distributed Infrastructures
- Conclusions
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.12 Exercises
EXERCISE 3.1 Assess the state of your current organization (or customer) with respect to the adoption of software paradigms. Prepare a short status assessment document containing recommendations for resolving any gaps in the current skill base.
BACKGROUND FOR SOLUTION: First look at the programming languages being used. Most procedural and OO organizations adopt single-language solutions. Then examine the training requirements. How much training is each developer required to have? We know of major IT organizations that require 9 weeks to as much as 26 weeks of training before they turn developers loose on the shop floor. At a bare minimum, we would suggest 3 weeks. Suppose we're pursuing the OO paradigm. The recommended training is 1 week for "thinking objects," 1 week for OO programming, and 1 week for distributed systems development process and practice (e.g., experiencing systems building in a training environment). These are the recommended absolute minimums. Some of the smartest companies require much more.
EXERCISE 3.2 Assess the state of architectural control within your organization. Are you heavily dependent upon the architecture of a single vendor or set of vendors? What elements of the architecture do you control in a vendor-independent manner? Create a list of recommendations for resolving any discrepancies or shortcomings resulting from excessive vendor dependency.
BACKGROUND FOR SOLUTION: Ask people, "What is our architecture?" If the answer is Oracle or Microsoft, you should be concerned. These are honorable vendor firms, but in our way of thinking, what vendors do is not application architecture. Simple selection of a technology is not sufficient to resolve architectural forces. At a minimum, your enterprise architecture should describe the deployment of technologies and customization conventions for how products are used consistently across systems development. Ideally, your organization has its own APIs that resolve key interoperability issues, as well as rigorously maintained profiles for technology utilization.
EXERCISE 3.3 Assess the state of middleware technologies in your organization (or customer). Identify which technologies are utilized and how effectively they are exploited.
BACKGROUND FOR SOLUTION: In our experience, there is a very high correlation between the technologies utilized and the architectural practices. If you are using several middleware infrastructures in a single application, you are most likely to have ad hoc architectural practices and relatively unmaintainable systems. In the era of CORBA enlightenment, begin to recognize the folly of this approach. Many organizations, being conservative, chose DCE as their corporate middleware solution. However, DCE remains a relatively brittle infrastructure (originating from the "C" procedural generation of technologies). Early adoptions of CORBA frequently resemble DCE-like solutions. As these organizations mature in their use of distributed computing, there is a corresponding flowering of architectural practices. Eventually, solid architectural frameworks like RM-ODP become quite attractive to these organizations because they help architects think much more effectively about managing infrastructure.
EXERCISE 3.4 Describe a case-study experience for your organization as a useful lesson learned for other developers. Which products, versions, and platforms were utilized? How did you use and customize the applications to meet the needs of the application?
BACKGROUND FOR SOLUTION: A case study or "experience report" is quite different than a design pattern although they both share lessons learned. A case study is a specific instance of a successful solution. As you work through this exercise, think about answering the questions that would be most useful to developers encountering a new architectural problem. What elements of the solution are most reusable, in a way that saves time and eliminates risk for readers about to define a new system architecture?
EXERCISE 3.5 Describe the infrastructure dependencies of one or more current applications in your organization. How would you re-architect these systems in their next generation to accommodate technology change more effectively?
BACKGROUND FOR SOLUTION: The worst case is if you are applying vendor technologies without profiling conventions and user-defined APIs. Unfortunately, the worst case is also typical of most organizations. Suppose a vendor provides 300 APIs to access its product. Your developers will use alternate sets of APIs for each project and even within a single system. If you want to migrate to something else, you have a supreme challenge. Consistency in use of product features can work wonders for enabling interoperability and maintainability. The user-defined APIs, although proprietary, are very much under control and not likely to be vendor specific (e.g., CORBA IDL interfaces). To resolve these issues, you need to simplify the choices for how to utilize vendor products (i.e., using profiles) and clearly identify which aspects will be vendor-independent. Reliance on standards is one step. Definition of profiles shows that you have sophistication in the use of standards and products.
EXERCISE 3.6 Which standards are being applied in your organization? Do they supply the desired benefits? Are there any profiles for these standards in your organization? Why or why not? Develop a plan, listing the recommended profiles of standards for your organization. Explain the rationale for why your organization needs each profile specification.
BACKGROUND FOR SOLUTION: Standards, while being one step away from vendor dependence, pose many of the same challenges as integrating with vendor-specific APIs. By definition, standards are very general purpose, applying to as many types of applications as possible. Therefore, the management of complexity is not an important goal for the standards writer. In fact, many standards are overly complicated in order to create barriers for vendor competition. Sophisticated application architects know this, and they plan to manage this complexity (e.g., profiles). We apologize for being so singled-minded about profiles, but this is a key solution concept that most organizations miss—with resulting negative consequences. In one of our favorite quotes, a senior executive laments that "We have created a set of fully standards-compliant stovepipes which can't interoperate." It's dead obvious why that's happened. You didn't read our book—not that we created the concept, which is nearly as old as IT standards themselves.
EXERCISE 3.7 Describe the quality-of-service requirements for the distributed infrastructures in your organization (or customer). What qualities of service are readily supported today? What qualities of service could be usefully added? What distributed technologies would be applicable to meet these needs?
BACKGROUND FOR SOLUTION: A quality of service (QoS) is an important category of architectural requirements for distributed infrastructure. Do you need reliable communications (e.g., funds transfer)? Do you need to support continuous media (e.g., desktop video teleconferencing)? How reliable? How continuous? How secure? These are important questions that drive the selection of infrastructures, the migration plans of enterprises, and the practices of enterprise architects.