Technology perspectives driven by vendors, fashion and ignorance

Prompted by more maddening items on orientation

Firstly let me say that I believe the following perspectives should be considered as 1st order when looking at ICT systems:
- presentation (from services i.e. they are by definition presented, to interfaces)
- information (from knowledge to data)
- process (from a capabilitity, to a function, to a process, worflow, to step/activity)
- rules (from a law, to a policy, to a rule, to a decision and control mechanism)
- characteristics (from being cool, sexy to what some might call non-functional requirements)
- organisation (from culture, to organisation, to role, to people).
- location (from country, to region to specific location)

Key 2nd order elements are:
- components (from products to objects) which can often be consider assets

I would also think that technologies (products and standards) are used by the vendor community (products and consulting vendors) to drive an feeding frenzy in some new (actually not new) area each year or so - so that some new set of things can be sold.

Orientations over the decades:

• Information - When I 1st learned to programme the focus was on memory management and jumps in assembly langauges (there was no focus on presentation).
  
• Rules - Then it was on logic and alogrithims e.g. Fortran, Algol, SNOBOL, LISP (oriented around Formulas, Algorithms, rules for processing strings, rules for processing lists).
  
• Integrated - For a while real applications were then written in langauges that considered logic (presentation was fixed by the very limited range/type of devices; location/organisation/characteristics were effectively fixed by the integrated OS/HW). This was actually quite a productive time.
  
• Information - Databases emerged and information engineering became king. Everyone forgot about function points because all you needed as information model (not).
• Integrated - Then it moved to OO (and data and logic don't exist discretely). Unfortunately the methods were usually oriented at coders not business people.
• Process - BPR lead to a brief fling with business process orientation, but it was really just a way the consultants to pack as many graduates as possible into organisations so they could document what was alreading known. In the course of this "Imaging" vendors became "workflow" vendors, before coming "BP vendors" and of course now they are "SOA" vendors.
  
• Presentation - now with SOA we can focus on another set of technical standards and products.

Sooner or latter surely people will realise that all these perspective need to be considered (i.e.
presentation, information, process, rules and characteristics) and they stop throwing the baby out with the bath water.

An introduction to reference models

An introduction to reference models. Models are ways of organised information so it can be used to answer questions. Reference models provide a consistent (and often best practice) way of organising information about something. They may be used a categorisation structure or they may be considered high level elements that are decomposed into more detail.

Determinants - few integrated sets of these exist in the public domain. Ideally one would have things such as: Legalislative and regulatory RM (LRM)

Enterprise strategy - RMs covering: goals, strategies, measures etc. some example include: FEAF's PRM (Performance RM) and one would ideally also have a Goals RM.

Enterprise operations - RMs covering: products, services, functions and processes, information and data, policies and rules, organisation structures and locations. Some examples include: NGOSS's eTOM, SID, FEAF's BRM) etc. So one would have: Functional RM (FRM), Rules and Policy RM (RRM), Information RM (IRM), Organisational RM (ORM), Services/Products (SRM).

Systems and facilities - RMs covering: systems and facilities performance (e.g. SLA templates, technology goals/principles). Some examples include service and application RMs: FEAF's SRM, NGOSS's TAM), Technology RMs: FEAF's TRM, TOGAF's TRM. The connection of these internally may be between the SRM and the functional modules/services associated with specific suites or services.

Suppliers - Some examples include: sector classification schemes; channel models; agreement topics (contract templates). This would include a Vendor and products RM (VRM)

The RMs should:
- connect within each level and between each touching levels.
- connect to detailed extant 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.
- allow direct impact analysis to be undertaken
- allow inferential analysis to be undertaken (I will discuss this in latter entries).
- be treated a set and applied

RMs are:

1. Most useful when analysable - whenf 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.)
2. Not a silver bullet - but there is little doubt that using reference will often accelerate thinking and reduce the scope for oversight. However the value of this should not be underestimated. For many large organisations it may take a team or 1/2 people working for a year or so part time to come up with the above. More often than not they never complete anything useful.
3. 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.
   
4. Need to be analysable from the top (and bottom) - this is why absence of Determinants RMs 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).
   

A structure for thinking about enterprises

A structure for thinking about enterprises

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.

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

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

Systems and facilities - including applications and services, technologies and system services, facilities and internal utilities. The systems area can be further divided into business services and systems and technology services and systems.

Suppliers - externalities that determine the products, services, standards a business can use e.g. technology products, services and standards; product channels; real estate and facilities. This section includes details of all provisioning and agreements.

Effectively the external constraints are the determinants and the suppliers; the goals come from the strategy and the operations, systems and facilities - represent a solution set (i.e. designed to the meet the goals based on the constraints).


Notes on the above

1. I have tried to avoid using two loaded terms in the above "architecture" and "framework". I use Enterprise to encompasses things that may not be "businesses" per se.
2. In each of the middle three areas there may be change initiatives (for transformation or optimisation driven from that level).
3. Business requirements derive largely from the Enterprise Strategy and Enterprise Operations.
4. User acceptance is the confirmation that the Systems and Facilities meet the Requirements i.e. represents a boundary condition and/or illustrates compliance with a set of constraints (e.g. requirements).
   
5. The division into into business services and systems and technology services and systems may be increasingly hard to work with in a way that is useful for decision making for most enterprises e.g. splitting a GPS function used by a business into its: application, infrastructure (device) and service (e.g. satellite) components may in practice be difficult. This will increasingly be the case as consumer and external services and components are integrated to support Enterprise operations. Similiarly in the past some technology reference models have identified somewhat layers of technology that are increasingly irrelevant in practice with many devices e.g. operating systems, graphics presentation, file and database, etc. are not that useful if the device is an appliance. These division are probably useful distinctions for technologies operated internally by an enterprise. But a decision is 1st required that operating these technologies internal is to be desired or required.