Objective
While enterprise architecture has become a primary concern for a wide range of organizations, practitioners are looking at the discipline from various perspectives, often with conflicting understandings depending on their standpoint, information systems or business management. Yet, a significant part of the differences may be more of words than substance, and that could be helped by setting the arguments within some concrete playground. Given that actual corporate grounds are arguably not for play, a mock-up could be used to frame the arguments about EA framework requirements.
Introducing the mock-up
When EA frameworks are considered, requirements can be organized along four basic functionalities:
- How to describe current architectures capabilities.
- How to formulate corporate strategies and business objectives in terms of architectures capabilities.
- How to identify and analyze alternative transition scenarii from current architectures capabilities to targeted ones.
- How to plan, pilot and assess transformation processes.
Basically, and without undue simplification, those functionalities can be supported by two kinds of models, one for architecture assets, the other for enterprise processes.
Enterprise architecture models describe organizations and resources meant to support business objectives and processes. The mock-up organizes their description by combining the standard architecture levels (business, systems, platforms), with Zachman framework capabilities (Who, What, How, Where, When).
Enterprise processes (not to be confused with business ones) models describe objectives and ongoing activities whose purpose is to change enterprise architectures. On that regard, the mock-up is aligned on the three basic phases for requirements (supported business processes), analysis (supporting systems functionalities), and design (operational solutions).
The aim of the mock-up is to explore the relationship between architectures and processes: in manual mode users can browse through architecture capabilities across levels, directly or with the help of predefined blueprints. In assisted mode users explore the relationship between changes in architecture capabilities on one hand, enterprise processes on the other hand.
Manual (aka capability) vs Assisted (aka process) modes
In manual mode users can select capabilities from the architecture view (top) and see their relationships in the capabilities view (bottom), where changes (CRUD operators) can be edited (dashed lines are for read-only dependencies). Primitives for changes (CRUD) can be set from the architecture view (pop-up menus) or directly to capabilities (combos).
Capabilities can also be browsed across levels, with or without templates. Using the yo-yo button will cascade capability changes across layers.
In assisted mode options are constrained by predefined masks applied on architecture constituents. Changes to footprint capabilities are initialized with default operation and can be directly modified; others are initially disabled but can be reactivated using cascade.
Use cases examples
While the mock-up blueprints have no special relevancy, they can be used as starting points for EA framework use cases, e.g:
- Business knowledge: how to improve information and understanding of business environment (markets, suppliers, customers, etc).
- Operational knowledge: how to improve the monitoring of operational performances and costs.
- Development effectiveness: how to improve the launch of new products or services (delays, quality, costs).
- Operational effectiveness: how to improve the delivery of products and services (delays, quality, costs).
One step further towards KM, EA should be supported by a conceptual thesaurus that would bring shared concepts under the same semantic roof.
Further Reading
- MDA & EA: Is The Tail Wagging The Dog ?
- Models, Architectures, perspectives (MAPs)
- Architecture Capabilities
- Enterprise Architecture & Separation of Concerns
- Architecture Driven System Modeling
- Open concepts
- Conceptual thesaurus