Architecture standards: intro and overview (1/7)
Standards management plays an important role in many aspects of organizations. It is frequently seen as a way to improve costing structures, governance, IT-efficiency et cetera. Setting up a good standards practice is by no means simple and straight forward, though.
This is the first in a series of postings on Architecture standards. The series consist of seven postings each covering a different aspect of the subject. In this first posting we will explore why an organization would care about architecture standards in the first place, and also what value a good architecture standards practice can bring to the table. For the content of this series we base ourselves partly on theory from architecture frameworks such as TOGAF , documented best practices, and our own practical experience and lessons drawn from several engagements with client organizations in which we helped building an effective architecture standards practice.
Why architecture standards?
We are convinced that a well defined set of architecture standards as well as an effective standards management practice is a key asset for most organizations. Standards allow enterprise architects to become more effective by aligning with goals such reusability of components (IT related, but also business related, e.g. a business process or capability) and interoperability between systems. Having said this, we have to raise a first red flag here already: setting architecture standards should never be a goal in itself! Putting a standard in place should always have a clear and explicit rationale which, in turn, should be linked to one or more business drivers, such as lowering maintenance costs or faster development of new functionality.
How do architecture standards realize business value?
As mentioned in the previous section, each architecture standard should be aligned with one or more business drivers. These drivers are in their turn derived from the overall strategy as declared by the executive board of the enterprise. If an architecture standard falls short of such a relationship, it is a waste of effort to have and maintain it. In posting 4 of this series we will elaborate on the embedding of architecture standards with similar concepts in other places in the organization (policies, technical specifications, etc.). Below we list some benefits of a good architecture practice that directly translate into business value. These examples are drawn from what we have seen in practice, the list is definitely not meant to be complete.
- Improve efficiency of processes
Architecture standards have an impact on key design choices for new functionality. The earlier in the development process these choices are made, the better. This point is illustrated by the simplified graph, depicting how the cost of change curve for the life cycle of an IT project looks like: the later in the life cycle, the higher (more than linear!) the cost of change.
- Improve interoperability
Think of electricity plugs for your electronic equipment. If you do a lot of travelling, you know that you need a whole bunch of converter plugs to be able to plug in your laptop in all parts of the world. The same holds for interfaces between IT systems. The more standardized these interfaces are, the less “converter plugs” (i.e. band-aid solutions) are needed, the less costs for maintenance, etc.
- Reduce risk
In the next posting (terminology) we will define a standard as some “thing “ or best practice that has proven successful in the past. This past success and experience with the standard mean that reusing it in a new project improves the predictability of the result. This greatly reduces project risk of all sorts. Take for example a standard IT component that handles authorization for access to an application. It was proven in the past that this standard complies with corporate policies on identity and access management. Reusing the component in the development of a new application assures us that the new application also complies with the corporate policy. Hence the risk of a security breach is reduced.
- Lower costs (TCO)
Standardization can result in the reduction of the number of assets in the enterprise landscape. This means a reduction of the total cost of ownership.
How to use standards
Architecture standards do not exist in solitude in the organization. Beside the actual content of the architecture standards themselves, the “standards practice” comes among other things with processes for governance and maintenance, roles and responsibilities, and a common vocabulary. The success of the standards practices depends on how well all this is tied into other processes and frameworks in the organization. This will be a central theme in the subsequent postings in this series. We end this first posting with an overview of the topics of the next postings.
Overview blog series
The figure below visualizes the overview of this blog series. We will briefly explain what will be covered in each of the topics mentioned.
- Terminology
As in every management discipline, communication is a key success factor. There is a need for a common vocabulary. What exactly is a standard? What are types of standards? In this posting we will introduce a framework for architecture standards management, and explain the words that define this framework.
- Documentation
This posting describes an effective approach for the documentation of architecture standards. We will also touch up on how to store the content, and how to maintain this body of architecture standards.
- Embedding
As already brought to bear in this posting, architecture standards do not live in solitude, but should be connected to corporate strategy. In this posting we will elaborate on practical ways to achieve the right level of embedding.
- Life cycle
Change is a constant factor for every organization, and architecture standards need to adapt to changes. That means that the architecture standards have an expiration date on them, and that they should be reviewed on a regular basis. The right processes must be in place to manage the life cycle of architecture standards. In this posting we will describe a practical approach.
- Governance
An architecture standard is worth close to nothing if they are not used in change initiatives such as IT projects. A solid governance process alone is not enough, every effort should be taken to socialize and familiarize end users with the architecture standards available and applicable to them. This will be the last topic of the series, before we issue a final episode in which we wrap-up and summarize.
Outlook
If you’d like to know more, please contact the authors directly at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
/
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
, or leave a comment. The next post in this series covers the introduction of a common terminology to use within a standards practice, and will also include suggestions and examples. It is scheduled to be posted on the 9th of January 2012.
Why architecture standards?
We are convinced that a well defined set of architecture standards as well as an effective standards management practice is a key asset for most organizations. Standards allow enterprise architects to become more effective by aligning with goals such reusability of components (IT related, but also business related, e.g. a business process or capability) and interoperability between systems. Having said this, we have to raise a first red flag here already: setting architecture standards should never be a goal in itself! Putting a standard in place should always have a clear and explicit rationale which, in turn, should be linked to one or more business drivers, such as lowering maintenance costs or faster development of new functionality.
How do architecture standards realize business value?
As mentioned in the previous section, each architecture standard should be aligned with one or more business drivers. These drivers are in their turn derived from the overall strategy as declared by the executive board of the enterprise. If an architecture standard falls short of such a relationship, it is a waste of effort to have and maintain it. In posting 4 of this series we will elaborate on the embedding of architecture standards with similar concepts in other places in the organization (policies, technical specifications, etc.). Below we list some benefits of a good architecture practice that directly translate into business value. These examples are drawn from what we have seen in practice, the list is definitely not meant to be complete.
- Improve efficiency of processes
Architecture standards have an impact on key design choices for new functionality. The earlier in the development process these choices are made, the better. This point is illustrated by the simplified graph, depicting how the cost of change curve for the life cycle of an IT project looks like: the later in the life cycle, the higher (more than linear!) the cost of change. - Improve interoperability
Think of electricity plugs for your electronic equipment. If you do a lot of travelling, you know that you need a whole bunch of converter plugs to be able to plug in your laptop in all parts of the world. The same holds for interfaces between IT systems. The more standardized these interfaces are, the less “converter plugs” (i.e. band-aid solutions) are needed, the less costs for maintenance, etc. - Reduce risk
In the next posting (terminology) we will define a standard as some “thing “ or best practice that has proven successful in the past. This past success and experience with the standard mean that reusing it in a new project improves the predictability of the result. This greatly reduces project risk of all sorts. Take for example a standard IT component that handles authorization for access to an application. It was proven in the past that this standard complies with corporate policies on identity and access management. Reusing the component in the development of a new application assures us that the new application also complies with the corporate policy. Hence the risk of a security breach is reduced. - Lower costs (TCO)
Standardization can result in the reduction of the number of assets in the enterprise landscape. This means a reduction of the total cost of ownership.
How to use standards
Architecture standards do not exist in solitude in the organization. Beside the actual content of the architecture standards themselves, the “standards practice” comes among other things with processes for governance and maintenance, roles and responsibilities, and a common vocabulary. The success of the standards practices depends on how well all this is tied into other processes and frameworks in the organization. This will be a central theme in the subsequent postings in this series. We end this first posting with an overview of the topics of the next postings.
Overview blog series
The figure below visualizes the overview of this blog series. We will briefly explain what will be covered in each of the topics mentioned.
- Terminology
As in every management discipline, communication is a key success factor. There is a need for a common vocabulary. What exactly is a standard? What are types of standards? In this posting we will introduce a framework for architecture standards management, and explain the words that define this framework. - Documentation
This posting describes an effective approach for the documentation of architecture standards. We will also touch up on how to store the content, and how to maintain this body of architecture standards. - Embedding
As already brought to bear in this posting, architecture standards do not live in solitude, but should be connected to corporate strategy. In this posting we will elaborate on practical ways to achieve the right level of embedding. - Life cycle
Change is a constant factor for every organization, and architecture standards need to adapt to changes. That means that the architecture standards have an expiration date on them, and that they should be reviewed on a regular basis. The right processes must be in place to manage the life cycle of architecture standards. In this posting we will describe a practical approach. - Governance
An architecture standard is worth close to nothing if they are not used in change initiatives such as IT projects. A solid governance process alone is not enough, every effort should be taken to socialize and familiarize end users with the architecture standards available and applicable to them. This will be the last topic of the series, before we issue a final episode in which we wrap-up and summarize.
Outlook
If you’d like to know more, please contact the authors directly at This e-mail address is being protected from spambots. You need JavaScript enabled to view it / This e-mail address is being protected from spambots. You need JavaScript enabled to view it , or leave a comment. The next post in this series covers the introduction of a common terminology to use within a standards practice, and will also include suggestions and examples. It is scheduled to be posted on the 9th of January 2012.
Thanks for sharing information
