The production of enterprise architecture documents should adopt a formal content authoring framework – principle 4

The common tool across most organisations for authoring documents is Microsoft Office – Word, Excel and Powerpoint – however this does limit the usefulness of the information contained within the document. Even though Microsoft has updated the file format to an XML based format this still does not allow the author to add intelligence to the document by way of tagging content with more than just headings and styles.

In order for enterprise content management systems and enterprise search engines to manage and deliver content to users they need to be formatted in a particular way with metadata and xml. Microsoft Word and Excel are able to do this but there are other tools that could be used to build a better content library for an enterprise architecture repository. At this point I am not talking about models produced with an appropriate enterprise architecture tool such as Troux or Aris but document based artefacts.

It is worth considering the potential benefits from authoring content within a XML authoring tool – at the moment i am looking at an open source tool from Syntex called Serna. This is a WYSIWYG XML authoring tool that offers DITA and Docbook formats and at some later date i will post some comments on the application.

The role of an enterprise architecture repository – principle 1

Enterprise Architecture Management System
Enterprise Architecture Management System

The Enterprise Architecture Repository is both a means to store all of the artefacts concerning the enterprise architecture and a federated information system linking with other sources of data and c0ntent. This federated environment produces a enterprise architecture management system to support architectural development. There is quite an interesting overview of this on the Aris Community blog.

Along side the standard features of the repository, to hold the information pertaining to the AsIs and ToBe models, is the need for the system to support research development and evidence management. The enterprise architecture is represented by a collection of facts and statements about the enterprise. They are collected in a set of artefacts and are used through the architecture development methodology to build future versions of the enterprise. It is the change from the current state of the enterprise to a new state that evidence is required and applied to support change decisions. The evidence that is used and cited within artefacts it should be stored within the architecture repository. This enables the evidence to analysed and tracked through the lifetime of the decision.

The evidence repository is a subset of the EA repository or federated knowledge base that has defined relationships that link the evidence to the artefact. This can be achieved through simple hyperlinks but a defined approach with specific artefact metadata and unique identifiers would offer a structured relationship. This should also encompass the evidence metadata to provide the attributes to support tracking such as the value, confidence and temporal attributes.

Whilst it is important to store evidence cited within artefacts within the EA repository it is also important to store research and information to act as future evidence. This form of evidence should be built with a formal process and should be collected in line with future views of the organisation. This type of evidence can include horizon scanning of new technologies, customer or user opinions and surveys, planned legislative changes or innovations.

I have made this principle 1 because i consider an enterprise architecture repository a fundamental part of enterprise architecture and building up and storing evidence is a vital part of evidence based enterprise architecture.

Principles of evidence based enterprise architecture

These are a set of principles specifically for evidence based enterprise architecture and would follow on from those I have described in the earlier post on evidence based design.

  1. An organised enterprise architecture framework and repository must be used to provide a model of how the organisation defines enterprise architecture and a store for enterprise architecture artefacts.
  2. The enterprise architecture framework must define the development method used in practice and all of the artefacts used in the process should include evidence where appropriate.
  3. The production of all enterprise architecture artefacts must follow a controlled authoring and management process. All artefacts must have appropriate metadata and be stored in a document management system. There must also be a review process to ensure consultation and validation of content and evidence.
  4. The production of enterprise architecture documents should adopt a formal content authoring framework such as DITA – Darwin Information Typing Architecture (OASIS standard) to help structure the content and allow for reuse.
  5. A controlled vocabulary should be used to minimise ambiguity and support information relationships within the repository. The Universal Data Element Framework (UDEF) should be considered as a way to classify and categorise terms used in documentation.
  6. There must be a controlled evidence model to define how to classify evidence and evidence value. The evidence model must at least be able to define the following evidence attributes:
    – Value 
    – Sources
    – Credibility
    – Expertise
    – Impartiality
  7. All architects should be trained on how to perform evidence research, evidence analysis and how to incorporate evidence where appropriate into artefacts to support any hypotheses, propositions and recommendations.
  8. Any evidence used in an artefact must be clearly marked and identifiable to help traceability, tracking and analysis in the future.

These are just a few I have identified and I will probably add to this list and define each one in more detail in future posts.

An Evidence Ontology

Monastery of Hosios Loukas - Gabriel
Monastery of Hosios Loukas - Gabriel

I have been thinking about the task of developing a model of the classes and attributes  of an evidence ontology to support Evidence Based Enterprise Architecture. Having searched on Google, not that i was expecting to find an exact match, i came across something similar for the field of biosciences.

It was interesting to read how they have approached the problem. They describe the use of their ontology as a means to record a collection of assertions, the sources of the assertions and the degree of confidence experts hold in the assertions.

There are very similar relationships here with the requirements for an evidence ontology for evidence based enterprise architecture. Firstly the means to classify particular assertions made in the enterprise architecture. For example these assertions can be found within the artifacts such as models and specifications, the architectural and solution building blocks and statements recorded in architectural views.

Secondly the ability to classify the degree of confidence in the assertions as expressed by senior architects and subject matter experts. Measuring the confidence is perhaps a two fold activity whereby the author assess the confidence and this is either accepted or revised by an expert.

Enterprise Architecture value assurance

Why is value assurance important to Enterprise Architecture? Value assurance is a means to review plans, proposals, architectural designs and strategies to determine that value to the business will be delivered.

Like any assurance process it cannot guarantee value will be delivered but it can investigate and decide that the information is aligned to a framework or standard and that the evidence is sound and backs up the decisions, risk mitigation and actions. Value assurance should be independent in its approach and incorporate consultation and critical reviews of all proposals. The objectives of a value assurance review should be:

a) To provide external challenge to the architecture project team at each key decision stage; to help assess the validity and robustness of the work done and the key areas requiring focused attention; and to assist in achieving the value of the deliverable.

b) To assess the suitability of the plans and strategies to ensure a go ahead to operate within the context of the overall Enterprise Architecture.

c) To appraise the readiness and justification of the project to proceed into the next phase, including the project’s soundness for capital allocation.

d) To capture lessons learned for dissemination across EA teams and, where appropriate, facilitate best practice transfer into the maturation or project team.

Two important areas of value assurance are the compliance to the enterprise architecture framework and the validity of the evidence supplied. Checking compliance is relatively straight forward by ensuring the proposals are all based on the agreed template and process, checking evidence is a lot harder.

If an organisation has had a disciplined approach to information management (supported by an enterprise information management strategy ensuring all formal information is well classified, categorised and accessible) then an evidence relationship map should be straightforward. By evidence relationship map i mean the pedigree of references to past documentation pertaining to the current proposal.

For example, references to three similar projects implementing the same technologies or business decisions that have all proved value through their successes – delivered to schedule or cost, shown effective transformation and or growth through sales or customer satisfaction.

If an organisation has poorly managed their information assets then building up evidence to support decisions will be a lot harder. I suspect most organisations are a mix of these two scenarios and as Enterprise Architecture is relatively new, historic information assets aligned to the EA framework is unlikely. Value assurance and evidence management are two critical activities to support Enterprise Architecture maturity. If an organisation is not using evidence to support architectural decisions then it is running the risk of undermining the importance of its EA and its ability to deliver value in the future.