Tag: Decision Making

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.

Evidence behind organisation goals

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

Goals exist at every level of an organisation and it is important that behind each goal is sufficient evidence that the target of the goal is the right decision and that it is achievable. It is often hard to measure the effects of decisions on very long term enterprise level goals unless there is a dedicated team monitoring from beginning to end.

At an enterprise level a long term goal may be dependent upon the success of many subgoals therefore creating complex interdependent relationships. As the path to reaching the goal develops the effects of the decision stages should be assessed as well as relevance and value of the underlying evidence.

The evidence used to help the decisions behind long term enterprise goals may be in several forms. Data based evidence includes such things as statistical reports, business intelligence, trends, financial projections and forecasts. Content based evidence generally includes internal reports, externally published and purchased reports from leading organisations such as Gartner, Ovum, Mckinsey etc. competitive analysis and recommendations from internal or external experts.

It is likely that an organisation will spend considerable money, time and effort assembling and analysing the evidence before decisions are made. It is therefore important to track and monitor the value of the evidence against the benefits delivered as the organisation moves towards the goal. This i believe is a role for enterprise architecture.

Realising the goal is likely to have an impact and sometimes a major impact on the enterprise architecture. The architects tasked with defining the future architecture should monitor the evidence for changes over time and consider these changes for possible impacts on the future designs.

For example, an organisational goal to adopt a new ERP system or scale up operations or service lines will have an impact on the business, information and technology architectures. The evidence behind the decisions suggests certain courses of action as well as the purchase of new technologies. Over time the evidence sources may change their opinions, views or recommendations or new evidence may arise to question the original conclusions.

This is often termed horizon scanning and if overlooked then the result could be costly errors and damage to the original outcome of the goal.

Enterprise Ontology – a framework for building and identifying corporate evidence

by Tolosa, posted in Enterprise Architecture Ontology, Enterprise Ontology, Evidence Ontology, Ontology, OWL, RDF, Semantic

Role of an enterprise ontology

For an overview of this concept i am going to reference an article written by Dave McComb called The Enterprise Ontology. It offers a good description of an ontology, an Enterprise Ontology as well as some very good reasons as to why an organisation should build one. The article was written in 2006 and i will quote the first paragraph: At the time of this writing almost no enterprises in North America have a formal enterprise ontology.

Yet we believe that within a few years this will become one of the foundational pieces to most information system work within major enterprises.

We are now in 2011 and i am not aware of any publicised stories of any companies in the USA or Europe or the rest of the world for that matter that are able to say they have an enterprise ontology and that it is underpinning the information systems that exist within organisation.

Whilst it is expected that it will take an organisation some time to design, model and build an enterprise ontology the benefits will, if it is managed effectively, bring considerable change to people and value to the information created.

An enterprise ontology provides the enterprise indexing system to define meaning, classification and categorisation for past, current and future information. By providing this it aids evidence and evidence based enterprise architecture by creating a means to “frame” information by specific terms and definitions and thus aid like to like relationships.

If we consider evidence as either proofs or observations derived from a formal or scientific approach as well as opinions and expert statements created from renowned experience and capability; thus that evidence has to be

An Evidence Ontology

by Tolosa, posted in Evidence Based Enterprise Architecture, Evidence Ontology, Information Management

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.

Evidence behind the deliverables

by Tolosa, posted in Business Strategy, Enterprise Architecture

I am going to use TOGAF and the deliverables set out in the Architecture Development Method to highlight some examples of documents which should be evidence based. Within the Preliminary and Vision phases the Business Strategy is the principle design guide to the development of the core architectures.

I consider a baseline or current  architecture and the target architectures to be statements of fact and design and generally portrayed through conceptual models. How the architect arrived at theses models and on what basis is another issue and it is here that i see evidence based methods being most useful and appropriate. How does an architect decide which design is the right one to support a strategy? The architect’s decisions are based on the instructions within the business strategy and the goals and drivers within the blueprint. If the business strategy is weak then there is a likelihood that that the proposed architecture will not be able to fulfill the strategic requirements.

What makes a good business strategy document and where should evidence be used to back up findings and recommendations? Let’s consider the primary requirements of a typical business strategy document:

  • Strategic Focus
  • The Business AsIs
  • Market Analysis
  • Products
  • Marketing
  • Research and Development
  • Production and Delivery
  • Supply Chains
  • Business Systems and Processes
  • Stakeholder Relationships and Alliances
  • Organisational Development and Management
  • Environmental and Social Impacts
  • Risk Factors and Regulatory Compliance
  • Corporate Governance
  • Financials
  • Application of Investment Funds
  • Strategic Action Plan
  • Plan Improvement

Each of these topics represents key aspects of the business and as such the positions, findings and recommendations for change must be evidence based. I am going to assume that the business strategy has been written independently and is then presented to the Enterprise Architecture unit.  The first thing an architect must do is to review the evidence underpinning each of the topics and decide upon the validity and and impact of the decisions in relation to the size of change they propose.

Let’s consider an example where the strategy is recommending change. Market analysis has shown that sales for a particular product line have fallen over the last 12 months. A review of this based on interviews with retailers and questionnaires to customers has shown there to be a number of technical problems that customers are not happy with and thus they are returning products for repair against guarantees. This has led to costly updates and an extra burned on the service department. Further research has indicated problems with a supplier of key components and incompatibilities with technology within the product manufacturing and assembly division.

The strategy recommends a review of the current suppliers and a review of the manufacturing technology and has asked a team, which includes an Enterprise Architect, to begin a project to investigate a solution. The task for the Architect is to dig deeper in to the research and evidence to ensure that the root cause has been identified. Has the evidence located which technologies if any are failing. Has the original review discussed the problems with the service teams and considered what actions they have been taking? If the evidence has not identified specifics then there are still unanswered questions. It is too easy to take evidence at face value and begin activities without solid foundations.

The Architecture needs to consider the make up of the evidence, how detailled were the customer and retailer surveys, what questions did they ask and where they the right questions. Is the product line key to overall sales and what is the current relationship with the supplier. Is the product line merely reaching the end of its lifetime and perhaps it may be better to close the product line rather than commit further investment. This is where the Architect needs to consider a view from the business architecture and determine the proposed change in line with the wider enterprise architecture.

People and evidence

by Tolosa, posted in EBEA, Enterprise Architecture, Uncategorized

It is important for architects to understand and apply evidence and research findings to their work. At the same time it is important to encourage the decision-makers to pay more attention to that evidence and question it so that it can help inform their decision-making. Often the decision maker is not expecting or wanting to see negative evidence that contradicts their plans or strategies.

I was going through the electronic version of TOGAF 9 and i was surprised to find that the term evidence only appears 6 times. The first occurrence is in section 8.2.2 Developing the Baseline Description within the Business Architecture and the other 5 relate to the security aspects and gathering evidence in the event of a security breach.