Maturity Through Standards
Architecture standards define which products, patterns, and practices are to be used in developing or acquiring software within an organization. In this article, you’ll look at how standards can accelerate application development and lower the total cost of ownership of IT assets.
Although having defined standards is an indicator of maturity in an IT organization, having poorly defined standards may not be better than not having any standards at all due to the risks projects will incur by using them. You’ll look at the characteristics of mature and well-defined standards and a classification scheme for recognizing them.
Architecture standards are subject to change over time. I’ll conclude by looking at a thoughtful architecture standards process to define, catalogue, communicate, mature, and govern standards relevant to your organization.
The Benefits of Standards
Architecture standards define certain boundaries. These boundaries may be what open source or vendor products are to be used in software development. Some examples include the application server, portal framework, Ajax toolkit, content management system, database, or service bus that is mandated or recommended in your organization. Other boundaries may be the architecture patterns and solutions applicable to certain types of business problems such as a business to business (B2B) gateway, multi-user transactional n-tier application, or business intelligence system. Boundaries may even include the practices used to build software such as an architecture baseline, as defined in the Rational Unified Process, or extreme programming.
Because of these boundaries, the developer and application architect may feel that their creativity is being curtailed. What are the benefits of standards? Through the boundaries they define, already solved problems are not revisited. Creativity is not curtailed, but rather, channeled into solving business problems.
Project delivery can be accelerated through architecture standards. For example, a product selection thoughtfully done will serve the needs of multiple projects, eliminating the need for subsequent teams to spend the upfront effort. Codifying standard practices within an organization results in working software being delivered faster and cheaper through tried and true repeatable processes.
By defining product standards, an organization can have fewer, deeper relationships with key product vendors or open source providers. This can result in more advantageous pricing and/or support. Also, selected products are more fully leveraged, and internal expertise with using them is cultivated. This will ultimately result in IT assets that can be managed and maintained over time with a lower total cost of ownership, or TCO.
Not all standards are alike and will realize the promise of accelerating delivery and lowering total cost of ownership. Please examine some characteristics of mature architecture standards.
Subject matter expert (SME) recognition and approval: The first characteristic to consider in assessing standard maturity is whether the proposed standard has passed the initial approval of a subject matter expert in the relevant architecture domain. Often, a proof of concept or product evaluation will be undertaken to prove the use of a product or approach to meet a particular set of functional and non-functional requirements. De facto standards, on the other hand, can be harvested from existing production implementations. In either case, a subject matter expert first must pass judgment on a proposed standard and its wider use in an organization. Sometimes, outside help may be enlisted in making this judgment.
Reference Models and Implementations: A product, pattern, or practice that is documented through a reference model is more likely to be used successfully to solve a particular business problem. A reference implementation increases the chances further because it is a concrete example of the model to be followed. Reference models and implementations that are readily accessible to the architecture and development community provide a kick start to development efforts.
Support Model: A support model must be defined and put in place for a standard product, pattern, or practice. This often includes the development, testing, and production environments needed to leverage it successfully. The roles and responsibilities of the application development teams and support personnel must be clearly defined across all environments. A standard with a fully defined and operational support model is most likely a very mature standard.
Planning Aids: Planning aids help projects using a particular product, pattern, or practice prepare the environment, engage support, and accurately estimate the work effort involved by all partners, ensuring successes can be repeated and failures avoided.
Production Implementations: A project team would much rather use a standard where one or more production implementations exist. Production implementations are a true test in assessing standard maturity.
Absence of one of these standard maturity characteristics puts a project using that product, pattern, or practice at risk:
- Without the thorough evaluation of a SME, a standard may not support its intended use and may overlap unnecessarily with other standards, creating confusion.
- Without a reference model and implementation, a standard may not be used properly and may result in increased development time and cost.
- without a clearly defined support model and organization to support it, gaps and overlaps in roles and responsibilities may result.
- Without planning aids, the benefits of past learning will not be fully leveraged.
- And finally, without production implementations, a standard has not been proven throughout the entire software development lifecycle might be employed.
Architecture Standards Classification
It is helpful to classify standards according to their maturity characteristics. The Standards Maturity Pyramid, depicted in Figure 1, places the least mature standards at the bottom, and the most mature at the very top.
Figure 1: Standards Maturity Pyramid
A submission represents a product, pattern, or practice being considered for a standard. A candidate has passed the scrutiny of subject matter experts. A recommendation has a reference model and implementation in place. A practice has a defined support model and at least one production implementation. A best practice has multiple production implementations and a refined support model.
The architecture standards classification scheme provides an objective way to recognize and mature standards. It prevents standards being set by politics, favoritism, or the influence of vendors on business partners and executives.
This classification loosely follows the W3C (World Wide Web Consortium) standards classification, with the addition of practice and best practice for those organizational architecture standards which are the most mature. Note that, over time, some best practices may be supplanted by newer candidate standards being matured.
An Organizational Standards Process
A process for recognizing, developing, cataloguing, and communicating architecture standards within an organization is needed to realize the benefits of standards. This process ensures that standards are relevant, that they are defined with integrity, and that they are communicated well to all stakeholders.
Figure 2, “How a Bill Becomes a Law,” illustrates a process for defining architecture standards that borrows from the W3C process.
Figure 2: How a Bill Becomes a Law
The architecture standards process begins with a submission representing a product, pattern, or practice to be considered for a standard. This submission is first reviewed by a subject matter expert, and then by a Standards Committee that will determine whether this submission warrants further work. The main criterion in evaluating a submission is relevance across multiple projects, and intersection with previously defined standards.
The Standards Committee may decide to charter a Working Group to mature the submission. The Working Group Charter might include vendor or open source product evaluations; creating reference guides, models, and implementations; determining the support model; reviewing production implementations; engaging outside help; and so forth.
The Working Group presents its deliverables to the Standards Committee. When approved, the standard maturity is assessed (Candidate, Recommendation, Practice, Best Practice) and added to the catalog of standards to be leveraged throughout the organization. It is the responsibility of the Standards Committee to communicate standards to all stakeholders. It is then the responsibility of solution architects and developers to utilize these standards, and of the architecture governance board to ensure their use.
This process for organizational architecture standards ensures that standards are thoughtfully considered, and that the benefits promised are ultimately achieved.
In this article, you saw how architecture standards define the products, patterns, and practices to be used in developing or acquiring software in an organization. You also learned about the many benefits standards provide, mainly accelerating delivery and lowering the total cost of ownership.
All standards are not alike. Characteristics of maturity include subject matter expert approval, reference models and implementations, a support model, production implementations and the time the product, pattern, or practice has been used. These characteristics can be used to classify a standard as a candidate, recommendation, practice, and best practice.
Finally, you reviewed a process, similar to the W3C standards process, that you might use in an organizational setting, to recognize, define, catalog, and mature standards to realize the benefits of accelerated delivery and lower total cost of ownership.
Does your organization have defined architecture standards? Are they classified by their maturity? Is there a process for recognizing, defining, communicating, and maturing standards? Do you have examples of how defined standards have accelerated delivery and lowered total cost of ownership? If not, consider putting into practice some of the concepts discussed in this article. The rest is up to you!
1. W3C, World Wide Web Consortium Process Document, July 19, 2001
About the Author
|Jeff Ryan is an enterprise architect with over twenty years experience architecting and implementing thoughtful solutions to business problems. Jeff led a team that defined and implemented an architecture standards practice in a large organization using the concepts described in this article. He has published over twenty articles on enterprise architecture, SOA, XML, XSLT, Java, and other subjects.|