Caminao EA Workbench (Mock-up)

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.

Eduardo Neri perspetivas-a-reas-1970
How to frame enterprise architecture representations (Eduardo Neri)

Introducing the mock-up

When EA frameworks are considered, requirements can be organized along four basic functionalities:

  1. How to describe current architectures capabilities.
  2. How to formulate corporate strategies and business objectives in terms of architectures capabilities.
  3. How to identify and analyze alternative transition scenarii from current architectures capabilities to targeted ones.
  4. 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 architects are presented with views of architectural assets and associated processes.
Enterprise architects are presented with views of architectural assets and associated processes.

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).

vvv
Requirements capture

Capabilities can also be browsed across levels, with or without templates. Using the yo-yo button will cascade capability changes across layers.

Capabilities can be combined across levels
Capabilities can be combined across levels

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.

Changes to capabilities of process templates can be set from both views.
Changes to capabilities of process templates can be set from both views.

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

External Links

Leave a Reply

%d bloggers like this: