Whereas enterprise architecture (EA) is a broadly recognized practical concern, there isn’t much of a consensus about it as a discipline. Hence the interest of figuring it out from practice.
Be Specific
Compared to the abundance of advice about EA management, there is a dearth of specifics about what is to be managed, apart from the Zachman framework. So the best approach is to begin with actual practice and try to characterize the specifics of what is actually done.
Separate Structures from Processes
Architecture is about shared assets whose life cycle is not limited to specific activities. Hence the need to set apart processes, which have to change depending on business environments and opportunities, and structures (e.g organization and systems) whose life cycle is meant to be set along a corporate time frame.
Separate Symbolic from Actual
To be of any use EA has to rely on some consensus regarding what is to be managed, and by who. That can only be achieved if some distinction is kept between symbolic descriptions (the equivalent of blueprints) of information and processes on one hand, actual objects (e.g legacy) or activities on the other hand. That distinction between maps and territories can be seen as the cornerstone of EA as a discipline.
Add Time Frames
At the end of the day success will be decided by the fruitful combination of enterprise assets (financial, physical, logical, human) and business context and objectives. Defining their respective life cycles and planning the necessary changes could be seen as the primary responsibility of enterprise architects.
Add Responsibilities
Last and least, allocating responsibilities is probably better carried out on a case by case basis depending on each organization and corporate culture.
That’s All
Those few principles may seem unassuming but they provide a sound basis that takes full advantage of what staff and management know about their enterprise resources and practices. And never forget that continuity is a critical factor of EA success.
Further Reading
- Thread: Enterprise Architecture
- Enterprise Architects Booklet
- EA: Maps & Territories
- EA: Work Units & Workflows
- EA: Case Study
- Architectures
- Models, Architectures, Perspectives (MAPs)
- Architecture Capabilities
- Capabilities vs Processes
- Enterprise Governance & Knowledge
- Enterprise Architectures & Separation of Concerns
- From Processes to Services
- EA & MDA
- EA Documentation: Taking Words for Systems
- Abstractions & Emerging Architectures
- EA: Entropy Antidote
- Regulations & Risks
- Events & Decision Making
- Alignment for Dummies
- Alignment: from Entropy to Abstraction
- Enterprise Systems & the OS Kernel Paradigm