Help:ArchiSurance Use Case
Jump to navigation
Jump to search
ArchiSurance use case
How is this infrastructure architecture repository filled, used and maintained? And what role does it play regarding infrastructure development processes? Who are involved in either or both the preparation/maintenance of the wiki and the utilization of it? This simple use case description tries to give brief but concise answers to these questions.
Actors
| EA: | Enterprise Architect |
| Dept. head: | Department head |
| DA: | Domain Architect |
| PA: | Project Architect |
| Designer: | Lead engineer/designer of project team |
| Svc Mgr: | Service Manager |
| Ops: | Operations |
Wiki preparation
- step (a) The architecture repository is filled with default content: default Working Areas, default Building Block Types, default Quality Attributes
- step (b) EA inputs architecture Principles
- step (c) Dept. head inputs Environments under Working Area that corresponds to his department (e.g. Front Office inputs all Environments under Client Realm
- step (d) DA creates quality attribute classes and their properties, custom Building Block Types, (universal) Building Block Variant descriptions and Elements.
The diagram below shows a graphic representation of the use case of the architecture wiki. Depicted are two processes: the preparation of the repository, and using the repository to realise an infrastructure facility under architecture.
Use case: realizing a new infrastructure facility
- step (1) The customer appoints a PA to realise (a.o.) an infrastructure facility. The customer provides the PA with needs, requirements and a business case.
- step (2) The PA[1] consults relevant architecture principles, Environment descriptions (Quality Requirements of usage context) and already available feasible solutions, in the form of (Pattern Types or) Building Block Types. With this information, the PA[1] creates one or more architecture studies, containing high-level drafts of feasible solutions. These drafts, based on the selected Pattern Types and Building Block Types in the repository, depict possible 'to-be' solutions.
- step (3) Based on the architecture studies, the PA researches available and eligible Pattern Variants and Building Block Variants. Based on this information, PA[1] determines the impact of the new solution on the 'as-is' situation.
- step (4) if necessary, the PA[1] creates new Building Block Variants/Pattern Variants, describing the target architecture of (new) facilities.
- step (5) The Designer consults the selected and/or created Building Block Variant/Pattern Variants, and creates an infrastructure facility design in accordance with the BBV's/PV's.
- step (6) if convenient, the Designer creates a Design Outline. And if necessary, he puts extra indications for use in the Building Block Variants/Pattern Variants, and/or he updates or adds Elements.
- step (7) The Service Manager reads the properties of the new infrastructure facility from its Design Outline, its Building Block Variants/Pattern Variants and its quality attributes. Based on this, she creates an OP (Operational Product)
- step (8) Operations needs to perform maintenance, and checks the Blueprints for characteristics/indications for usage