Maturity Through Standards
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.