8-10 minutes<\/p>\n
Organizations that can manage change effectively are generally more successful than those that cannot. Many organizations know that they need to improve their IT-related development processes in order to successfully manage change, but don\u2019t know how. Such organizations typically either spend very little on process improvement, because they are unsure how best to proceed; or spend a lot, on a number of parallel and unfocussed efforts, to little or no avail.<\/p>\n
The Software Engineering Institute (SEI) \u2013 www.sei.cmu.edu operated by Carnegie Mellon University \u2013 developed the original CMM (Capability Maturity Model) for Software (SWCMM) in 1986s, which is still widely used today. This CMM provided a framework to develop maturity models in a wide range of disciplines.<\/p>\n
Capability Maturity Models (CMMs) address this problem by providing an effective and proven method for an organization to gradually gain control over and improve its IT-related development processes.<\/p>\n
The benefits of capability maturity models are well documented for software and systems engineering. Their application to enterprise architecture has been a recent development, stimulated by the increasing interest in enterprise architecture in recent years, combined with the lack of maturity in this discipline.<\/p>\n
An evaluation of the organization\u2019s practices against the model \u2013 called an assessment \u2013determines the level at which the organization currently stands. It indicates the organization\u2019s maturity in the area concerned and the practices on which the organization needs to focus in order to see the greatest improvement and the highest return on investment.<\/p>\n
The various practices are typically organized into 5 levels, each level representing an increased ability to control and manage the development environment. The 5 levels are:<\/p>\n
No IT architecture program. No IT architecture to speak of.<\/p>\n
Informal IT architecture process underway.<\/p>\n
1. Processes are ad-hoc and localized. Some IT architecture processes are defined.<\/p>\n
2. IT architecture processes, documentation, and standards are established by a variety of ad-hoc means and are localized or informal.<\/p>\n
3. Minimal, or implicit linkage to business strategies or business drivers.<\/p>\n
4. Limited management team awareness or involvement in the architecture process.<\/p>\n
5. Limited operating unit acceptance of the IT architecture process.<\/p>\n
6. The latest version of the operating unit\u2019s IT architecture documentation is on the web. Little communication exists in the IT architecture process and possible process improvements.<\/p>\n
7. IT security considerations are ad-hoc and localized.<\/p>\n
8. No explicit governance of architectural standards.<\/p>\n
9. Little or no involvement in strategic planning and acquisition personnel in the enterprise architecture process. Little or no adherence to existing standards.<\/p>\n","protected":false},"excerpt":{"rendered":"