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.
Despite the wide range of advice, most enterprise architecture methods appear to go along one of two imbalances: abundance of specifics for artifacts combined with a dearth for modus operandi (epitomized by the Zachman framework), or detailed procedures meant to deal with generic contents (TOGAF a good example). Instead, one should begin with talk of actual practices and continue with a balanced walk.
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.
Iterate across 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. But since that enterprises are to keep sailing, EA is by nature continuous and iterative.
Organization & Responsibilities
All too often EA is undertaken as a big bang project carried out step by step until completion. But like ships, enterprise can neither be put in dry-docks or be submerged and reborn like phoenixes. So enterprise architects have to play agile and phased games and weave business fabric around architectural threads. Organization would broadly follow agile principles, with the details of responsibilities set on a case by case basis depending on each organization and corporate culture.
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.
- Thread: Enterprise Architecture
- 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