Example of a Conceptual Architecture Diagram
A few days ago I wrote a post about creating conceptual architectures using the Visual Architecting Process of Dana Bredemeyer and Ruth Malan. Kalle Pokkinen suggested that a sample diagram would be a great help, and I agreed. So I thought I would do more than just give a sample diagram, I would give a small sample conceptual architecture including a diagram and the accompanying documentation. Please note that this is a sample, it is not a complete or full conceptual architecture. It has not been through the rigorous process of peer review and interrogation that we would expect of a real architecture. It is merely intended to illustrate the use of the process and templates from the Visual Architecting Process. The example here just shows a diagram of the conceptual components, and a brief description of them. It doesn’t include other aspects of a conceptual architecture such as a architecturally significant requirements, system qualities or architectural mechanisms. However, it should be enough to give you an idea of what a conceptual architecture might look like. If you like it – let me know. If you have any questions about it – feel free to give me a shout in the comments!
This example is of a conceptual architecture (or part of one) for an IT service request system which includes the ability for users to raise requests themselves through a self-service mechanism, rather than having to log all requests by calling a help desk. It also automates the management of the work-flow of the service requests, and the creation of individual assets in an asset “register” (or inventory) if the service request results in the provisioning or assignment of inventory (e.g. if a piece of hardware is assigned, or a piece of software is deployed to a desktop).
The conceptual architecture is composed of four separate components: the Service Request Portal; the Service Request Manager; the Asset Manager and the Service Request Catalogue. The architecture is divided into two layers: a user interaction layer (in grey), and an application layer (in orange). Each component is described in terms of:
- Responsibilities: responsibilities assigned to the component.
- Collaborators: components the component depends on for services.
- Rationale: the rationale for assigning responsibilities to the component, traceability to requirements and system qualities.
- Issues: any issues with the component.
Service Request Portal
Responsibilities:
- Allow users to initiate service requests for services offered in the Service Request Catalogue.
- Allow users to view their own service requests and check on progress.
- Allow users to approve service requests assigned to them.
Collaborators:
- Service Request Catalogue provides information about services that are available via the Service Request Portal.
- The Service Request Portal submits service requests to the Service Request Manager.
- The Service Request Manager provides information about a user’s service requests to the Service Request Portal.
Rationale:
Separate user interaction (the presentation and capture of service requests) from the management of life-cycle of individual service requests.
Service Request Catalogue
Responsibilities:
- Manage information about types of services that are available to be requested. This includes what type of service request it is, and associated information such as the cost and typical SLA.
- Manage the life-cycle of that type of service request (e.g. evaluation, available, grand-fathered, retired).
- Manage who is entitled to request which services (e.g. by role).
Collaborators:
- Service Request Catalogue provides information about services that are available via the Service Request Portal.
- Service Request Catalogue provides information about types of service requests to the Service Request Manager.
- Service Request Catalogue provides information about types of services that is common to all assets to the Asset Manager.
- The Asset Manager provides information about the number of instances of types of services that are deployed (for instance where assets are consumable, such as limited pieces of hardware).
Rationale:
Separates out information about types of service requests from: information about deployed instances of the results of service requests (e.g. individual instances of applications or pieces of hardware); and, the management of individual service requests.
Service Request Manager
Responsibilities:
- Assigns service requests to users (for approval or action).
- Manages the life-cycle of each individual service request based on a definition for that type of service request.
- Escalates un-actioned service requests.
- Creates assets once service requests are completed.
Collaborators:
- The Service Request Portal submits service requests to the Service Request Manager.
- The Service Request Manager provides information about a user’s service requests to the Service Request Portal.
- Service Request Catalogue provides information about types of service requests to the Service Request Manager.
- The Service Request Manager creates assets in the Asset Manager as the result of the completion of a service request.
Rationale:
Separates the management of a service request from: its initiation and presentation to a user; the definition of types of service requests (and their life-cycles); and the management of individual assets.
Asset Manager
Responsibilities:
- Maintains a list of assets.
- Manages information about those assets (such as location, who they are assigned to, costs).
- Manages the life-cycle of each asset.
Collaborators:
- The Service Request Manager creates assets in the Asset Manager as the result of the completion of a service request.
- The Asset Manager provides information about the number of instances of types of services that are deployed (for instance where assets are consumable, such as limited pieces of hardware) to the Service Request Catalogue.
Rationale:
Separates the management of information about individual assigned assets from the definition of common features of service requests and from the management of the work-flow of individual service requests.
Doug Newdick's Blog 