- 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.9 Applying Standards to Application Systems
In the adoption of object-oriented architectures and technologies, many common questions are raised. They must be resolved to understand the implications fully. The questions of defining object orientation and the component technologies that comprise object technologies have already been reviewed, as has a discussion on how object technologies compare with others, such as procedural technology.
Many other questions and requirements are crucial to certain categories of applications. Questions about performance, reliability, and security on the Internet and how these technologies integrate with vendors that have significant market share are all important considerations in the adoption of these technologies. The next few chapters explain some of the fundamental concepts that describe the commercial and application sides of object-oriented architecture. Furthermore, the case is made for the application of open systems technologies in object-oriented software development practice. Additionally, application development issues on applying object technology, integrating legacy systems, and monitoring the impact of these technologies on procurement and development processes are addressed.
It is important to understand that commercial technologies based upon open systems evolve according to certain underlying principles. These principles are clearly defined through a model developed by Carl Cargill that describes the five stages of standardization (Figure 3.17). To initiate an open systems standards process, it is necessary to define a reference model. A reference model defines the common principles, concepts, and terminology that are applied across families of standards. These reference models also apply to object-oriented architectures and the integration of application systems. Reference models are an element that is often missing in software engineering processes that address complex issues. Developing a formal reference model through a formal open systems process takes a considerable amount of effort from numerous people.
)
Figure 3.17. The Five Stages of Standardization
A typical reference model from the international standards organization may take up to ten years to formulate. Based upon a reference model, a number of industry standards can be initiated and adopted on a somewhat shorter time scale for formal standardization; this ranges up to seven years. Both reference models and industry standards are usually the intellectual product of groups of technology vendors. The standards represent the most general common denominator of technologies across the largest consumer base. In order to apply these technologies, it is necessary to define a number of profiles that serve the role of reducing the complexity of applying the standard within a particular domain or set of application systems (refer to Figure 2.13b).
){kind=link}
There are two different kinds of profiles. Functional profiles define the application in general terms of a standard for a specific domain. Typical domains might include mortgage lending or automobile manufacturing. The functional profiles define the common usage conventions across multiple companies within the same industry. Functional profiles can be the product of information technology vendors but usually are a joint product between the users of technology and the vendors.
The next level of profiles is called system profiles. System profiles define how a particular family of systems will use a particular standard or set of standards. The family of systems is usually associated with a certain enterprise or virtual enterprise. For example, a set of electronic data interchange standards for the Ford Motor Company defines how the company and its suppliers for the manufacturing process can provide just-in-time inventory control so that Ford's assembly lines can proceed in an organized fashion without interruptions.
Above system profiles are application systems, which are specific implementations. Even though the concept of profiles is new to many software engineers, profiles are implemented, perhaps implicitly, in all systems. Whenever a general-purpose standard or a commercial technology is applied, decisions are made regarding the conventions of how that technology is used, and those decisions comprise a profile. Unfortunately, many of the important profiles are buried in the implementation details of information systems. Notice that, in Figure 2.13b, the time scales for developing each of the types of specifications is decreasing. The intention is that the reference models provide a stable architectural framework for all the standards, profiles, and systems that are developed over a longer term. The industry standards provide the next level of stability and continuity, the profiles provide stability and consensus across domains and application families, and all these mechanisms support the rapid creation of application systems on the order of half a year to a year and a half.
Figure 3.18 shows the breakout of reference models and profiles from the perspective of a particular vendor of information technology. In general, a vendor is working from a single reference model that spans a number of industry standards. The vendor implements technologies conformant with these standards and then works with various application developers and vertical markets to define the usage of the technology for valuable business systems. There is a multiplying factor for vendors in this approach in that for a small group of vendors potentially numerous customers are enabled by the technologies that they supply.
)
Figure 3.18. Standards from the Vendor's Perspective
Figure 3.19 portrays the concept from the perspective of the end-user application developer. This diagram is somewhat amusing in a dark sense, but it is very representative of the kind of challenges that object-oriented architects in all kinds of information technology are facing today. For a given application system, numerous standards and reference models are potentially applicable to the development of that system. A smaller number of functional profiles and system profiles can be obtained off the shelf to guide application system development. In general there is a gap between the application implementations and the industry standards in the area of profiling. Because profiling is primarily the responsibility of users, it's appropriate to say that the users are to blame for this gap in guidance.
)
Figure 3.19. Standards from the User and Application Developer's Perspective
When profiles are not agreed to between application system projects, the likelihood is that the systems will not be interoperable, even though they are using identical industry standards and even products from the same vendors. This can be a confusing and frustrating situation for application architects. It is necessary to understand these principles in order to resolve these kinds of issues for future system developments.