|
|
| Line 1: |
Line 1: |
| − | Catalogs are lists of objects/items that are intended for reuse. One should always use an existing object from a catalog when it exists.
| + | {{Delete|reason=Expired content.}} |
| − | | |
| − | === How to use Catalogues in QualiWare ===
| |
| − | A “Catalogue” within the SSC EA Repository is a diagram which contains a master list of objects (e.g. Business Capability, Actor, Service, EA Principle). The purpose of the diagram is to define the reusable catalogue (list) of objects used in other diagrams/models and to define their levels of abstraction for this particular area of the SSC architecture model.
| |
| − | | |
| − | This is important so that an object which should appear once (e.g. Any specific business capability) does not appear dozens of times in the repository. One of the most significant advantages of modeling tools over drawing tools in the ability to reuse objects universally which has the following benefits:
| |
| − | * All detailed information about an object is entered and maintained in one place. This saves on data entry effort and gives us one source of truth.
| |
| − | * The repository can support queries related to the objects. For example, if management would like to know how Business Capability X is realized across SSC, we can do this easily IF the object from the catalog has been used everywhere.
| |
| − | * Collisions are resolved earlier. If different teams have different “lists”, the use of catalogues usually forces the alignment of these as they get entered in to a catalog.
| |
| − | Catalogs, generally, are under the management of the ACOE and kept in the Governed Repository in “CatalogueDiagram:SSC”.
| |
| − | | |
| − | Each Catalog will have a specific owner whom will have the governance accountability. In most cases, this will be the relevant Segment Lead but for general catalogues the owner will be the ACOE lead. Refer to the Catalogue diagram to see the “Owner”.
| |
| − | | |
| − | ==== '''Catalogue Status''' ====
| |
| − | Catalogues follow the same lifecycle as all diagrams/models in the governed repository, that is, Development, Finished, Circulation, Ready for Approval, Approved and Retired. While in “Development” the owner can decide who has write access and who can only read. “the owner can decide who has write access and who can only read”. Technically anyone will be able to write in a diagram that is in the WIP but normal etiquette would be for anyone to check with the owner before updating it.
| |
| − | | |
| − | ==== '''New Catalogue or Catalogue Entry Requests''' ====
| |
| − | Catalogues should be used where there is a risk of many of the same object being created in the repository. A new catalog can be suggested by anyone asking the Segment lead first and then the segment lead will request it from the ACOE using GCCODE.
| |
| − | | |
| − | DO NOT STOP modeling if you feel a catalog or catalog entry is needed but does not exist. Simply create the object you need from the standard template, send a request to the ACOE or catalogue owner and wait for the object to be created. Once the object exists, you can “Replace” your stand-alone object with the proper catalogue object.
| |
| − | | |
| − | ==== '''When to Use a Catalogue''' ====
| |
| − | When developing a new diagram in the governed repository, modellers are must follow the guidance for the specific diagram. That Guidance will explain which objects must be selected from which catalogues. If there is no indication that an object is tied to a catalogue then modellers are free to choose from the standard QW template.
| |
| − | | |
| − | ==== '''“Catalogue” object indication''' ====
| |
| − | Currently, all approved Catalog objects have (*) in the title. This is a temporary measure and will be replaced in the future. Guidance will be provided at a later time on how to verify the entire content of a diagram and will include the way to see which objects are being used which did not come from a catalogue.
| |
| − | | |
| − | === Catalogue List ===
| |
| − | {| class="wikitable" | |
| − | |-
| |
| − | !Catalog
| |
| − | !Status
| |
| − | !Element
| |
| − | ! Description
| |
| − | ! Location
| |
| − | |-
| |
| − | |Segment
| |
| − | |Existing
| |
| − | |Business Function type=segment
| |
| − | |SSC architecture segments
| |
| − | |CatalogueDiagram:SSC
| |
| − | |-
| |
| − | |Business Capability
| |
| − | |Existing
| |
| − | |Capability
| |
| − | |A list of business capabilities - which are to be realized/supported by various architectures.
| |
| − | |CatalogueDiagram:SSC
| |
| − | |-
| |
| − | |SSC Service
| |
| − | |Existing
| |
| − | |Business Function type=SSC Service|| SSC Services - as described in the official SSC Service Inventory. Represented in QualiWare as functions with a special attribute.
| |
| − | |CatalogueDiagram:SSC
| |
| − | |-
| |
| − | |Foundation Technology Services
| |
| − | |Existing
| |
| − | |Technology Service
| |
| − | |List of level 1 and 2 technologies as determined by convention by EA
| |
| − | |CatalogueDiagram:SSC
| |
| − | |-
| |
| − | |Actors
| |
| − | |Started
| |
| − | |Business Actor
| |
| − | |List of official actors - named persons or groups
| |
| − | |CatalogueDiagram:SSC
| |
| − | |-
| |
| − | |Operating Systems
| |
| − | |Existing
| |
| − | |System Software
| |
| − | |List of Operating System with types (specializations)
| |
| − | |CatalogueDiagram:SSC
| |
| − | |-
| |
| − | |Projects
| |
| − | |Proposed
| |
| − | |Work Package
| |
| − | |List of SSC Projects and initiatives. Work package = project or initiative.
| |
| − | |
| |
| − | |-
| |
| − | |Gaps
| |
| − | |Proposed
| |
| − | |Gap
| |
| − | |List of identified strategic architectural gaps - intended to be filled by projects
| |
| − | |
| |
| − | |-
| |
| − | |Goals/Outcomes
| |
| − | |Proposed
| |
| − | |Goal/Outcome
| |
| − | |List of identified strategic goals and outcomes - every project must connect to at least one.
| |
| − | |
| |
| − | |-
| |
| − | |SSC Architecture Principles
| |
| − | |Proposed
| |
| − | |Principle
| |
| − | |List of architecture principles - used in EA assessments, and as requirements for every SSC project/initiative.
| |
| − | |
| |
| − | |-
| |
| − | |Standards
| |
| − | |Proposed
| |
| − | |Sub-type of Principle
| |
| − | |List of SSC IT Standards. A subset/subtype of principles.
| |
| − | |
| |
| − | |-
| |
| − | |Driver
| |
| − | |Proposed
| |
| − | |Driver
| |
| − | |List of SSC Drivers, which may include legislation, policy, directives, strategies, standards, IT standards, and any other motivations for the organization.
| |
| − | |
| |
| − | |-
| |
| − | |Roles
| |
| − | |Proposed
| |
| − | |Role
| |
| − | |Standardized list of roles and types of roles in the enterprise.
| |
| − | |
| |
| − | |-
| |
| − | |Databases
| |
| − | |Started
| |
| − | |System Software
| |
| − | |List of databases, database software and types.
| |
| − | |CatalogueDiagram:SSC
| |
| − | |-
| |
| − | |Storage
| |
| − | |Started
| |
| − | |TBD
| |
| − | |List of storage, storage types.
| |
| − | |CatalogueDiagram:SSC
| |
| − | |}
| |
