The CSVLOD model of enterprise architecture
The CSVLOD model of enterprise architecture (or simply the CSVLOD model) is a comprehensive research-based conceptual model explaining the notion of enterprise architecture (EA) and its core components.[1] It describes fundamental types of EA artifacts and their key properties in the context of an EA practice. The model's name represents an abbreviation of the first letters from the six general types of EA artifacts it defines: Considerations, Standards, Visions, Landscapes, Outlines and Designs.
Overview[edit]
The key element of the CSVLOD model is the taxonomy for EA artifacts providing a classification scheme for grouping diverse EA artifacts into six consistent groups according to their essential roles and properties.
Considerations[edit]
Considerations describe global conceptual rules and fundamental considerations important for business and relevant for IT. They are dual EA artifacts relevant to both business leaders and architects. Considerations usually either do not focus on specific points in time or focus on the long-term future. They are typically expressed in simple intuitive formats, often as brief written statements. Specific EA artifacts related to Considerations used in successful EA practices include, but are not limited to, the following articulate subtypes:
Considerations represent planning decisions on how an organization needs to work from the IT perspective. They are developed collaboratively by senior business executives and architects and then used to influence all “downstream” architectural decisions. As permanent EA artifacts, Considerations are developed once and then updated according to the ongoing changes in the business environment. Considerations can be considered as the overarching organizational context for information systems planning. The general purpose of all Considerations is to help achieve the agreement on basic principles, values, directions and aims. The proper use of Considerations leads to improved overall conceptual consistency between business and IT.
Standards[edit]
Standards describe global technical rules, standards, patterns and best practices relevant for IT systems. They are not dual EA artifacts and relevant mostly to architects. Standards usually either do not focus on specific points in time or focus on the current state. They can be expressed in various formats, often using strict notations. Specific EA artifacts related to Standards used in successful EA practices include, but are not limited to, the following articulate subtypes:
- Technology reference models
- Guidelines
- Patterns
- IT principles
- Logical data models
Standards represent mostly planning decisions on how all IT systems should be implemented and some facts on the current approaches and technologies. They are developed collaboratively by architects and technical subject-matter experts and used to shape architectures of all IT initiatives. As permanent EA artifacts, Standards are developed on an as-necessary basis and updated according to the ongoing technology progress. Standards can be considered as proven reusable means for IT systems implementation. The general purpose of all Standards is to help achieve technical consistency, technological homogeneity and regulatory compliance. The proper use of Standards leads to faster delivery of new IT initiatives and reduced IT-related costs, risks and complexity of the IT landscape in general.
Visions[edit]
Visions provide high-level conceptual descriptions of an organization from the business perspective. They are dual EA artifacts relevant to both business leaders and architects. Visions often focus on the long-term future up to 3–5 years ahead. They are typically expressed in brief informal formats, often as simple one-page diagrams. Specific EA artifacts related to Visions used in successful EA practices include, but are not limited to, the following articulate subtypes:
- Business capability models[4]
- Roadmaps
- Target states
- Value chains
- Context diagrams
- Core diagrams[5]
Visions represent mostly planning decisions on what IT should deliver to an organization in the long run. They are developed collaboratively by senior business executives and architects and then used to guide IT investments, identify, prioritize and launch new IT initiatives. As permanent EA artifacts, Visions are developed once and then updated according to the ongoing changes in strategic business priorities. Visions can be considered as shared views of an organization and its future agreed by business and IT. The general purpose of all Visions is to help achieve the alignment between IT investments and long-term business outcomes. The proper use of Visions leads to improved strategic alignment and effectiveness of IT investments.
Landscapes[edit]
Landscapes provide high-level technical descriptions of the organizational IT landscape. They are not dual EA artifacts and relevant predominantly to architects. Landscapes more often focus on the current state. They are typically expressed in strict formats, often as complex one-page diagrams using formal modeling notations, e.g. ArchiMate. Specific EA artifacts related to Landscapes used in successful EA practices include, but are not limited to, the following articulate subtypes:
- Landscape diagrams
- Inventories
- Enterprise system portfolios
- IT roadmaps
Landscapes represent mostly facts on the current IT landscape and some planning decisions on its future evolution. They are developed and maintained by architects and used to rationalize the IT landscape, manage the lifecycle of IT assets and plan new IT initiatives. As permanent EA artifacts, Landscapes are developed on an as-necessary basis and updated according to the ongoing evolution of the IT landscape. Landscapes can be considered as a knowledge base of reference materials on the IT landscape. The general purpose of all Landscapes is to help understand, analyze and modify the structure of the IT landscape. The proper use of Landscapes leads to increased reuse and reduced duplication of IT assets, improved IT agility and decreased dependence on legacy IT systems.
Outlines[edit]
Outlines provide high-level descriptions of specific IT initiatives understandable to business leaders. They are dual EA artifacts relevant to both business executives and architects. Outlines usually focus on the mid-term future up to 1–2 years ahead. They are typically expressed as a mix of textual descriptions and simple diagrams. Specific EA artifacts related to Outlines used in successful EA practices include, but are not limited to, the following articulate subtypes:
- Solution overviews
- Options assessments
- Initiative proposals
Outlines represent planning decisions on how approximately specific IT initiatives should be implemented. They are developed collaboratively by architects and business executives and then used to evaluate, approve and fund specific IT initiatives. As temporary EA artifacts, Outlines are developed at the early stages of IT initiatives to support decision-making and then archived. Outlines can be considered essentially as benefit, time and price tags for proposed IT initiatives. The general purpose of all Outlines is to help estimate the overall business impact and value of proposed IT initiatives. The proper use of Outlines leads to improved efficiency and ROI of IT investments.
Designs[edit]
Designs provide detailed technical and functional descriptions of specific IT projects actionable for project teams. They are dual EA artifacts relevant to both project teams and architects. Designs usually focus on the short-term future up to one year ahead. They are typically expressed as a mix of text, tables and complex diagrams, can be voluminous and often use formal modeling notations, e.g. UML. Specific EA artifacts related to Designs used in successful EA practices include, but are not limited to, the following articulate subtypes:
Designs represent planning decisions on how exactly specific IT projects should be implemented. They are developed collaboratively by architects, IT project teams and business representatives and then used by project teams to implement IT projects. As temporary EA artifacts, Designs are developed at the later stages of IT initiatives to support implementation and then archived. Designs can be considered as communication interfaces between architects and project teams. The general purpose of all Designs is to help implement approved IT projects according to business and architectural requirements. The proper use of Designs leads to improved quality of the IT project delivery.
See also[edit]
References[edit]
- ↑ Kotusev, Svyatoslav (2018) The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment. Melbourne, Australia: SK Publishing.
- ↑ Greefhorst, Danny, and Erik Proper (2011) Architecture Principles: The Cornerstones of Enterprise Architecture. Berlin: Springer.
- ↑ Broadbent, Marianne, and Peter Weill (1997) "Management by Maxim: How Business and IT Managers Can Create IT Infrastructures", MIT Sloan Management Review (38:3), pp. 77-92.
- ↑ Scott, Jeff (2009) "Business Capability Maps: The Missing Link Between Business Strategy and IT Action", Architecture and Governance Magazine (5:9), pp. 1-4.
- ↑ Ross, Jeanne W., Peter Weill, and David Robertson (2006) Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, MA: Harvard Business Press.
- ↑ Beijer, Peter, and Theo de Klerk (2010) IT Architecture: Essential Practice for IT Business Solutions. Lulu.com.
- ↑ Wagter, Roel, Martin van den Berg, Joost Luijpers, and Marlies van Steenbergen (2005) Dynamic Enterprise Architecture: How to Make It Work. Hoboken, NJ: John Wiley & Sons.
External links[edit]
- Enterprise Architecture on a Page (June 2018)
- Six Types of Enterprise Architecture Artifacts (November 2016)
- Eight Essential Enterprise Architecture Artifacts (February 2017)
- The Relationship Between Enterprise Architecture Artifacts (March 2017)
- A Fresh Look at Enterprise Architecture Artifacts (December 2017)
This article "The CSVLOD model of enterprise architecture" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:The CSVLOD model of enterprise architecture. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.