Sd Esa Reference Model

8/13/2019 Sd Esa Reference Model

1/66

Reference Model for BCSCertificates in Enterpriseand Solution Architecture

Version 4.0

June 2012


2/66

Copyright BCS 2012Enterprise and Solution Architecture Reference ModelVersion 4.0 June 2012

Page 1 of 65

Reference Model for BCS Certificates in Enterprise andSolution Architecture

This reference model follows the structure of the syllabus for BCS examinations in enterprise andsolution architecture. It defines terms used in the syllabus. It is designed to help:

Examiners to scope and phrase examination questions. Examinees to understand terms and concepts in examination questions. Training Providers to scope training courses that lead to the examinations.

Acknowledgements

BCS gratefully acknowledges that about half this reference model (at version 1) was based on thereference model published in 2008 by Avancier Ltd as an aid to architect training athttp://avancier.co.uk . The two models are aligned at the time this model is published.

Many other public domain sources (such as the Object Management Group, Open Group and ITIL)have been used. Definitions which have been taken from another source are included in quotationmarks. Definitions which have been tailored to ensure consistency between terms within thisreference model are not attributed to any particular source.

Trademarks Mentioned in Definitions

CMM and CMMI (Capability Maturity Model Integration) are registered trademarks of theSoftware Engineering Institute (SEI).

COBIT is a registered trademark of the Information Systems Audit and Control Association andthe IT Governance Institute.

CORBA, MDA, Model Driven Architecture, OMG, and UML are registered trademarks andBPMN, Business Process Modeling Notation, and Unified Modeling Language aretrademarks of the Object Management Group.

IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc.

ITIL is a Registered Trade Mark of the Office of Government Commerce in the United Kingdomand other countries. IT Infrastructure Library is a Registered Trade Mark of the Office ofGovernment Commerce in the United Kingdom and other countries.

Java is a registered trademark of Sun Microsystems, Inc.

Microsoft is a registered trademark of Microsoft Corporation.

PRINCE is a registered trademark and PRINCE2 is a trademark of the Office of GovernmentCommerce in the United Kingdom and other countries.

TOGAF and Boundaryless Information Flow are registered trademarks of The Open Group


3/66


Page 2 of 65

Contents

1. Architecture and Architects......................................................................................4 1.1 Foundation Terms and Concepts ..................................................................4 1.2 Intermediate Terms and Concepts................................................................7

1.2.1 Architecture Granularity ...................................................................7 1.2.2 Architecture Domains ......................................................................7 1.2.3 Hierarchical or Layered Architecture................................................9 1.2.4 Architect Roles, Goals and Skills.....................................................9

1.3 Practitioner Terms and Concepts................................................................11 2. Architecture Precursors (Requirements & Context) ...............................................12

2.1 Foundation Terms and Concepts................................................................12 2.1.1 Stakeholders..................................................................................12 2.1.2 Elaboration of Inputs to become Deliverables ...............................12

2.2 Intermediate Terms and Concepts..............................................................13 2.2.1 Drivers, Aims and Directives..........................................................13 2.2.2 Solution Descriptions and Plans ....................................................14 2.2.3 Standards ...................................................................................... 15 2.2.4 Scope of Architecture Work ...........................................................15 2.2.5 Requirements ................................................................................ 16 2.2.6 Regulatory Requirements .............................................................. 17 2.2.7 Business Case [See Migration Planning for definitions].................18

3. Architecture Frameworks ....................................................................................... 19 3.1 Foundation Terms and Concepts................................................................19 3.2 Intermediate Terms and Concepts..............................................................19

3.2.1 Architecture Process Frameworks.................................................19 3.2.2 Architecture Descriptions...............................................................20 3.2.3 Architecture Models and Languages .............................................22 3.2.4 Architecture Description Structures ...............................................23

4. Business Architecture .................... ........................................................................25 4.1 Foundation Terms and Concepts................................................................25 4.2 Intermediate Terms and Concepts..............................................................25

4.2.1 Business Architecture Structure and Behaviour ............................25 4.2.2 Business Process Decomposition and Automation........................28 4.2.3 Design for Business Security.........................................................28

5. Data Architecture ...................................................................................................29 5.1 Foundation Terms and Concepts................................................................29 5.2 Intermediate Terms and Concepts..............................................................30

5.2.1 Unstructured data management ....................................................30 5.2.2 Data Architecture...........................................................................30

5.2.3

Data Qualities and Integration .......................................................32

5.2.4 Design for Data Security................................................................32 6. Software Architecture .................... ........................................................................34

6.1 Foundation Terms and Concepts................................................................34 6.2 Intermediate Terms and Concepts..............................................................36

6.2.1 Component Interfaces ...................................................................36 6.2.2 Component Structures and Patterns..............................................37 6.2.3 Component Interoperation Styles ..................................................38


4/66


Page 3 of 65

6.2.4 Component Communication Styles................................................39 7. Applications Architecture ....................................................................................... 42

7.1 Foundation Terms and Concepts................................................................42 7.2 Intermediate Terms and Concepts..............................................................43

7.2.1 Applications Architecture Structure................................................43 7.2.2 Applications Architecture Behaviour ..............................................43 7.2.3 Applications Integration .................................................................44

7.2.4 Design for Applications Security ....................................................45 8. Design for NFRS....................................................................................................46 8.1 Foundation Terms and Concepts................................................................46 8.2 Intermediate Terms and Concepts..............................................................46

9. Infrastructure Architecture......................................................................................48 9.1 Foundation Terms and Concepts................................................................48

9.1.1 Basic Infrastructure Components...................................................48 9.1.2 Network scopes .............................................................................48 9.1.3 Network topologies ........................................................................49 9.1.4 Network layers...............................................................................49 9.1.5 Network protocols..........................................................................50 9.1.6 The internet ...................................................................................51

9.2 Intermediate Terms and Concepts..............................................................51 9.2.1 Infrastructure services and components ........................................ 51 9.2.2 Enterprise technology rationalisation .............................................52 9.2.3 Solution technology definition ........................................................53 9.2.4 Connecting Applications to Networks ............................................ 53 9.2.5 Design for Infrastructure Security ..................................................54

10. Migration Planning .................................................................................................55 10.1 Foundation and Intermediate Terms and Concepts ....................................55 10.2 Practitioner Terms and Concepts................................................................56

11. Architecture Management......................................................................................57 11.1 Foundation and Intermediate Terms and Concepts ....................................57 11.2 Practitioner Terms and Concepts................................................................57

11.2.1 Architecture Implementation ..........................................................57 11.2.2 Architecture Change Management ................................................58 11.2.3 Architecture Governance ............................................................... 59 11.2.4 Architecture in Operations ............................................................. 60

12. Enterprise Technology Classification.....................................................................62


5/66


Page 4 of 65

1. Architecture and Architects

This section is about work and roles to describe the high-level design of business systems and theinformation systems that support them (not work and roles related to buildings).

1.1 Foundation Terms and ConceptsThis reference model defines terms used in specifying the structure and behaviour of activitysystems. Four essential architecture concepts can be classified as shown in this table.

Behaviour Structure

External Service Interface

Internal Process Component

This reference model is based the notion that these four concepts can be applied in each of threearchitecture domains, shown here as a layered architecture domain hierarchy.

Business Services ServicesBusinessBusiness Functions Components

Information System Services ServicesInformation Systems

Applications Components

Platform Services ServicesTechnology Infrastructure

Technologies Components

The remainder of this reference model defines terms used in architecture. The definitions are

generalisations that draw from several sources.

Architecture 1: documentation describing the structure (components) andbehaviour (processes) of a system. A detailed plan of thesystem to guide its implementation.Or 2: the process for describing the architecture of a systemto meet given requirements and under given constraints.

Structure What a system is made of. A configuration of items. Acollection of inter-related components or services.Possible structures include hierarchies (items arranged in acascade of one-to-many relationships) and networks (itemsconnected by many-to-many relationships).

System A structure of interacting subsystems or components thatperform activities.An encapsulated collection of processes that transform inputsinto outputs (Output being the purpose of a man-madesystem).

Software system A system in which computer programs execute theprocesses.


6/66


Page 5 of 65

Human activity system A system in which people execute some or all of processes.A rich system, much more complex and loosely-defined thana software system. It relies to a greater or lesser degree onhuman personalities, skills, ingenuity and judgements aboutwhat to do and how to do it.

Component A subsystem that is encapsulated behind an interface - can

be replaced by any other with the same interface - is relatedto other subsystems by requesting or delivering services.A component can have several interfaces.

Building block A synonym in some architecture frameworks for a componentand/or an architectural entity. To avoid this ambiguity, thisreference model eschews the term.

Function 1: A component that offers several services.Or 2: A process that delivers a single service.Or 3: A purpose or goal of a component or process.To avoid this ambiguity, this reference model eschews theterm, except within business function.

Interface The means of connecting to a system, process or component.1: A list of services, offered by one or more components.

Or 2: The signature (name, inputs and outputs) of oneservice.Or 3: A data f low between sender and receiver componentsOr 4: The protocols used to exchange data betweencomponents.Or 5: The channel via which data flows are passedThis reference model favours definition 1.

Location A place where business is done, or where computers,applications or their users are. An identifiable point in spaceor geography. An architectural entity that appears in artefactssuch as technology deployment diagrams.

Time Period A slot in a schedule. An architectural entity that appears inartefacts such as application availability tables.

Behaviour What a system does. What external entities observe a systemas doing. The processes executed or supported by a system.

Service 1: The outcome of a process that is executed in response to arequest from a client.Or 2: An interface of a component (such as a web service)that may offer many services of kind 1.This reference model favours definition 1, to limit confusionbetween components and services.

Service contract The signature, semantics and non-functional characteristicsof a service.The signature is what a client needs to invoke a service -composed of a name, inputs (arguments) and outputs.The semantics are what a client designer needs to know ofwhat the service does - composed of its preconditions andpost conditions.The non-functional characteristics are what a client designerneeds to know of the conditions under which the serviceworks, which includes both performance and commercialconditions.


7/66


Page 6 of 65

Process 1: A procedure, started by an event, which terminates withthe delivery of an output or service. A set of steps oractivities arranged under a control flow in one or moresequential paths.Or 2: An encapsulated system or subsystem - as in theactive process on a computer.

This reference model favours definition 1.Life cycle A process from birth to death. E.g. the life of: a system from conception through deployment and use to

removal a project from conception through development to

delivery an entity [See Data Lifecycle.]

Abstraction 1: A process of composition, generalisation or idealisation bywhich shorter and more general descriptions are producedfrom longer, more detailed and more specific descriptions.Or 2: A simplified description of a system that is made by theprocess at definition 1.Abstraction is tool that every architect must be able to use.

Enterprise architects work with the highest abstractions.Composition 1: the assembly of parts into a whole;

Or 2: the organisation of units under a manager or owner;Or 3: the encapsulation of content inside a shell.The result is some kind of aggregate or compositecomponent or process. A composite contains its componentsin some sense. A description made with reference to awhole, manager or shell is more abstract than one that refersto its parts, units or content.Enterprise architects tend to work with coarse-grainedcomponents.

Decomposition The opposite of composition. Division of one composite oraggregate component or process into several components orprocesses. The conventional advice is that it is difficult tomaintain the integrity of a hierarchical structure that isdecomposed more the three or four levels (or more than athousand elements) from the top.

Generalisation Abstraction from several specific components or processesinto a more generic component or process. A generalisationcontains only the common features of its specialisations.Enterprise architects look to re-use generic components andservices.

Specialisation The opposite of generalisation; the elaboration or division of ageneral component or process into one or more specificcomponents or processes. A specialisation contains itsgeneralisation in some sense.

Idealisation 1: A kind of generalisation that produces a logical descriptionof a physical component or process. Reverse engineering toproduce a description that can be presented as therequirement for the real thing.Or 2: The separation of an interface from the component(s)that realise the interface.Enterprise architects define logical components and services.


8/66


Page 7 of 65

Realisation The opposite of idealisation; leads to the instantiation ofphysical materials. It can be viewed as forward engineering,as a progression from requirement to solution.

1.2 Intermediate Terms and Concepts

1.2.1 Architecture Granularity

Architecture granularity A scale which ranges from coarse-grained or high level tofine-grained or detailed. Generally speaking, the narrowerthe scope of the system, the finer-grained the description thatcan be written in a given time.This reference model distinguishes three levels ofarchitecture granularity.

Enterprise architecture A strategic approach to architecture that addresses a wholeenterprise. The highest level, widest scope, longest term kindof architecture.1: documentation describing the structure and behaviour ofan enterprise and its information systems.

Or 2: a process for describing an enterprise and itsinformation systems and planning changes to improve theintegrity and flexibility of the enterprise.

Solution(s) architecture A relatively tactical approach to architecture that addressesspecific problems and requirements, related to selectedinformation systems and business processes.1: documentation describing the structure and behaviour of asolution to a problem.Or 2: a process for describing a solution and the work todeliver it.

Software architecture A kind of architecture that addresses the scope andinteraction of software components within an application.1: Documentation describing the internal structure andbehaviour of a software application.Or 2: Principles and patterns for software modularisation, fordescribing and building the internal structure of anapplication.

1.2.2 Architecture Domains

Architecture domain A broad area architectural interest such as business, data,applications, and technology infrastructure. A facet or view ofan architecture description. A description that hides otherfacets or views of the system described. A partialrepresentation of a whole system that addresses severalconcerns of several stakeholders.


9/66


Page 8 of 65

Primary Domains

Business architecture The structure and behaviour of a business system (notnecessarily related to computers). Covers business functionsor capabilities, business processes and the roles of the actorsinvolved. Business functions and business processes aremapped to the business goals and business services they

support, and the applications and data they need.Data architecture The subset of information architecture that is focused on thedefinition, storage and movement of structured data.The data structures used by a business and/or itsapplications. Includes meta data: that is, descriptions of datain storage, data in motion, data structures and data items.Includes mappings of data objects to data qualities,applications, technologies etc.

Applications architecture The structure and behaviour of applications used in abusiness, focused on how they interact with each other andwith business users or actors. Focused on the dataconsumed and produced by applications rather than theirinternal structure.

The applications architecture is shaped by where data isobtained from and where it is used.The applications are usually mapped to the businessfunctions they support and the platform technologies theyneed.[See also application portfolio management.]

Infrastructure architecture The structure and behaviour of the technology platform thatunderpins user applications. Covers the client and servernodes of the hardware configuration, the platform applicationsthat run on them, the services they offer to applications, theprotocols and networks that connect applications and nodes.

Other Domains

Information architecture A broad domain that covers both structured and unstructureddata, that is, content, document and knowledge management.(This reference model focuses on structured data.)

Information systemsarchitecture

Often used to mean the combination of applicationsarchitecture and data architecture. It depends on but does notinclude the technology platform.

Software (aka application)architecture

The internal structure, the modularisation of software, withinan application. Discussed for example in Patterns ofenterprise application architecture by Martin Fowler.This is applications architecture at the lowest level ofgranularity - usually below the level of modularity thatenterprise and solution architects define. However, there isno rigid dividing line.

Security architecture The various design features designed to protect a systemfrom unauthorised access. Not a cohesive architecture on itsown so much as features of the other architecture domains business, data, applications and infrastructure asmentioned in other sections.


10/66


Page 9 of 65

1.2.3 Hierarchical or Layered Architecture

Hierarchical or layeredarchitecture

A structure in which components are organised into layers,such that components in one layer delegate work tocomponents in the layer below, but not the layer above.

Platform The layer that lies beneath and provides services to the layerunder consideration.

E.g. beneath the applications are application platformtechnologies including database management systems, andbeneath the operating system is the hardware platform.

The architecture domainhierarchy

Business, application and infrastructure architecture domainsviewed as a hierarchically layered structure. Thecomponents in one layer offer services to components in thelayer above.This is a useful mental model for enterprise and solutionarchitects alike. This reference model features several otherhierarchical decomposition structures.

1.2.4 Architect Roles, Goals and Skills

Architect One who designs buildings and superintends theirconstruction. One who describes the architecture of system insufficient detail for work to be planned and detailed designand building to proceed, then governs the building work.

Architect Role The list of roles below has been agreed by BCS as sufficientfor examination purposes.The focus of the following roles is evident from the definitionsof architecture levels:

Enterprise architect: defines principles, policies and plansthat cover several solutions to several businessproblems.

Solution architect: describes the structure of solution to abusiness problem, which may include severalapplications and technologies.

Software architect: describes how a single application isbuilt from software modules, at a fine-grained level.

The focus of the following roles is evident from thedefinitions of architecture domains:

Business architects: focus on business architecture; theirprincipal concerns are the functions and processes of thebusiness.

Data architects: focus on data architecture; their principalconcern is to ensure data quality in data stores and dataflows, through the definition and maintenance of metadata.

Applications architects: focus on applicationsarchitecture; their principal concern is the modularity ofapplications and data that flows between them.

Technical/infrastructure architects: focus ontechnical/infrastructure architecture.


11/66


Page 10 of 65

Enterprise architect goals The list of goals below has been agreed by BCS as sufficientfor examination purposes.

Improved alignment of business and IT Improved IT cost-effectiveness Business agility Technical agility

Long term planning: enablement of strategicallybeneficial IS/IT work. Vendor and technology independence (portability) De-duplication of applications and technologies Interoperability of applications and technologies Simpler systems and systems management. Improved procurement.

Solution architect goals The list of goals below has been agreed by BCS as sufficientfor examination purposes. The solution architect supports thegoals of an enterprise architect, but focuses more on thefollowing:

Timeliness of IS/IT project deliverables Cost of IS/IT project deliverables

Quality of IS/IT project deliverables Solution-level risk identification and mitigation Application integration and data integrity Conformance of solution to non-functional and audit

requirements Conformance of solution to principles, standards,

legislation. Effective interaction between managers and technicians. Governance of detailed design to architecture principles

and standards.Architect knowledge andskills

The list below has been agreed by BCS as sufficient forexamination purposes.

Holistic understanding of business and technical goals. Holistic understanding of business and technical

environment Broad technical knowledge including current trends. Broad methodology knowledge Analysis of requirements and problems Innovation. Leadership. Stakeholder management. Communication, political and soft skills. Awareness of project management and commercial risks

and issues.


12/66


Page 11 of 65

1.3 Practitioner Terms and Concepts

The table below suggests analogies between business systems and software systems. Practitionerarchitects should understand such analogies, and their limits.

Business (human activity) systems Software (computer activity) systems

An enterprise offers services (businessservices) to its customers. An application offers services (use cases) toits users.An enterprise is divided into componentdivisions, which are further subdivided.

An application is divided into components,which are further subdivided.

Enterprise divisions offer business services toeach other.

Application components offer automatedservices to each other.

Some divisions (e.g. Accounting,Procurement, HR) offer common services tomany other business functions.

Some components (e.g., Address retrieval,Currency conversion, Date, Payment) offercommon services to many other applications.


13/66


Page 12 of 65

2. Architecture Precursors (Requirements & Context)

This section is about the various inputs, the requirements and constraints that guide an architect asto the nature and shape of the solution to be built. This information is needed to support astatement of architecture work. Note that management activities are addressed in sections 10 and

11.2.1 Foundation Terms and Concepts

2.1.1 Stakeholders

Stakeholder Person or role with power over and/or interest in work to bedone or its deliverables. A person who has one or moreconcerns about the system to be built (because they own it,manage it, use it or other reason).

Stakeholder management A technique based on analysis of stakeholders positions in apower/interest grid, which determines a communication planfor each stakeholder.

Sponsor A stakeholder who is willing to apportion money or otherresources to some work.

Concern A general kind of requirement (e.g. availability, usability) thatis important to one or more stakeholders in the system, anddetermines the acceptability of the system to thosestakeholders.A concern may be addressed in several view points. A viewpoint may address several concerns.

Architect stakeholder Enterprise and solution architecture stakeholders include: Owners: business and IT board members, customers. Managers: programme/project/change managers. Buyers: procurement/acquisition organisation. Suppliers: service and product providers. Designers, Builders, Testers: other project team

members: Users: representatives and domain experts. Operators and Maintainers: IT Services Management.

2.1.2 Elaboration of Inputs to become Deliverables

Elaboration of inputs tobecome deliverables

The inputs to architecture definition include high level aims,directives, visions and strategies. During architecturedefinition, these are decomposed and elaborated. So theoutputs include lower-level elaborations of the inputs.

This reference model tends to distinguish different levels ofdecomposition by using different words.


14/66


Page 13 of 65


2.2.1 Drivers, Aims and Directives

Driver A pressure (internal or external) that helps to shape aims andplans.E.g. customer feedback, increased competition, staff

retention.

Aim hierarchy A hierarchy of goals, objectives and requirements, applicableto an enterprise, system or project.

Goal (business or technical) An aim at the top of the aim hierarchy. It is often decomposedinto lower level objectives. Sometimes qualitative; sometimesquantified using SMART Key Goal Indicators.

Objective An aim in the middle of the aim hierarchy. It supports one ormore higher-level goals. It should have SMART KeyPerformance Indicators.

Requirement An aim at the bottom of the aim hierarchy.[See requirements statement for further definition.]

Balanced Score Card A management tool in which top-level objectives are spreadacross four categories, then cascaded down the organisationand decomposed at each level.

SMART The acronym for Specific, Measurable, Actionable, Realisticand Time-bound. The qualities of a good goal, objective orrequirement.

The directive hierarchy below reconciles TOGAF 9 with the OMG's Business Motivation Model byplacing Principles above Policies and Rules, and defines these terms so as to ensure consistencywith other terms in this reference model.

Directive hierarchy A hierarchy of principles, policies and business rules,applicable to an enterprise, system or project. Each is astatement that guides people along a path to reach an aim,and can be used as a tool of governance.

Principle A directive at the top of the directive hierarchy. A strategic,abstract and not-directly-actionable directive that derives fromhigh-level goals. A statement of an outcome that reflectsgoals. A tool used in governance of architecture work.Principles can be related to business, data, applications,infrastructure or security. E.g.

Waste should be minimised. Data security is paramount.

Policy A directive in middle of the directive hierarchy. A tacticaldirective that derives from objectives. A tool used ingovernance of day to day work. It guides behaviour that thecompany expects will lead to desired outcomes. e.g.Members of the public have minimal access to data.

USB ports are disabled. Message data at security level 3 is encrypted.

[The definition in the OMG Business Motivation Model A rulethat governs or guides the strategy is closer to Principleabove.]


15/66


Page 14 of 65

Business Rule A directive at the bottom of the directive hierarchy. It directsand constrains a procedure. It appears in specifications ofautomated data processing.A Term, Fact, Constraint or Derivation Rule used in definitionof data processing. e.g.

AccessLevel = Low if UserType = Public.[The definition in the OMG Business Motivation Model An

actionable rule derived from the policy is comparable.]

2.2.2 Solution Descriptions and Plans

Business mission What an organisation is about; its reasons for being; theessential products and services it offers customers.

Business vision A high-level outline of an aspirational target state for anenterprise. What an organisation wants to be or become.(Business Motivation Model.)The target state is supposed to meet the goals of one or morestakeholders. The state may be attainable and associatedwith specific objectives. The state may be unattainable, used

only as a guiding principle for planning.Mission statement A declaration of mission, vision, main goals and values.

Target solution hierarchy A solution defined at a vision level may be elaborated atincreasing levels of detail. Solutions may be mapped to aimsand directives.

Solution vision An outline description of a target system, just enough toenable options to be compared and /or work to proceed. Maybe a response to a business problem or an elaboration ofhow to reach a business vision.

Solution outline A high-level outline of a target system, produced after a firstpass architecture definition, enough to pass risk assurance.

Solution to be built A project-ready architecture, completed in sufficient detail for

the project to be scheduled and resourced, and the buildingteam to start work.Plan A document that defines the process to reach an aim. It

should include timescales, costs and resources for each step.There can be a plan for an organisation, a project, or person,at any level of detail.

Plan hierarchy Plans are often arranged in a hierarchy, increasing in numberand in detail from strategic to tactical.

Strategy A plan to channel efforts towards achieving a goal. BusinessMotivation Model.A relatively high-level and/or long-term plan to reach a newstate and so achieve some relatively high-level and/or long-term goals.

Programme plan A plan for a programme of projects.In the context of architecture, the plan via which theenterprise architecture is developed and implemented.

Project plan A plan for a project to develop and/or implement a solution.In the context of architecture, the plan via which a relativelyself-contained solution architecture is developed and/orimplemented.


16/66


Page 15 of 65

2.2.3 Standards

Standard A widely-accepted measure or set of qualities that is intendedto increase uniformity between distinct systems andprocesses.

Standards Body An enterprise with a mission to set standards and assesscompliance to them. E.g.

American National Standards Institute (ANSI). BCS The Chartered Institute for IT (BCS). Information Systems Examination Board (ISEB). Institute of Electrical and Electronic Engineers (IEEE). Information Systems Audit and Control Association

(ISACA) International Standards Organisation (ISO). Office of Government Commerce (OGC). Open Applications Group Standards (OAGIS). Organisation for Advancement of Structured Information

Standards (OASIS). The Object Management Group (OMG). The Open Group.

US National Institute of Standards and technology(NIST). Software Engineering Institute (SEI).

Enterprise StandardsInformation Base

A repository contains standards recommended or usedacross the enterprise. Cf. The Open Groups SIB.

Profile The standards (and perhaps options and parameters of thosestandards) necessary for a system, application or componentto do its job.

Profiling Selecting standards for a particular system, application orcomponent.

2.2.4 Scope of Architecture Work

Scope of architecture work The work needed to change a system may be dividedbetween small changes handled through changemanagement and big changes that require a substantialarchitecture effort.Architecture work has four dimensions of scope:

Breadth: scope of the enterprise, system or solution. Focus: business, application or infrastructure change. Depth: the detail to which deliverables will be produced. Constraints on work.

Constraint (on work) A factor that limits work to be done or potential solutionoptions, such as time, budget and resources.(Not a constraint in the sense of a data type or business rule.)

Breadth of enterprise orsystem

This dimension of scope may be defined in several ways. Aim view: goal/objective/requirement catalogue Service view: a service catalogue. System view: a top-level context diagram. Process view: a top-level process map or use case

diagram. Data view: a conceptual/domain/business data model.


17/66


Page 16 of 65

Context Diagram(interfaces to externalsystems)

Shows a system as a black box, the inputs consumed andthe outputs produced by that system, and the external entities(actors and/or roles) that send inputs and receive outputs.

External entity An actor or role that inputs to and/or consumes outputs froma system or process. Defining external entities as actorstends to make a model more understandable. Definingexternal entities as roles tends to make a model more stable

and flexible.Actor An identifiable individual external entity that plays one ormore roles in relation to a system or process. May be aperson, a human activity system or a software system.E.g. BACS, salesforce.com, a sales executive, a customer,an auditor.

Role A part played by one or more actors in relation to a system ora process. With software systems, the part is often to enteror consume data and so named after the input or output dataflow.E.g. loan applicant, expense claim approver, auditor.

2.2.5 Requirements

Requirement statement A statement of need with which compliance must bedemonstrated; this implies an acceptance test and anacceptance authority.Often expressed as an entry in a requirements catalogue or ause case description.Requirements attributes are likely to include: referencenumber, description, source, owner, type, priority, anddeadline. A requirement should be SMART, which implies thedefinition of acceptance tests.

Functional requirement A requirement related to data into or output from a system,and to processes and business rules for input and output.

Audit requirement A requirement to do with ensuring an auditor can find thewhen/where/how/who of a process or stored data, and canreplay events. (Considered by some to be a functionalrequirement and others to be non-functional.)

Non-functional requirement A requirement about the ability of a system to perform itsfunctions (whatever they are) effectively and efficiently.Usually quantitatively measurable.

Performance Subdivides into two measures, often in opposition: Throughput: number of services executed in a time

period. Response or cycle time (aka latency): time taken from

request to response.Availability The amount or percentage of time that the services of a

system are ready for use, excluding planned down time.Recoverability The ability of a system to be restored to live operations after a

failure.Reliability The mean time between failures. Usually applied to the

technologies in the Infrastructure, ignoring the more likely riskof application failure.


18/66


Page 17 of 65

Integrity [A term with several meanings defined under Data integrityand Data flow integrity.]

Scalability The ability of a system to grow to accommodate increasedwork loads.

Security The ability of a system to prevent unauthorised access to itscontents.

Serviceability The ability of operations team to monitor and manage asystem in operation.Usability The ability of actors to use a system.

Maintainability The ability of maintenance teams to revise or enhance asystem.

Portability The ability to move a component from one platform toanother, or convert it to run on another platform. In practice,it can be difficult to set or estimate this quality metricrealistically.

Interoperability The ability for subsystems to exchange data at the technicallevel using shared protocols and networks. Sometimesembraces data integratability.

Integratability The ability of interoperable subsystems to understand eachother, which requires either common data types or brokers totranslate between data types.

Extensibility A synonym of maintainability.

Service Level Agreement(SLA)

Written agreement between an IT service provider andcustomer (s) that documents agreed-to service levels. (ITIL)A document defining the requirements that services mustmeet, often focused on non-functional requirements.

Service Level Requirement(SLR)

Criteria for level of service required to meet businessobjectives. ITIL

2.2.6 Regulatory Requirements

Regulatory requirement A law or other regulation that adds to the requirements for orconstraints on any solution to be developed or maintained.

IT accountability andprocurement regulations

Regulation that makes public sector, IT directors and CIOsaccountable for justifying investment in IT and for fairprocurement from suppliers.US legislation of this kind was the stimulus for many earlyenterprise architecture initiatives:Government Performance Results act (GPRA) of 1993, P.L.103-162.Federal Acquisition Streamlining act (FASA) of 1994, P.L.103-355.

Information Technology Management Reform act (ITMRA) of1996, Division E, P.L. 104-106.Various EU directives have followed suit.

Data protection andfreedom regulations

UK's data protection act:http://www.opsi.gov.uk/ACTS/acts1998/19980029.htm Freedom of Information act 2000:http://www.opsi.gov.uk/ACTS/acts2000/20000036.htm


19/66


Page 18 of 65

Disability and accessibilityregulations

UK Disability Discrimination act:http://www.opsi.gov.uk/acts/acts1995/1995050.htm .W3C Web Content Accessibility Guidelines:http://www.w3.org/TR/WAI-WEBCONTENT/ US Americans with Disability act.

Shareholder protection andaudit regulations

US Sarbanes-Oxley act of 2002.Basel II.

Intellectual property rightsregulations International and national laws protect people and enterprisesfrom theft of intellectual property.

2.2.7 Business Case [See Migration Planning for definitions]

Business case (beforearchitecture)

Should be outlined at the start and updated as need be. It willbe reviewed and refined several times while architecture workis done. It may decompose into business cases for specificoptions, stages or projects within the overall solution.[See the Migration Planning section for further definitions ofthis the supporting terms below.

Return on Investment (ROI)

Cost-benefit analysis Solution options Risk analysis Gap analysis (options) Trade-off analysis.]

Business scenario A process, or story, to which are attached details of theactors, applications and technologies involved. A good wayto create and present an architecture description.May be defined to support a solution vision or business case.May be defined during business architecture definition. Maybe presented as an example instance of a business process.


20/66


Page 19 of 65

3. Architecture Frameworks

This section is about frameworks designed to help people create architecture descriptions and usethem to good effect.

3.1 Foundation Terms and Concepts

Architecture Framework A structured collection of guidance and techniques, amethodology, designed to help people create architecturedescriptions and use them to good effect.A comprehensive framework contains:

a development process (a process framework) a classification of architecture descriptions (a content or

documentation framework) advice on organisation.


3.2.1 Architecture Process Frameworks

Architecture processframework

A description of a process that develops a target architectureto meet some requirements, under some constraints, plansthe move from the baseline state to the target state, andgoverns that change.

Architecture state A baseline architecture describes a system in a state,perhaps operational, ready to be reviewed and/or revised.A target architecture describes a system in a state that is tobe created and implemented in the future.An intermediate or transitional architecture defines a state of

a system between baseline and target.The Open GroupArchitecture Framework(TOGAF)

A well-known framework for enterprise architecture, centredon a process called the architecture development method(ADM).

Architecture DevelopmentMethod (ADM)

The core of TOGAF. A step-by-step process to develop anduse an enterprise architecture. Designed more for enterprisearchitecture than solution architecture. Involves a cycle of 8phases.A. Architecture VisionB. Business ArchitectureC. Information System Architecture (Data and Applications)D. Technology ArchitectureE. Opportunities and Solutions

F. Migration PlanningG. Implementation GovernanceH. Architecture Change Management.


21/66


Page 20 of 65

Avancier Methodology(AM)

An architecture process framework designed more forsolution architecture than enterprise architecture. Theprocess is presented in 9 phases, though iteration andparallelism is expected.1. Define precursors2. Scope the work

3. Understand the baseline4. Review non-functional criteria5. Outline the target6. Select and manage suppliers7. Plan the migration8. Hand over9. Govern the migration.

3.2.2 Architecture Descriptions

Architecture descriptionhierarchy

In describing the structure and behaviour of an enterprise orsystem, it is common to build a three level architecture

description.Architecture deliverables contain artefacts, which are in turncomposed from architectural entities.Conversely: an entity can appear in several artefacts; anartefact can appear in several architecture deliverables.

Architecture deliverable A report that an architect is required to deliver. Deliverablesinclude management and project documents as well asarchitecture descriptions that contain architecture artefacts.Deliverable examples: Request for Work, Statement of Work,Architecture Requirements, Architecture Definition, RAIDCatalogue, Migration Plan.

Architecture artefact A list, hierarchy, table, diagram or model that names andrelates architectural entities. It describes the entities to someextent, though they are usually documented separately.Artefact types (aka view points) include:PRECURSORS: Goal or requirements hierarchy, Goal orrequirements traceability, Process map, Context diagram.BUSINESS: Business function structure, Business processmodel, Organisation structure, Location structure, Businessfunction dependency matrix, Business data model.DATA: Data model, Data lifecycle, Data structure, Businessfunction-Data CRUD matrix, Application-Data CRUD matrix,Data dissemination matrix.APPLICATIONS: Application portfolio, IS context diagram,Business-Applications matrix, Applications architecturediagram, Application decomposition diagram, Softwarelayering diagram.INFRASTRUCTURE: Technical Reference Model, StandardsInformation Base, Technical environments outline, Hardwareconfiguration diagram.

Architectural entity A discrete architectural element, an object in an architecturerepository that is reusable in different artefacts, and isdefinable using a standard template. An entity instance maybe decomposed into finer-grained instances of the same type.


22/66


Page 21 of 65

Most architectural entity types can be classified as belongingto an architecture domain. For example:PRECURSORS: Stakeholder, Business goal/objective,Principle, Standard.BUSINESS: Organisation unit, Business function, Businessprocess, Role, Actor, Business service, Location, Timeperiod.DATA: Data entity, Data event, Data flow, Data quality, Datasource, Data store.APPLICATIONS: Application, Data flow, Use case,Automated service, Component.INFRASTRUCTURE: Technology, Computer, Network

Mapping An artefact, view or model that relates items in differentstructures, made for the purposes of

gap analysis, impact analysis, requirements traceability or cluster/affinity analysis.

Artefacts that take the form of mappings betweenarchitectural entities include:

organisation unit to business function, business function to application, application to platform technology. data entity to business function, data entity to data store, data entity to data quality.

ISO/IEC 42010 Recommended Practice for Architecture Description ofSoftware-Intensive Systems.A standard for software architecture or system architecture. Itfocuses on the description of an architecture as the concreteartefact representing the abstraction that is softwarearchitecture or system architecture.Commonly known by its original identity ANSI 1471.

View The term used in ISO/IEC 42010 for an instance of a broadarchitecture domain description or narrower architectureartefact.a representation of a whole system from the perspective of arelated set of concerns, to demonstrate to one or morestakeholders that their concerns are addressed in the designof the system.Views are decomposable. Views can share content. Viewscan contain parts of other views.An instance of a view point. A description that hides irrelevantdetails or facets of the system described.E.g. A logical data model shows the scope and structure ofdata stored by an application, but shows nothing of processes

or technologies.


23/66


Page 22 of 65

View point The term used in ISO/IEC 42010 for a type of architecturedomain or narrower architecture artefact.what views of the same kind look like a schema ortemplate describing the purpose and intended audience ofthe viewDefines a views scope (the concerns addressed) and style

(documentation conventions). Should be stored for reuse byarchitects in the same organisation.E.g. Logical data models drawn using the IDEF1X standardcan address concerns shared by systems analysts anddatabase designers.

3.2.3 Architecture Models and Languages

Model A description that hides some details of the things described.Often, an architecture artefact or view that is drawn in theform of a diagram. A limited representation of entities andevents in the world that is monitored by a system.

Idealisation hierarchy The idealisation hierarchy of conceptual model, logical modeland physical model.Conceptual (or domain)model

A logical model that defines terms and concepts in a businessor problem domain without reference to any computerapplication.In MDA, a computation-independent model (CIM).

Logical model A model that excludes details of physical implementation.In MDA, a platform-independent model (PIM) that is unrelatedto a specific technology (though may be related to an industrystandard).

Physical model A model that includes details of physical implementation.In MDA, a platform-specific model (PSM) that is related to aspecific technology, and may include specific infrastructurefunctions.

Model-Driven Architecture(MDA)

A vision of the Object Management Group that encouragesvendors to develop tools that help transform a conceptualmodel to a logical model, and a logical model to a physicalmodel, and the reverse.A transformation may be forward engineering or reverseengineering.

System modellingtechniques

Types of diagram used to model a systems structure orbehaviour. Most of the diagrams and notations used byarchitects emerged out of ways to define software systemarchitectures. Divided by BCS into structured and UMLvariants.Models commonly used by architects include processmodels, data models, context diagrams, use case diagrams,data flow diagrams, and interaction/sequence diagrams.


24/66


Page 23 of 65

Modelling language A standard that defines box shapes and line symbols fordrawing node-arc diagrams to represent relationshipsbetween things.

Integration DEFinition (IDEF)language

A modelling language in the field of systems and softwareengineering. Includes IDEF0 for system or process structuresand IDEF1X for data structures.

Unified Modelling Language(UML) A modelling language maintained by the Object ManagementGroup. Designed to help in object-oriented software design,though often used outside of that domain. Includes use case,activity, class and sequence diagrams.

ArchiMate A modelling language maintained by the Open Group.Designed to help in architecture description. Components,interfaces and services are shown in distinct boxes. Overlapswith UML but mostly more abstract.

3.2.4 Architecture Description Structures

Architecture repository An information base used by architects. A system that holds

and manages all the meta data that describes an enterpriseand its information systems.The content of the repository can be categorised in manyways, including tabular classifications such as the ZachmanFramework and the Enterprise Continuum.

Zachman framework A logical structure for classifying and organising thedescriptive representations of an Enterprise that aresignificant to managers and to developers of Enterprisesystems.Drawn as table or grid: the 6 columns are primarily analysisquestions. But they are also interpreted as architecturedomains (data, process, network etc.).The 6 rows are primarily levels of idealisation-realisation fromhighest level context to operational systems, but they are alsointerpreted as stakeholder groups and architectureviewpoints. Zachman says the rows should not be interpretedas levels of decomposition.

Enterprise continuum A structure for architecture description documentation used inTOGAF. A classification scheme for the contents of anarchitecture repository.Drawn as a table or grid, the rows are similar to those in theZachman Framework. The columns are a spectrum fromuniversal to unique.The 4 columns represent generalisation-specialisation,ranging from universal to bespoke or uniquely configured.

Foundation: Structures and items that are universal. Common systems: Structures (composed of foundation

items) that are used across most business domains. Industry: Structures and items used by enterprises in one

business domain (say Telecoms or Banking). Organisation: Structures and items specific or bespoke to

a single enterprise.The 4 rows represent levels of idealisation. From top tobottom:


25/66


Page 24 of 65

Requirements and context. [See architecture precursors.] The architecture continuum. [Defined below.] The solution continuum. [Defined below.] Deployed solutions (architecture implementations).

Architecture continuum A higher-level spectrum in the enterprise continuum, whichcontains logical or vendor-neutral specifications ofrequirements. It corresponds to the logical model level of the

idealisation hierarchy.Solutions continuum A lower-level spectrum in the enterprise continuum, whichcontains specifications of products and services thatimplement the logical specifications. It corresponds to thephysical model level of the idealisation hierarchy.

Reference model A relatively abstract model people use as a guide in creatingtheir own more specific model. Typically, a structure ofcomponents, services, processes or data entities. Sometimesfor a specific industry or business domain. A kind of designpattern.


26/66


Page 25 of 65

4. Business Architecture

This section is about one of the primary Architecture Domains defined in the first section of thisreference model.


Business goal A goal of an enterprise or organisation. [See Goal.]

Business objective An objective of an enterprise or organisation. [See Objective.]

Enterprise A business or organisation with common goals and budget, inthe public or private sector.A part of the real world that is directed and controlled by amanagement board to some human purposes, in whichplayers cooperate to meet goals and objectives.Usually the highest level of an organisation, spanning severalrelatively distinct organisation units.Usually a human activity system that involves people,processes and technologies.Usually maintains resources and properties.Usually governed according to principles and policies.

Business An enterprise or organisation that offers products andservices to its customers in return for payment or funding.

Organisation A synonym for the management structure of an enterprise orbusiness.

Organisation unit A physical subdivision of an enterprises organisation.Usually given a manager, goals, budget and employees.

Management structure The structure of organisation units defined by its managers.Usually a hierarchy decomposed to bottom level (elementary)organisation units. Usually shows the reporting line up from

each bottom-level manager to the management board.Sometimes a matrix.


4.2.1 Business Architecture Structure and Behaviour

Business functioncatalogue or portfolio

A list of business functions, usually arranged in hierarchicalstructure.Functions may be arranged in two or more hierarchies.Functions may arranged in a matrix in which the rows orcolumns may titled function, capability or domain.To validate and complete the business process and businessfunction structures, some decompose them to the same levelso that every elementary business process step is also anelementary business function.


27/66


Page 26 of 65

Business function An idealised or logical subdivision an enterprises capability.An encapsulation of the activities and resources needed toproduce a cohesive set of services and/or products, forinternal or external consumption. It may map to one or morephysical organisation units.E.g. Marketing, sales, customer services, security,

emergency response. (The examples in this section overlapbecause the concepts overlap.)Bottom level (elementary) business functions are commonlymapped to business process steps, to data entities and toorganisation units.

Core business functions A business function that is focused on the development,marketing, sales, creation and delivery of business productsand services (as opposed to a support business function).

Core competency A business function or capability that differentiates onebusiness from another, if only in the manner that the activitiesare carried out. It should be difficult for competitors to imitate.

Support business function A business function that serves core business functions. E.g.personnel, procurement or finance. Often similar in different

businesses, so an obvious candidate to be out-sourcedand/or delegated to a shared service. (Analogous at thislevel of definition to a reusable application component, butvery different in practice.)

Business capability A business function whose performance is the subject ofmanagement attention - as for example in Capability MaturityModels or in Capability-Based Planning. It is usually a high-level and cross-organisational business function.E.g. legal compliance, customer service, security, emergencyresponse. (The examples in this section overlap because theconcepts overlap.)

Capability-based planning Planning in which the focus of managers is to establish orimprove a business function regardless of currentorganisation unit boundaries. The end result of capability-based planning may be that a business capability is given amanager and becomes an organisation unit.

Business domain The primary business function of an enterprise ororganisation unit. Classifies an enterprise or organisation unitby the services it offers and/or the expertise it has.Sometimes a market segment. Sometimes a public sectordomain (say tax collection) that recurs only in differentnations.E.g. law, employment law, telesales, insurance, airlineoperation, airline maintenance, security, emergencyresponse. (The examples in this section overlap because theconcepts overlap.)

Business process A process that is important to an enterprise, leads to a goal ofthe enterprise, or involves people in the enterprise.


28/66


Page 27 of 65

Value stream A chain of activities; an end-to-end business process thatproduces a result valued by the customer. Products passthrough the activities, gaining value at each step.A key concept in the Six Sigma framework, which is designedto remove wasteful activities and optimise processes inproduct manufacturing industries.

Often shown as a nave end-to-end business process model,lacking the formality required for it to be automated.Value chain A particular kind of value stream featuring core business

functions (inbound, operations, outbound, marketing, salesand service) and support business functions (HR, R&D,Procurement).Introduced in Competitive Advantage: Creating andSustaining Superior Performance Michael Porter.

Business service (businesssense)

A service or product provided by an organisation unit orbusiness function to its customers, internal or external.Defined for its consumers by an interface or service contract,rather than by internal processes needed to deliver it.[Analogous in SOA to a software business service, but at a

completely different level of different analysis and design.]Service-orientedarchitecture (businesssense):

An approach that divides a business into distributedcomponents that offer business services to each other and tocustomers. Each component (business function ororganisation unit) may be defined by a Service LevelAgreement.[Analogous to SOA in software systems, but very different inpractice.]

Business data model A conceptual model of business terms and facts, independentof any specific computer application. The entities in themodel represent things in the real world. May also be knownas a domain model.It usually takes the form of a data structure that definesbusiness terms and concepts in the form of entities, attributesand relationships.

Business semantics A definition of business rules: that is, terms, facts, constraints(on data values and process steps) and derivation rules (fordata items). May be recorded in a data dictionary, a businessdata model and/or the pre and post conditions of processes.

Business model A term used by business managers to mean various thingsother than a business architecture diagram.1. The way an enterprise delivers products and/or services toits customers, determined by its business strategy.2. The operating model, sometimes expressed in terms ofhow far the business processes are or should bestandardised and integrated (after Ross, Weill andRobertson).3. A what-if model of business operations, perhaps inspreadsheets or animated workflow models.


29/66


Page 28 of 65

4.2.2 Business Process Decomposition and Automation

Process map A top-level picture of a business in which its processes arenamed. The processes are not connected, or connected bydependencies rather than control flow. Might be drawn as ause case diagram. Might be arranged in swim lanes.

Business process

decomposition

The hierarchical decomposition of a process into lower-level

processes. Every business process step may be defined as aprocess in its own right.To validate and complete the business process and businessfunction structures, some decompose them to the same levelso that every elementary business process step is also anelementary business function.

OPOPOT One person, one place, one time. A rule of thumb used todefine the bottom level of business process decomposition.

Process automationhierarchy

The hierarchy within an enterprise, system or project ofbusiness processesuse casesautomated services.[See applications architecture for further discussion of

process decomposition.]Information system service A use case or automated service provided by one application

to another, or to an end user.[See applications architecture for further definitions.]

Workflow 1: the assignment of business process steps to actors in anorganisation.Or 2: the logic or control flow of a process.Or 3: a technology that helps people to define or change oneor both of the above.

4.2.3 Design for Business Security

Design for human andorganisational security

Definition of all the things that can be done outside ofsoftware systems to secure business information, such assecurity guards, locks, definition and roll out of policies andprocedures.


30/66


Page 29 of 65

5. Data Architecture

This section is about one of the primary Architecture Domains defined in the first section of thisreference model.


Entity A structural thing that persists. A thing that is created,affected and ultimately destroyed by events.

Event A behavioural thing that happens. May create or destroy anentity, or move an entity from one state to another in itslifecycle. May affect several entities.

Data Can be divided into structured and unstructured data. [Thisreference model focuses on structured data.]

Information 1: Data at the point of use by an actor in a business system.Or 2: unstructured data as opposed to structured data.

Structured data One or more items (atomic facts) that describe one or moreentities or events. Contained in data flows and data stores.

Data item An elementary unit of information, a fact about an entity or anevent. An attribute of an entity in a data model or an event ina data flow structure. A variable containing a value that isconstrained by a type.

Data structure A structure that arranges data items in one or more groups.May be defined in logical model or at a physical level in anXML schema or a database schema.

Data entity The representation of an entity as a data structure thatpersists in a data processing system. Often records the stateof a business process.

Data event The representation of an event as a data structure in a dataflow input to one or more data processing systems.

Data lifecycle The life of a data entity expressed in terms of the states itpasses through from creation to deletion, and data eventsthat cause state transitions.

Type A generalisation; a form or structure common to severalthings; a constraint on an instance shared by all instance ofthat kind.

Data type A type that defines the properties shared by instances of adata item or larger data structure. It constrains the values ofthe data. It defines the processes that can legitimately beperformed on the data.

Data type (primitive) A data type defined in a programming language. e.g.alphanumeric string, integer, floating-point number (decimal),and boolean.

Data type (user-defined) A data type defined by systems analysts that is bespoke tothe business at hand. e.g. customer, order, product.

Constraint (rule) A business rule that limits the values of a data type.

Derivation rule A business rule that defines how the value of a data item isderived from the value of one or more other items (a specialkind of constraint).


31/66


Page 30 of 65

Meta data Data that describes data. Includes data structures, datatypes, business rules, data locations and data qualities.

Data dictionary A catalogue of data item types, which may include businessrules.

File A synonym of data store; any identified collection of datastored in the computer. May be used in a data flow. May besaved for future use. Sometimes means more specifically a

flat file, a data store in which data is stored and accessed insequence, starting at one end.Data source Any data store, actor or component from which data is

received by an application.


5.2.1 Unstructured data management

This entry is out of scope for examination purposes. The choice of content, document andknowledge management applications is as much or more a matter for applications architects thandata architects.

Content management The organisation, processes and tools for producing, storing,editing, sharing and searching any unstructured data.Roles can include creator, editor, publisher, administrator(managing access permissions etc.) and consumer, viewer orguest.

Document management A subtype of content management focused on electronicdocuments and document images. Usually includesprocesses for:

Capture, indexing, attaching meta data Storage, security Searching, retrieval Distribution, publishing Collaborative, configuration management

Often associated with workflow systems.Knowledge management A subtype of content management focused on the knowledge

of an enterprise and on capturing lessons learned. Typicallysupported by collaborative applications.

5.2.2 Data Architecture

Data in storage Those aspects of data architecture relating to data thatpersists in a location.

Data store A data structure that is held in persistent memory. Any file or

database from which data can be extracted by an application.You can define the state of any data store (be it a database,cache or component) in a data model (though it may containonly a flat list of attributes).


32/66


Page 31 of 65

Data model A schema that groups data items into a data structure anddefines the type of each data item. A structure that definesthe attributes of entities and the relationships between them.It may include derivation rules for some data items.A business data or conceptual or domain model is a vehiclefor documenting business semantics.

A logical data model is a definition of the data that mustpersist for the processes of an application to work.State The data structure maintained inside the memory of a

process or component.Database A persistent data structure that can be accessed by

applications. Usually accessed via a database managementsystem that enables direct (rather than serial) access to anypart of the data structure.[See section 12: Enterprise Technology Classification fordefinition of database management system.]

Cache A local store of data that has been copied from a master datastore, usually for the purpose of speeding up response orcycle time.

Data in motion Those aspects of data architecture relating to the movementof data.

Data flow A data structure that is transported from sender to receiver. Itis carried from data source to destination in a message, file,report or other data transport vehicle.

Regular expression A hierarchical structure of elements arranged so that everyelement is part of a sequence, or is an option of a selection oris an occurrence of an iteration.You can define the every data flow structure as a regularexpression (after Kleenes theorem). Though manymessages contain no more than a list of data items.[You can also define a process structure as a regularexpression, under a logical control flow in which loops andalternative paths are governed by conditions.]

Data format A format or language for presenting data flow structures.E.g. Comma Separated Values (CSV), Extensible Mark UpLanguage (XML).

Data format standard A standard for the content of data flow structures.E.g. EDIFACT, domain-specific XML Schema

Canonical data model The one true definition of data types (e.g. customeraddress, order value, tax reference number) used by anenterprise.A logical data model that defines the data types that appearin messages between applications, and in the signatures ofautomated business services.Usually applied to data in data flows, as a standard forintegration of applications, but could apply to data in datastores as well.A canonical data may be defined at a physical level usingXML schema and other data format standards.


33/66


Page 32 of 65

5.2.3 Data Qualities and Integration

Data quality A characteristic of a data item, data structure or data store.Notably: Confidentiality, Integrity and Availability (CIA).

Data integrity Data integrity (1): A data item has the same value in everypart of a distributed system. A fact (e.g. customer name) hasthe same value in all locations that data item is stored.

Data integrity (2): A data item obeys relevant business rules,sometimes in relation to another data item. The value of adata item is consistent with all invariant business rules e.g. anorder must be for a known customer.Data integrity (3): A data item accurately represents a factabout an entity or Event. The value of a data item in a dataprocessing system is consistent with a fact in the real world.Data disintegrity is a problem. Data integrity solutions caninvolve one-off data quality improvement exercises, datawarehouses and master data management.

Data flow (or message)integrity

The requirement that a data flow has the same data contentwhen it reaches its destination as it did when it left its source.

Data dissemination view A view showing the dispersal (and perhaps duplication) of

data between data stores or locations.Useful in analysis of change impacts, data mastering andsecurity vulnerabilities.

Data warehouse A kind of database system designed to hold a non-normaliseddata structure that is optimised for the production ofmanagement information reports.

Master data management The systems and processes that enable an enterprise tomaintain and/or find one master version of any data item ordata structure, typically customer or product data. Supportedby a range of approaches and technologies, includingmiddleware technologies that hide the reality of multipledisparate data sources from data consumers.

5.2.4 Design for Data Security

Data security 1: Confidentiality alone. Or 2: a combination of Confidentiality,Integrity and Availability.Tom Peltier suggests rating the security level of a data item,data structure or data store as equal to the highest of theindividual ratings (high, medium, low) awarded forConfidentiality, Integrity and Availability.

Security protection Prevention of access to data designed to maintain therequired data qualities of confidentiality, availability, andintegrity.

Security feature A feature of a system that enables its data and processes tobe protected.E.g. Encryption, Checksum, https.

Security policy A policy that defines which actors have (or do not have)Access rights to objects in a given domain - along with anyother protections.


34/66


Page 33 of 65

Information domain A uniquely identified set of objects with a common securitypolicy. Access to any data within the domain limited andconstrained by the same rules.

Identity One or more data items (or attributes) that uniquely label anentity or actor instance.E.g. passport number or user name.

Encryption A process to encode data items (in a data store or data flow)so that they are meaningless to any actor who cannot decodethem.

Checksum A redundant data item added to a message that is the resultof adding up the bits or bytes in the message and applying aformula. This enables the receiver to detect if the messagecontent has been changed. It protects against accidentaldata corruption, but does not guarantee data flow integrity,since it relies on the formula being known only to sender andreceiver.

Digital signature A cryptographic scheme that simulates the security propertiesof a handwritten signature. More secure than a check sum, itis said to guarantee the data flow integrity of a message,

since the signature is corrupted if the message content ischanged.


35/66


Page 34 of 65

6. Software Architecture

This section is about the internal structure of applications defined in applications architecture.


Modular design The design-time organisation of a system into components, ora process into sub-processes.You can divide a system or process into smaller modules bytop-down decomposition of its structure or behaviour.You can compose entities or processes into larger modulesby bottom-up cluster or affinity analysis.

Client An actor, computer or software component that requests oneor more services from a server. In software, the request isusually called an invocation.

Server An actor, computer or software component that can provideone or more services in response to requests from a client.

Design time structure andruntime behaviour

Design time is when a structure of components is defined.Run time is when those components work and interoperate.An architect should have a good idea of how a design-timestructure will behave at run time, since that is critical tomeeting non-functional requirements.

Encapsulation The enclosure within a component of processes, meaningthat the inner workings are invisible to outsiders. Also theenclosure within a component of data, so the only way toaccess that data is by using the interface of the component.(Components whose state is persisted outside of thecomponent often turn out to be pseudo components; theyhave an interface but do not encapsulate state, so externalprocesses may read or update that data).

Cluster or affinity analysis Techniques for finding and grouping items based oncharacteristics they share. An aim is to encapsulate cohesiveitems in one component, and minimise the couplings betweencomponents. Cohesive means closely related, inter-dependent or tightly-coupled by time, location, acquaintance,protocol or other ways. [See tight-coupling for more detail.]

Stateless Characterises a component or service that has only atransient state. Its working storage is discarded at end of theprocess. It does not persist between invocations (or at least,does not remember any data it worked on last t ime).

Faade A frontage to a building. An interface component that sits infront of a system and shields clients from some kinds ofchange to that system. Often, stateless.

Used to reduce the coupling between client and servercomponents. Used to aggregate services into a coarser-grained component.

Transactional Characterises a service that can be completely andautomatically rolled back if anything goes wrong. A desirableproperty in that it saves design effort and preserves integrity.


36/66


Page 35 of 65

Delegation One process or component calls on another to do the work,invoking it by passing a message (rather than by inheritance).May call a stateless faade.

Dependency A relationship between two parties in which any change to thedepended-on party implies an impact analysis of thedependent party.

Often reflects a client-server invocation, or delegation to aserver. Often represents a run-time relationship.Cyclic dependency A relationship in which two or more components depend on

each other. Considered to be an architectural flaw - fragileand unstable - difficult to understand and maintain. Softwarewith many cyclic dependencies is said to underminetestability, parallel development, and reuse.However, large-scale business components (e.g. Customer,Order, Product) are inevitably co-dependent.

Hierarchical (non-cyclic)dependency

A relationship in which higher-level components depend onlower-level ones, but not vice-versa.E.g. client components depend on server components, andapplication components depend on infrastructure

components, but not vice-versa.Service quality A characteristic of a service in a well-designed architecture.

A service conforming to Web Service standards has four suchqualities: it is an abstraction, composable, loosely-coupledand defined by a contract. Beyond that, a well-designedservice should be reusable, autonomous, discoverable andstateless.These eight qualities were suggested by Thomas Erl; and forsimplicity, a service should be transactional as well.

Service-oriented design A methodology that matches required services to availableservices. Required services are discovered thoughdecomposition of high-level business process and use cases.Available services are discovered in some kind of servicescatalogue and invokable across a network via some kind ofservices directory.

Service-oriented designchallenges

Obstacles to successful service-oriented design. Notably:service ownership, maintenance of shared services,versioning strategy. Governance of the service catalogue,avoiding vendor lock in, management of service-orienteddesign methodology across the enterprise.As a service consumer, you dont want service owner tochange the interface unless you ask, or refuse to change itwhen you do ask.


37/66


Page 36 of 65


6.2.1 Component Interfaces

Application ProgrammingInterface (API)

An interface used to invoke the services of an application, ormore usually, an application platform technology.

Interface Description

Language (IDL)

A language for defining an API that is, ideally, independent of

the technology used to implement the component behind theinterface. Enables communication between components indifferent languages and running on different operatingsystem. An interface generator (pre-compiler) reads the IDLto create a header file for use by client and server, and clientand server stubs.

Realisation (softwaresense)

The act of providing an implementation for an interface. Aservice is an abstract thing until there is a system orcomponent to implement it.One component may realise (publish or offer) more than oneinterface e.g. older and newer versions, or full and restrictedlist of services. One service can appear in several interfaces.Components require interfaces as well as offer them. Acomponent with a required interface desires to meet acomponent with a matching offered interface.

Synchronicity How work, divided between two components, is scheduled.The two components are called client and server below, butcould be called sender and receiver, or prior and successor.

Synchronous 1: A request-reply style: a client must wait for a server to replybefore continuing. (This is the usual invocation from oneCOBOL module to another or one Java object to another.)Or 2: A blocking style: a server serves one client at a time,turning away any other client who attempts to request aservice. The caller and responder hold a channel open,blocking others from using it. (This is the usual invocationstyle

Documents

Sd Esa Reference Model