Industry Reference Model framework

INTRODUCTION

Systems need to be established and evolve and over time. Therefore an understanding of what lead to the current state is critical. These endeavours include a gamut of challenges: regulatory, governance, policy, institutional arrangements and agreements, organisation structure and roles, skills and capabilities, technologies and technical standards, transitional and phasing, etc. To often this knowledge departs or lies in thousands of documents and files.

There are existing best practices emerging in how to establish industry frameworks. There use addresses: recognised issues associated with the implementation of complex information systems by government; assists using in capture knowledge in a semantically precise way; allows specific local implementations to be supported that can be mapped to external reference set (that reflect common best practice).

In implementing a system one needs to ensure it can evolve. This allows it to be extended to address future needs. The evolution of systems requires that the raison d’être for the design of the systems and organisations is understood i.e. so that experience is institutionalised and retrograde “enhancements” can be avoided.

This framework must ensure semantic precision and allow easy case by case instantiation. It relates patterns, principles, standards, modules (or build blocks), reference models and maturity levels. It allows the adoption, emphasis or abnegation of the elements in the framework in each specific implementation to be made explicit. This allows the framework to be common – while each implementation is different with a mapping between the common framework and the specific implementation

ANALYSIS OF PROBLEM

Complicated systems

Complicated systems and relate to complex organizational structures. They are typically networks of systems, distributed and loosely coupled, in federated or discrete organizations, serving a multitude of purposes and audiences, support transactional and archival functions. To address the problems effectively we need to learn from other complex disciplines better and recognize that many of the best practice that applies to these apply to our systems.

Specifically we could start by looking at the generic problems associated with the implementation of complex IT systems (especially in government).

The Royal Academy of Engineering and and The British Computer Society observed that

"A significant percentage of IT project failures, perhaps most, could have been avoided using techniques we already know how to apply. For shame, we can do better than this."

They go on to say:

"It is alarming that significant numbers of complex software and IT projects still fail to deliver key benefits on time and to target cost and specification. Whilst complex IT project success rates may be improving, the challenges associated with such projects are also increasing rapidly. These are fuelled in large part by the growth ... in the capability of hardware and communications technology, and the corresponding inflation in people’s expectations and ambition.".

They examine how complex IT projects differ from other engineering projects, with a view to identifying ways to augment the successful delivery of IT projects.

Amongst their findings and recommendations are that:

– “A striking proportion of project difficulties stem from people in both customer and supplier organisations failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry, as well as inadequacies in the education and training of customer and supplier staff at all levels”

– The significance of systems architecture is not appreciated.

– Further developments in methods and tools to support the design and delivery of such projects could also help to raise success rates. In particular, basic research into complexity is required to facilitate more effective management of the increasingly complex IT projects being undertaken.

– There is an urgent need to promote the adoption of best practice amongst IT practitioners and their customers.

They also identify some things that we think most people have known for some time e.g. the need for good project management and risk analysis. However both of these tasks are significantly impeded if the underlying knowledge required for analysis is not available.

What issues does an framework address

A framework must help improve:

– collective professionalism – by providing all parties a way of undertaking analysis, design and planning in an effective and professional manner.

– education and training – by providing an explicit relationships between the outcomes, the procedures and systems, the organizations and roles, and the skills required.

– architecture – by provide a template for defining: sector or industry (NSDI) architect, the enterprise architectures and systems architectures

– strategies for dealing with complexity – by providing methods and tools that support the analysis, design and delivery of systems

– adoption of best practice – it is all to easy to speak of adopting best practice, everyone does, but in order to do this we really need to define what the elements of best practice are, how this knowledge is manner and provide a strategy for its adoption.

What capabilities does a framework need provide

It needs to allow federated group of participants to do a number of things, with greater transparency and more objectivity. Transparency helps people understand what and why they agree or disagree on things in an objective and unemotional manner. Reaching consensus is therefore easier. So it must be possible to:

– Capture drivers and requirements – these are the things that determine what a system should. Each and every elements of a solution (roles, skills, technologies etc.) must derive from these.

– Undertake analysis – a simple structured way to analysis is required. Analysis can be organised around simple set of canonical model (Goals, Facts, Beliefs and Recommendations).

– Design and decide – Designs are assemblages of elements. So we need to be able to record these things (and relate to externalities e.g. technologies). Design and decision making is made based on analysis of alternatives. So we have the information on drivers and requirements and are able to undertake analysis we can make explain the basis of decisions and designs.

– Plan, Programme & Phase – these require us to understand sequencing, prerequisites and co-requisites (implementation constraints). Intrinsic is the relationship between the requirements and the designs (i.e. the set of design constraints).

– Promulgate, educate, communicate and socialize – we need to be able to very selectively extract information for the framework that is suited to a particular audience, purpose or interest. What is keep is that we don’t need to manually re-craft communications artifacts for each different purpose or audience (and ideally we want information to be discoverable)

– Estimate the effort, costs, risk and timeframes associated with people, technology, procedures – in practice costs can only be effectively estimated by examining the proposed implementation i.e. the designs. But decisions need to be made related to the requirements and outcomes therefore we need to understand how the elements of the implementation relate to the requirements (and the marginal economic impact of each requirement).

– Support the validation, assessment, quality assurance and review – by making the above relationships explicit and transparent we provide a mechanism for doing this in a clear simple, and object way.

What is best practice (what can we learn from)

We can learn from a number of standards and approaches that are applied elsewhere by examining some existing methods e.g. ValIT (Val IT - is framework addressing the governance of IT-enabled business investments), COBIT (Control Objectives for Information and related Technology), OSIMM (Open group SOA Integration Maturity Model), CMMI (Capability Maturity Model Integration), FEAF (Federal Enteprise Architecture Framework), DODAF (Department of Defense Architecture Framework), TOGAF (The Open Group Architectural Framework), Zachman Framework , ITIL (Information Technology Infrastructure Library), IFW (Information FrameWork), DSM (Design Structure Matrix), Pattern Language (i.e. Alexander’s seminal work), TMForum.

These are from many disciplines e.g. engineering, architecture, portfolio analysis, defense, IT, telecommunications, etc.

Our approach to a framework is informed by these sources and others. The effectiveness of these approaches has in the past significantly impacted in most cases by their means of implementation (usually many documents and consultants). We need an approach that minimizes the need for both.

What does best practice suggest a framework needs to encompass

Space does not permit a full review of all of these but we believe that there is general consensus that following seem to make good sense:

– Business case and investment models – FEAF, ValIT

– Reference Models – FEAF, OSIMM

– Principles, patterns and anti-patterns – DODAF, Pattern Language, TOGAF:

– Principles – Pattern Language, TOGAF,

– Standards and technologies – TOGAF, FEAF, ITIL, OSIMM

– Modules (modularity, building blocks, e.g. service and components models) and collaboration models: indicating interfaces between roles and systems – IFW, DSM

– Taxonomies – DODAF, Zachman,

– Maturity models – CMMI, OSIMM, TOGAF (implied)

– Compliance mechanism – Cobit, FEAF, OSIMM. CMMI

– Different levels (of detail, of technicality) – Zachman, Pattern Language

– Instantiation – almost all of these frameworks allow instantiated instances

A FRAMEWORK BASED ON BEST PRACTICE

What analysis is enabled by semantic precision of the framework

In general we seek to provide a mechanism for better “analysis”. We proposed a simple model based on facts, goals, beliefs and recommendations. Where: goals are things you are trying to achieve, sometimes expressed as principles, issues (goals stated the reverse), visions, measures, objectives or KPIs; facts are not disputable and include laws, regulations, social factors and technical constraints; beliefs are based on facts and relate to goals and include causes, findings, implications; and recommendations are based on beliefs and achieve goals and strategies, plans etc. In addition we would want some grouping concepts (classification systems) for: terms, patterns, principles, technologies, standards etc. By support business or analysis with this paradigm we move for persuasive narrative to structured reasoning.

There are two types of specific analysis that we want to be able to do. I call them referential and inferential.

Referential analysis allows us to confirm that the relationships between element are correct this allows us to follow a path of relationships i.e. if this skill is unavailable what is affected, if this goal is to be achieved what is required, what elements are affected by this projects.

Inferential analysis is useful when we have compositions or when we have reference models - where we can related our implementation to the reference models. It allows us to infer what relationships should exist i.e. are implied to exist but do not. It allows us a check on correctness.

Reference models would usually be instantiated e.g. for example a functional reference models indicates a function is performed, our instantiation would indicate how we perform it. A data reference model indicates data we need, our instantiation would indicate how we manage it exactly.

While this seems obvious in this example when the relationships above are all described textually e.g. in a document inconsistencies are not so easy to see. Wven when they are dealt with graphically when there are large amounts of information (or multiple level of decomposition) these inconsistencies are hard to see. In both cases best practice would be to have systems do these checks (rather than checking for them manually).

What is the scope a framework

Therefore we propose a set of reference models which capture the fundamental issues

Determinants

Externalities that determine what a business does, how it operates etc. These are external factors that include: cultural and social, market and competitive, legal and regulatory, etc.

– Environmental, kegislative and regulatory reference model (ERM): describe the sets of laws, regulations and compliance issues (national and international), and local factors.

Strategy

Enterprise strategy, vision, mission, goals, strategies and plans (product, market, organisation), cases, governance and compliance, measures etc.

– Strategy reference models (XRM) – which relates to the Determinants and covers the vision, goals, strategies etc.

– Performance reference models (PRM) – which outlines the performance goals, measures etc. (Cf. FEAF’s PRM)

Operations

Enterprise operations - business: services, processes, rules, information (objects, documents, data etc.), organisation, facilities etc.

– Offerings, services and product reference model (OSM) – which outlines offerings, services and products which need to be provided to achieve the strategy

– Functional reference model – which outlines the capabilities, functions and steps, that must be performed to achieve the strategy (Cf. FEAF’s BRM).

– Rules and policy reference model – which outlines the rules and policies that are required by the strategy and determinants and to support operations.

– Information reference model – which outlines information, metadata and data required by the strategy and determinants and to support operations.

– Organisational reference models – which outlines the organizational networks, units, roles, techniques, skills that are required by the strategy and determinants and to support operations.

Systems and facilities

Systems and facilities including: applications and services, technologies and system services, facilities and internal utilities. The systems area could be further divided into business services and systems and technology services and systems (though the boundaries can become blurred)

Suppliers are externalities that determine the products, services, standards a business can use e.g. technology products, services and standards; product channels; real estate and facilities.

– Interface reference models – describes the interfaces, services and by implication the applications required for a system to operate.

– Technical reference models – describes the technologies, standards required to supports the interfaces.

– Vendor reference model – describes the products, agreements etc. required

Patterns and maturity models

Sitting beside the reference models are some knowledge bases:

– Patterns and template implementation plans – which indicate exemplar implementations and relate these to the reference models

– Maturity models – that outlines stage of maturity and relate these to the other aspects of reference models.

The 1^st three can be considered to represent the requirements and the last two are in the solution domain.

The Environmental, Technical, Vendor are effectively the external constraints.

These reference models are related to allow different types of analysis (referential and inferential) to be performed. They are most useful when they are related so as to allow impact analysis (both between domains, and within domains). Unfortunately many are often presented diagrammatically (great for communication, hopeless for analysis) or represented using inconsistent semantics, modelling paradigms that can't be related, or using arcane technology terms that are not meaningful to 99% of the world (e.g. use case, actor, cardinality etc.).

Need to be analysable from the top (and bottom) - this is why absence of Determinants is so limiting as ideally these would allow one to relate the circumstances to the strategy, and then from that the strategy to the operations; and the suppliers to the systems and facilities. It is why compliance issues seem so hard (and produce such a good feeding frenzy for consultants).

To be support modularity they can connect within each level and between each touching levels (in defined ways).

Need to be tailored and used carefully - as with all things that represent purported best practice they need to instantiated in-situ (using experience and judgement) to produce something that is useful in the specific set of circumstances. This needs to be done in a way that allows: the variations to explicitly understood and for the source reference models constant while being connected to detailed views of the enterprise e.g. the FRM may connect to existing detailed process models, the IRM may connect to data models, the PRM may connect to existing KPIs, etc.

Key characteristics of the framework

We can see a number of other key characteristics we require

– Implementation technology neutral and non-aligned – our framework must intrinsically technology and vendor neutral i.e. having no affiliation of alignment, and no preferred technology, products. This allows a clearer focus on the real needs and on standards.

– Accessible by anyone from anywhere – this effectively means Web accessible and is key so that knowledge can accessed where, when and by whom its it required and that knowledge can be capture as a natural by product of field work.

– Supporting different roles, scenarios of use, and levels of control – that is with role based access and presentation, so that people can see what they are interested in in a way that makes sense to them and can change information that is in their domain of control.

– Ensure semantic precision - which ensures it is analyzable, fully auditable, that the basis of decisions is explicit, objective and transparent. The lack semantic precision is one of the key problems with most, if not all, approaches based on documents.

– Represent idealised models – that has a holistic, coherent and complete set of well-structured, unambiguous and well partitioned and categorised set of business definitions (roles, functions, interfaces etc.). Has an explicit conceptual model of how the systems organizations are structured and operate (e.g. reporting, controls, data flows etc.)

– Divides the generic framework from the specific implementation - so the generic framework is reusable and extensible. Allows nations to maintain their know how i.e. how they do things, why they do things - rather than this knowledge be in the hands of third parties with vested interests e.g. consultants, vendors.

– Allows relationships and concepts to be – visualised, analysed and reported on.

– As simple as possible – to reduce complexity we limit connections within each level and between each touching levels.

CONCLUSIONS

We seek to make a non-incremental step to the way the systems are implemented. We believe that a framework with specific characteristics, capabilities and structure in order to allow best practice to be capture and applied. It is only by establishing this that we will significantly improve the efficacy of system implementations.

We can see that we identify many best practice methods we can learn and we believe there are better ways now available to implement a framework that will enable it operate effectively.

At present many parties are focused on capturing knowledge that should reside in a such a framework. Sadly much of the knowledge still resides in documents or in people’s heads where is not particularly useful (accessible, integratable, analyzable etc.) and frequently “leaves the building”