Preamble
Workflows & Workshops
Taking a leaf from Otto Neurath, enterprise architects “…are like sailors who have to rebuild their ship on the open sea, without ever being able to dismantle it in dry dock and reconstruct it from the best components.” To that effect, enterprise architects need to manage a wide array of evolving documents and artifacts with overlapping life cycles.
These managed elements can be summarily described in terms of:
- Goals: documents describing intents, expectations, and commitments
- Contexts: enterprise organization, activities, and operations
- Models: symbolic representation of environments and systems
- Artifacts: hardware and software components of systems
The objective of EA workflows is to manage the life cycles of these elements along time and across workshops for enterprise, domains, applications, and systems.
The case study workflow is represented using the OWL 2 / Protégé. The Caminao kernel (Cake 2.0) and the case study (A Diner in bOwls) can be consulted on the Protégé portal.
Representation
With the Caminao kernel, representations of EA workflows are organized in terms of requirements and artifacts:
- Initial requirements: business, functional, non functional, technical
- Intermediate requirements: use cases
- Intermediate artifacts: pagoda models
- Final artifacts: applications, services, libraries, etc.
These kernel representations can be applied directly or customized through subtypes.
Work Units
As to ensure complete neutrality, the Caminao framework makes no assumption with regard to the definition of work units and engineering processes. Nevertheless, two basic templates are supported: MBSE and OODA.
Model based systems engineering (MBSE) processes can be organized around use cases and pagoda models (see above).
The definition of work units can be aligned with the Observation/Orientation/Decision/Action (OODA) pattern:
- Observation: assessment of the status of projects
- Orientation: assessment and improvement (negotiation ?) of expectations and commitments
- Decision: commitments/updates/acceptance
- Action: release/delivery/deployment of documents and/or artifacts
Case Study Objectives
Current Situation
The existing Diner’s enterprise architecture includes two restaurants, one warehouse, and a home office.
Since the home office is meant to be unique it is simply represented as a building. That’s not the case for warehouses and restaurants which are expected to be extended and diversified, and thus call for specific building types.
The existing technical architecture is made of three systems for:
- Restaurants, ran locally
- Warehouse, ran on a server for inventories
- Home office, ran on a server for support activities
These systems communicate through FTP files transfers between locations.
Targeted Architecture
The company wants to expand through the purchase of restaurants organized around regional warehouses, and the architecture must be overhauled as to support strategic objectives :
- Restaurants organized along regional profiles, which calls for differentiated menus, local inventories, and regional suppliers
- Business functions (BF) for purchases and logistics managed centrally for warehouses and local inventories
- Human resources and customers relationships managed centrally through ERP
- Technical architecture moved to the Cloud through Platform as a Service (PaaS) and Software as a Service (SaaS)
In line with the pagoda blueprint, the first step is to map business cases (enterprise level) to business functions and communication (system functional level):
Projects & Works Units
Given the pagoda blueprint, the Caminao framework is meant to be neutral with regard to processes: there is no constraint on the way work units are segmented and tasks are defined. That ecumenism is critical for large enterprises where different kind of project management must be combined, typically Agile and phased developments.
In order to ensure that neutrality, EA engineering work units must be first defined in terms of outcome independently of pre-defined activities. Depending on dependencies, these work units would then be distributed between workshops, with workflows organized in line with the methods and/or practices in use.
Projects (sample)
Projects are defined with regard to outcomes and dependencies, typically around shared resources, shared functions, and local applications; in that case:
- Cloud infrastructure: required for the development of applications with Platform as a Service (PaaS) and the deployment of CRM as Software as a Service (SaaS).
- Supplies: two-tiered system (business functions and application), managing centralized supply lines as well as short ones between restaurants and local providers.
- Inventories: two-tiered system (business functions and application), managing regional warehouses as well as the ones managed at the restaurant level.
- Menus: business applications run on restaurants’ premises for the management of menus and local inventories and supplies.
- Customers Relationship Management (CRM): implemented through distributed SaaS.
On that account three projects could be defined:
- Two phased projects, for shared supplies and inventories business functions, to be developed with MBSE
- One iterative project, for menus application, to be developed with Agile
Assuming that technical dependencies are subsumed within the Cloud infrastructure, development dependencies can be managed at two levels:
- Business functions can be directly developed from prescriptive models, with automated management of technical models
- Menus application can be developed iteratively using the services interfaces defined by the Supplies and Inventories technical models.
Workshops & Work Units
As already mentioned, work units should be first associated to initial requirements, final outcomes, or intermediate pagoda models, before being organized into customized engineering processes.
To illustrate the framework ecumenism, this case study applies the OODA pattern to define work units and manage sequencing constraints.
With the CaKe template, the constraints between the four OODA patterns are simply defined in terms of references and execution connectors:
Corresponding work units can be defined directly as instances of the four OODA patterns:
Alternatively, patterns can be customized to take specific engineering methods into account; e.g., Agile developments will mask orientation and decision and iterate between observation and release:
Engineering paths across the factory floor will then be set dynamically according to the status of tasks and the dependency constraints.
Work Units & Workflows
Given a static description of workflows (connectRefer_ and connectExec_), their actual execution can be managed according to concern, typically work units or engineering:
Managing workflows at the work units level deals with resources and deliveries. Engineering constraints and the status of work units are masked and the focus is put on organizational issues.
Managing workflows at the engineering level deals with engineering dependencies and their impact on the definition and sequencing of work units.
The execution of workflows can be managed dynamically according to the status of resources (refResource_). That can be done directly (or “manually”), automatically (based on engineering dependencies), or in mixed assisted mode
Assuming a seamless integration of models within the supporting ontology, machine learning and knowledge graphs can be employed to monitor work units, update or tune dependencies, and assess and improve workflows.
Further Reading
- EA in bOwls
- Modeling Primitives
- EA Patterns
- Conceptual Modeling
- Powertypes
- Enterprise Architect Booklet
- Agile Architectures: Versatility meets Plasticity
- Knowledge-based Models Transformation
- Views, Models, & Architectures
- Abstraction Based Systems Engineering
- EA & MDA
- EA: The Matter of Layers
- EA: Maps & Territories
- EA: Work Units & Workflows
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- Models Transformation & Agile Development