Standards Software Architecture Lecture 26 Copyright Richard N Taylor Nenad Medvidovic and Eric M Dashofy All rights reserv Software Architecture Foundations Theory and Practice Objectives Concepts What are standards Why use standards And why not drawbacks Deciding when to adopt a standard Prevalent Architectural Standards Conceptual standards Notational standards Standard tools Process standards 2 Software Architecture Foundations Theory and Practice Objectives Concepts What are standards Why use standards And why not drawbacks Deciding when to adopt a standard Prevalent Architectural Standards Conceptual standards Notational standards Standard tools Process standards 3 Software Architecture Foundations Theory and Practice What are standards Definition a standard is a form of agreement between parties Many kinds of standards For notations tools processes organizations domains There is a prevalent view that complying to standard X ensures that a constructed system has high quality This is almost never strictly true But that doesn t mean standards are worthless Here we will attempt to put standards in perspective 4 Software Architecture Foundations Theory and Practice De jure and de facto standards Some standards are controlled by a body considered authoritative ANSI ISO ECMA W3C IETF These standards are called de jure from law De jure standards usually are formally defined and documented are evolved through a rigorous well known process are managed by an independent body governmental agency or multi organizational coalition rather than a single individual or company 5 Software Architecture Foundations Theory and Practice De jure and de facto standards cont d Some standards emerge through widespread awareness and use These standards are called de facto in practice De facto standards usually are created by a single individual organization to address a particular need are adopted due to technical superiority or market dominance of the creating organization evolve through an emergent market driven process are managed by the creating organization or the users themselves rather than through a formal custodial body 6 Software Architecture Foundations Theory and Practice Examples of de jure and de facto De jure standards UML managed by OMG CORBA also managed by OMG HTTP protocol managed by IETF De facto standards PDF format managed by Adobe May become de jure through ISO Windows managed by Microsoft There is a substantial gray area between these two 7 Software Architecture Foundations Theory and Practice Gray area Standards HTML Officially standardized by W3C indicating de jure Flavors and browser specific extensions developed by Microsoft Netscape and others creating de facto variants None of these has power to force users to use standard JavaScript Developed by Netscape copied as JScript by Microsoft After substantial adoption and possibly under threat of forking splintering Netscape submits it to ECMA Now standardized as ECMAScript de jure JavaScript and variants continue to be developed as compatible extensions of ECMAScript 8 Software Architecture Foundations Theory and Practice Another spectrum Standards whether de jure or de facto can be Open Allow public participation in the standardization process Anyone can submit ideas or changes for review Closed a k a proprietary Only the custodians of a standard can participate in its evolution 9 Software Architecture Foundations Theory and Practice Open vs closed standards Another spectrum with a gray area Some standards bodies have high barriers to entry e g steep membership fees vote of existing membership Some standards e g Java have aspects of both Sun Microsystems is effectively in control of Java as a de facto standard There is an open community process by which external parties can participate in a limited way 10 Software Architecture Foundations Theory and Practice Why use standards Standards are an excellent way to create and exploit network effects A network effect exists if the value of participation increases as the number of users of the standard increases versus Other network effects TCP IP HTTP HTML UML 11 Software Architecture Foundations Theory and Practice Why use standards cont d To ensure interoperability between products developed by different organizations Usually in the interest of fostering a network effect To carry hard won engineering knowledge from one project to another To take advantage of hard won engineering knowledge created by others As an effort to attract tool vendors To create economies of scale in tools To attempt to control the standard s evolution in your favor 12 Software Architecture Foundations Theory and Practice Drawbacks of standards Limits your agility Remember that doing good architecturebased development means identifying what is important in your project Standards often attempt to apply the same techniques to a too broad variety of situations The most widely adopted standards are often the most general 13 Software Architecture Foundations Theory and Practice Overspecification vs underspecification A perennial tension in standards use and development Overspecification A standard prescribes too much and therefore limits its applicability too much Underspecification A standard prescribes too little and therefore doesn t provide enough guidance Possibly in an effort to broaden adoption 14 Software Architecture Foundations Theory and Practice Two different kinds of underspecification Two compromises often made in negotiation when disagreements occur Leave the disagreeable part of the standard unspecified or purposefully ambiguous Include both opinions in the standard but make them both optional Both of these weaken the standard s value Consider the different kinds of reduction in interoperability imposed by these strategies Although they may improve adoption 15 Software Architecture Foundations Theory and Practice When to adopt a standard Early adoption Benefits Improved ability to influence the standard Get your own goals incorporated exclude competitors Early to market If standard becomes successful early marketers will profit Early experience Leverage enhanced experience to your benefit 16 Software Architecture Foundations Theory and Practice When to adopt a standard cont d Early adoption Drawbacks Risk of failure Standard may not be successful for reasons out of your control Moving target Early standards tend to evolve and churn more than mature ones and may be buggy Lack of support Early