Category: Frameworks

Using controlled vocabularies and semantics to improve Enterprise Architecture repositories – principle 5

by Tolosa, posted in Content Authoring, Controlled Vocabulary, Evidence, Evidence Based Enterprise Architecture, Frameworks, Glossary, IEEE1471, Semantic

One of the recommendations of IEEE 1471 (the standard for describing the architecture of a software-intensive system) is to establish a conceptual framework and vocabulary for talking about architectural issues of systems. To provide a definition of what controlled vocabularies are and why they should be used i refer to Wikipedia and the following quote:

In organizations, controlled vocabularies may be introduced to improve technical communication. The use of controlled vocabulary ensures that everyone is using the same word to mean the same thing. This consistency of terms is one of the most important concepts in technical writing and knowledge management, where effort is expended to use the same word throughout a document or organization instead of slightly different ones to refer to the same thing.

Both enterprise architecture and evidence based activities benefit greatly from a controlled vocabulary. By creating and agreeing on a controlled set of terms, and the meaning behind the terms, helps readers understand commonality and relationships across document sets that support projects, processes, policies and strategies etc. and therefore a greater understanding of what the document is trying to say.

Where evidence is used to support enterprise artefacts and documentation the use of controlled vocabulary helps ensure that the evidence is understood and bears meaning to the hypotheses and recommendations it is supporting.

Enterprise architecture development method – principle 2

by Tolosa, posted in Business Strategy, Enterprise Architecture, Frameworks, TOGAF

Each architectural framework (TOGAF, MODAF, DODAF, FEA) has its own development method that describes how to construct and deliver an architecture of the organisation from their prescribed artefacts. Perhaps it is just taken for granted that architects will research and use evidence where appropriate to justify their views and recommendations.  Yet  those methods i have used and have researched (i am not knowledgeable on all architecture methods) do not factor the concept of evidence application in their approach. So for principle 2 i am recommending that by adopting evidence based enterprise architecture it requires an addition to the governance and methodology to include activities that encourages research and application of evidence to support decisions, hypotheses and recommendations.

The role of an enterprise architecture repository – principle 1

by Tolosa, posted in Enterprise Architecture, Enterprise Architecture Ontology, Enterprise Architecture Repository, Enterprise Ontology, Evidence Ontology, Frameworks, Information Management

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.

Supporting alternative decisions

by Tolosa, posted in Business Strategy, EBEA, Enterprise Architecture, Evidence, Evidence Based Enterprise Architecture, Frameworks

The alternative options are often dependent upon the type of goal an organisation is aiming to reach as well as the situation the decision maker is in. Here perhaps is an important area for evidence either to prove that the original decision is the best choice or show that an alternative is better. Alternative decisions in enterprise architecture often centre around technology choices, which product is the best fit and stands out from the others that have been considered. Product evaluation can be a lengthy process and can primarily be based upon a set of requirements issued to each vendor. The vendor which best meets the requirements and provides a cost within budget is most likely to be the winning contender. Yet does the evidence show that the product and the vendor is the best choice.

The evidence framework to support the decision making process behind this type of decision should depend upon the size and impact of the strategy or goal. If the goal is to introduce a new organisation wide application then the evidence framework needs to be broad enough to enable detailed questioning of key capabilities and situations. Using the example of a important goal of purchasing a new organisation wide application, which will impact a large number of employees and departments, then evidence should be gathered on the following:

  • The current situation of the vendor; its financial position; company size and number of clients; expertise of key staff or board members; company locations – nationally and internationally; history of the vendor and its relationships with other organisations, partners, standards bodies and associations.
  • The vendor’s product and its position within its product portfolio; history of the product; awards; key clients, case studies and reviews by organisations such as Gartner, Ovum or Forrester.
  • How has the product been received by other customers; the trade press and internet forums.
  • The development process behind the product; who are the key designers and innovators behind the product; the vendor’s product position at trade conferences – how often and at which conferences does the vendor exhibit and make presentations?
  • Product capability and technical requirements; documentation and training programmes
  • Product support and service management capability; field staff numbers and support lead times.

This list is just a set of examples of topics that should be gathered as an evidence framework for each vendor and then compared against the enterprise architecture and at each architectural level. This is to determine how each alternative product will fit within the architecture and its impact on existing structure. This may seem like a lot of effort to gather all of this information but this type of evidence gathering my highlight that an alternative vendor to the main contender is a better fit for the organisation even if it means a higher initial cost. A decision based on requirement fit and cost alone may turn out to be a bad decision in the long term.

Enterprise Architecture value assurance

by Tolosa, posted in Enterprise Architecture, Frameworks, Information Management, 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.

Knowledge, Evidence and Architecture

by Tolosa, posted in Enterprise Architecture, Frameworks, ITIL, TOGAF

I have been looking at the requirements for knowledge building and sharing to advise a major programme. By now i would have thought that there should be enough guidelines for how teams should be doing this but still there seems to be obstacles.

What does a reader want when they are looking for something to help them support or perform the task they are doing? They want assurances that the information they find is going to add value to their task.

My advice to them was to consider preparing a knowledge charter for all participants at all levels of management. In this charter it should set out the rules, roles and responsibilities of how knowledge is created and distributed to all team members. More importantly it should set out clear evidence and references to underpin the facts and figures they use.

Every team member, at some point of their participation, will create information to support a project deliverable. That could be either a word document from a template, a visio model or diagram,  a spreadsheet or powerpoint presentation. The charter must set out ways to use reviews, opinions and feedback to distinguish particular pieces of information that can be defined as project knowledge.

These distinguishing features should be outlined through the document’s metadata and summaries. A reader coming to the document through a search should be able to determine what the document addresses and how useful that document will be to them. A reader will be coming to that document looking for answers to problems, challenges, solutions or advice as well as evidence that the knowledge within the document will be reusable to contribute to the the task they are involved in.

I was asked how this charter could advise on content structure and my first response was to keep document terms to well defined and understood business methodologies to help remove ambiguity. Secondly, to help the reader and their investigations by providing good, old fashioned references to quality sources of information.

All things created should be useful to someone or a group of people at some point in time. The value of that thing (document) as knowledge may be very specific to a particular task or a limited audience at a point in time however, there will be a percentage of that content that will have a lasting value to others. Determining  that value is greatly enhanced if it pertains to frameworks, standards and evidence. Standards and Frameworks such as  ITIL, MSP or TOGAF have a clear structure, terminology and application and are widely recognised and accepted.

Providing supporting evidence may provide the greatest value but it is important to determine the quality of that evidence before making any decision on value. Through this blog i am going to explore the different ways of building up appropriate evidence to support architectural decision making and scenario planning through the structure of a framework and associated systems and standards.