Download Enterprise Architecture Artifact Framework (DRAFT)

Enterprise Architecture Artifact Framework (DRAFT)
In support of the autonomous nature of IT at UC – The Enterprise Architecture (EA) team and
Information Technology Architecture Group (ITAG) are establishing an Enterprise Architecture Artifact
Framework (EAAF) to support the development and management of Enterprise Architecture Artifacts
(EAAs).
An Enterprise Architecture Artifact (EAA) can be thought of as any artifact that is produced by UC
personnel to further harmonization, interoperability and information exchange across UC. EAAs will
encompass a wide spectrum of artifacts e.g. Standards, Specifications, Principles, Reference
Architectures, etc.
EAAs are to be managed by the Enterprise Architecture team. EAAs may be created, and subsequently
submitted for consideration by anyone in UC (although the submitter should have familiarity with the
Architecture discipline). The Enterprise Architecture team and the Information Technology Architecture
Group (ITAG) will consider qualified submissions for inclusion in a repository of EAAs, monitor for
duplication, promote the establishment and utilization of EAAs, etc. The repository for EAAs has not
been identified as of yet.
An individual EAA may be as simple as a Principle statement, or be a collection of many components
(e.g. reference architecture). To support the cataloging, discovery and management of EAAs of dissimilar
structure and size, a metadata EAA document format will be established and will be mandatory for each
EAA submission.
The following outlines the main metadata sections (structure) of the metadata EAA document (this will
serve as a fulcrum point to support various other supporting artifacts).
Title –
Short name and/or description of the EAA
Type –
Types of EAA (defined in further detail later)
 Standard –
 Guidance/Guideline/Best Practice –
 Anti-Pattern –
 Specification –
 Process/Procedure –
 Security Control? –
 Principle –
 Reference Architecture –
 Framework –
Body –
Describes in sufficient detail the intent of the EAA. The structure of the body section
may vary by subject, EAA Type and a number of other factors.
Recommend keeping this section as succinct as possible and leverage the links sections
(below) to support verbose content.
Scope designation –
This section specifies the scope of the EAA thereby enabling consumers of the EAA to
determine the applicability of the EAA to their particular situation (also factoring in the
EAA Type).



Baseline (De-facto) –
Location Specific Adoption –
Systemwide –
Submitted by –
Identifies the person, Location affiliation, and contact information of the person that
originally submitted the EAA.
Links to related EAAs –
Identifies other EAAs that are related to this one e.g. EAA of type Anti-pattern may have
a link to an EAA of type Standard that recommends suitable alternatives.
Links to supporting/reference information –
Identifies links to (possibly) verbose reference information.
Status (of this EAA) Possible status values:
 Submitted – initiation status
 InProgress – the EAA is worked/refined
 UnderConsideration – the EAA is being considered by members of ITAG
 Published – the EAA has been published to a repository where it may be discovered
 Established – the EAA has been published and has one or more scope designations
 Revaluate – the EAA is/has/will been revaluated
 Deprecated – the EAA is no longer supported, applicable or used
 Rejected – for a number of possible reasons, the EAA submission was rejected
(Dates to be associated with each Status change)
Enterprise Architecture Artifact Scope Designations
Each EAA will have a scope designation section. This designation is a fundamental enabler to allow all
Locations to contribute (i.e. independently develop and submit EAAs), and other Locations to adopt (or
not) those EAAs at their own pace. Minimally, it enables us to assemble a body of knowledge for
consumption across UC.
Scope Designations:
Baseline –
This designation is established for EAAs pertaining to already established Common
Administrative Services, standards and best practices (e.g. Federated Authentication, UCPath
s/FTP, UCPath webServices, etc.). A Common Administrative Services is a service that can be
consumed by any UC Location, regardless of the underlying hosting arrangements. Once
established, Common Administrative Services are Baseline.
Systemwide –
An EAA is considered have a Systemwide scope designation when 8? (or more) Locations have
adopted the EAA (and are listed in the Location Adoption section).
Location Specific Adoption –
This scope designation indicates if the EAA has been adopted by at least one Location (i.e. being
listed in this section). Any UC Location that chooses to adopt an individual EAA, is agreeing to
implement and enforce that EAA locally. The process for adopting an EAA is described later
<link>.
Example Location Adoption:
Location
Effective Date
UCOP
1/1/2012
UCSC
12/21/2013
UCR
3/7/2011
ITLC Signoff
Paul Weiss
Mary Doyle
Chuck Rowley
Outcome
Not
Adopted
Adopted
The scope designations are used to inform practitioners at any Location about the
applicability/jurisdiction of an EAA on a particular decision/matter under consideration.
An individual EAA may have multiple scope designations simultaneously, or a single scope.
Scenario 1: A UCOP project wants to manipulate data using database stored procedures.
The project team evaluates the project using the established body of EAAs.
Assume there is an EAA (type: Anti-pattern) in place called “Prohibit use of Database Stored
Procedures“and a scope designation of “UCOP” (only). This EAA would inform the project team
that the use of database stored procedures is contrary to desires of UCOP. The project could
explore alternatives (e.g. via links to related EAAs) or could pursue an escalation/exemption
process. Exemption processes will vary from Location to Location but ultimately must involve
the ITLC representative for that Location (signoff allowing the exemption).
Scenario 2: A project at a Location other than UCOP wants to manipulate data using database stored
procedures.
The project team evaluates the project using the established body of EAAs.
Reviewing the content of established EAAs would again identify an EAA prohibiting the use of
database stored procedures. However, inspecting the Scope Designations (Baseline, Systemwide
& Location Specific Adoption) would inform them that this particular Location has not adopted
this specific EAA. So the project at this Location would not run afoul of this particular EAA and
could proceed along that route if desired. Notionally, they would have benefited from the
content of the EAA describing the perils of using stored procedures and may reconsider.
Enterprise Architecture Artifact Types
There are many types of Enterprise Architecture Artifacts.
EAA Types:
Principle –
Statement of position/philosophy intended to guide thinking/approach when specific standards
are not available. Usually, considered to be best practice irrespective of specific project
requirements.
Standard –
Governs/dictates an outcome. Prescribes required a use/approach.
Guidance/Guideline/Best Practices –
Recommendations and/or sound advice on subjects.
Anti-Pattern –
Typically the opposite to standards and principles, describes the
patterns/behaviors/technologies that are contrary to desired outcomes. May can be a direct
way to influence outcomes.
Specification –
Detailed instructions, steps, configuration (e.g. Specific web server hardening specifications).
Process/Procedure –
Prescriptive series of steps/tasks that collectively depict a process in sufficient detail to be
emulated and achieve consistency (auditing process for ETL job).
Security Control –
Defines Security Controls for various topics.
Enterprise Architecture Artifact Lifecycle stages
Process for Location Specific Adoption of an EAA
The ITAG representative for each Location is responsible for executing the Local Adoption Process at
their Location. This person will identify and consult with the resources at their disposal (stakeholders,
Subject Matter Experts, etc.).
If the EAA is viable for adoption by that Location, the ITAG representative will seek formal approval from
their ITLC representative. If approved/adopted by the ITLC representative, the ITAG representative will
send an e-mail to the Enterprise Architecture team citing the Location, ITAG signoff name, effective
date, etc. for the EAA that has been adopted by that Location.
<is verification needed? e.g. forward the approval e-mail>
Enterprise Architecture, on receiving the notification will update the EAA, and initiate communication to
<define audience>.
Enterprise Architecture Artifacts Hierarchy