Difference between enterprise, solution and

technical architecture
Example between City planning and any enterprise
Artifacts Properties
Format:

excel, word, power point

Level of details:

level one , or two or three

Or high level, medium level, or low level

Scope:

Application landscape, Business landscape, infrastructure landscape

Can be more specific like computational power in infra structure

Domain:

Four domains BDAT Business, Data, Application and Technology Domains.

Some people are adding another two domains (integration & Information Security)

because sometimes integration are considered as separated from application or basic part of
application.

Also the information security maybe reported to risk management not reported to IT
infrastructure, depend on the organization itself.

Focused State:

This artifact is about AS-IS state or TO-BE state

Stakeholders:

This document is for which people, executives, team leaders, technical people

Usage:

What we shall use this document for

Lifecycle:

This document should be reviewed every one year or three months or six months, we should
clarify that the document can be used now or needs review before usage

Purpose:

I am creating this document for …

Benefit:

This document will help in satisfying specific requirements

CSVLOD
model
Why is CSVLOD preferred over other EA frameworks (Based on the author):
You can either:
1. Read the author published paper. Svyatoslav Kotusev (July 2016), "Enterprise
Architecture Frameworks: The Fad of the Century". It is brief and answers this question.
2. For a more detailed understanding, read Appendix A from the book.

Why I'm recommending CSVLOD:

1. A simple EA Model that is easy to understand, communicate and implement.
2. Realistic & practical EA Model, based on empirical industry practice that I find aligned
with my day-to-day activities.
3. More adaptive to organization processes (Demand Planning, procurement, project
management) where the architecture is considered supporting activities rather than a
process/methodology.
4. Promote the concept of “There is no-one-size-fits-all”:
 Figure 17.2: The dependence of the structure on the size of an organization.
 Figure 17.3: The dependence of the structure on the degree of decentralization.
 Figure 17.9: The structure of Governance committees in different organizations.
5. Introduced practical solutions to EA challenges:
 Chapter 5: The Dialog Between Business and IT. This chapter solves one of the
toughest challenges facing any EA practice, if the business strategy is not published, how
can EA align to business?
 Chapter 19: The Lifecycle of Enterprise Architecture Practice. This chapter
introduces multiple practical ways to establish EA practice rather than the traditional
way of
6. Chapter 19: Introduces three types of productive EA consulting engagement.
7. IMHO, this is the most practical EA that an organization without any consultancy
services can start with.
8. I'm not ignoring other frameworks, rather than using their artifacts or detailed
templates if needed only. I'm not questioning their maturity level.

References:
 CSVLOD Enterprise Architecture Model
 Book: The Practice of Enterprise Architecture: A Modern Approach to Business and IT
Alignment ( ebooks, Amazon ) - Author "Svyatoslav Kotusev" Website
 DPBoK Foundation certification - Linking the dots of Digital Transformation - English
Video
 Digital Practitioner Body of Knowledge (DPBOK) - Arabic Video
 Prompt Engineering Guide
 Some EA Frameworks:
1. Zachman
2. Technical Architecture Framework for Information Management (TAFIM)
3. Federal Enterprise Architecture Framework (FEAF)
4. Department of Defense Architecture Framework (DoDAF)
5. The Open Group Architecture Framework (TOGAF)