Transcript The history of HII in Norway – learning from the history

From
Interoperability
to
Installed Base Cultivation
Interoperability
•
•
•
•
Interoperability = standards
Interoperability = paradise/nirvana?
The more the better?
Conflicts between interoperabilities?
Infrastructures
• Evolve – not designed from scratch
• Infrastructure design = shaping the evolution
• Infra design strategy = process strategy
• Need
– European Process Strategy
– European Process Framework
– European Process Architecture
• Interoperability generates processes
The EU’s eCustoms Initiative
eCustoms
• Harmonizing, streamlining customs declarations in
EU (since 90-ies)
• Aim:
– Originally: 25% cost reductions for traders: ”Single
window”
– Later: security
• Increased trade/globalization
– New risks: Mad cow, terror, counterfeit, ..
– Containers, big hubs
– New customs control procedures
• From transaction to system based control
Figure 6. Development of the European e-Customs information infrastructure 2000-2010
System abbreviations:
ECS: Export Control System
EORI: European Operators Registration and
identification system
ASS:
Agriculture Subvention System
EMCS:
European Movement Control
System
CRMS:
Customs Risk Management
Systems
Figure 5. Information flows in an export process
Danish Domain
EU Domain
Strategy/Programme
Multi-Annual Strategic Plan
NCTS
Customs 2013
Adaption projects
NCTS
ICS
Customs 2007
Projects
e-Customs Project
ECS
Customs 2002
Arla Domain
Projects/Subprojects
Projects
ECS
ECS
AEO
ICS
AEO
EORI
...
EORI
...
Figure 4. Organization of e-Customs projects at EU, national, and trader level.
ICS
TBG18
Agriculture
TBG2
Digital Paper
TBG15
Trade Facilitation
TBG8
Insurance
TBG19
eGov
TGB15 International Trade Single Window
TBG14 International Supply Chain Model & TBG2 UNeDocs Data Model
TBG17 UN/CEFACT Core Component Library
United Trade Data Elements Directory (UNTED)
TBG1
Supply Chain
TBG4
WCO DM
TBG3
Transport
TBG13
Environment
Figure 3. UN/CEFACT International Trade and Business Processes Group (TBG)
and key relationships between these working groups. Redrawn from Dill (2007).
TBG5
Finance
Development activities
• First step: Transit system
– Aim: One common export system
– Extensive adaptation to national installed base
• Next: Export system
– Developed one system in each country (=27
independent implementation of the same spec.)
• Next …
– Aim: One common system …
Plus
• For each new system:
– Control (RM) systems build on top of customs
systems
– Additional data collected for control purposes
Dynamics
• More trade, more risk, more needs for control
• New systems for customs declaration
– => new opportunities for building new control
systems
• Adapted to (national) installed base
– => more stability
– => more fragmentation
• Traders need to adapt their system to 27 diff.
National IIs
Status
• National IB increasingly more complex
• More fragmentation – increasingly frozen
• Moved in wrong direction – harder to change
direction
• Conflicts between RM/control and efficiency
• Conflict between national and European
interoperbility
The shaping of the evolution of the
eCustoms II
• Process strategy: Specification driven, one
system at the time
• Architecture: tight coupling within national IIs,
loose coupling between national IIs (outcome
of gov. regime)
• Governance: Loosely coupling between tightly
coupled national projects, traders detached
• All wrong
Alternative?
• Process strategy: Evolutionary, learning
focused
• Architecture: loose coupling within national
IIs, tight coupling between national IIs,
(minimum data), traders connected through
one European portal/gateway
• Governance: Tight coupling between loosely
coupled national projects, traders integrated
Critical issue
• Understanding complexity
– Network effects/externalities
– Process, path dependency (& lock-in)
• Complexities cannot be managed!
– Avoid creating it!
Design principles: Installed Base
Cultivation
• Bootstrapping
• Simplicity
– Maximum feasible simplicity
– Maximum imaginable complexity
– Minimum imaginable simplicity
• gateways
Granovetter/Schelling model
• Ex: Dying seminar, crossing a street
• Our preferences depends on others actions
• Preferences vary
• Processes depends on distribution of
preferences
• Small changes may have large effects
Growing networks
• Manipulating preferences
• Arranging users
• Bootstrapping
’Bootstrapping’
• Enclocypedia: ’She bootstrapped herself to the top’ – to
manage on one’s own
• Lifting yourselves by your hair
• Booting a computer
• Implementing a programming language
• Language learning
• Making a tool/network by means of the tool/network
• ”Deliver a better today, rather than promise a better
tomorrow”.
• Late adopters adopt because the others have already
• First adopters must adopt for another reason
Identifying and arranging preferences
•
•
•
•
•
•
Multi-dimensional
Personal, individual
Use areas and situations
Technological aspects
Coordination/governance structures
Arranging preferences and dimensions
(dynamically)
Bootstrapping Network Technologies
• Select motivated and knowledgeable users
• Simple, non-critical, non-complicated use
areas where no large organisational changes
are required.
• Select simple, relatively cheap and well
supported technical solutions.
• Users first, then functionality/technology
Individual/personal preferences
• Motivation, attitudes towards technology
• Knowledge about technology
Aspects of use areas and situations
• Resources
• Benefits of communication within a small
network
• Critical/non-critical activities
• Complexity of tasks and work practices
• Organizational changes needed
Aspects of technology
• “Distance” between users and
designers/vendors
• complexity
• costs
• flexibility
• “allied with the future”
Coordination and governance
• Structures and institutions have to be
established (bootstrapped)
• “Standardization bodies”
– Technology (protocols)
– Work practices/procedures (protocols)
• (The Internet is an example to learn from in
this respect as well)
Interdependencies and conflicts
• Highest benefits:
– Radical change,
– critical situations
– complex technology
• Advance along one dimension before another
• In general: use (enrol more users) before
technology
Design strategy 1
• Start with
– simple, cheap, flexible solution
– small network of users that may benefit
significantly from improved com. with each other
only
– simple practices
– non-critical practices
– motivated users
– knowledgeable users
Design strategy 2
1. Repeat as long as possible: enrol more users
2. Find and implement more innovative use, go to 1
3. Use solution in more critical cases, go to 1
4. Use solution in more complex cases, go to 1
5. Improve the solution so new tasks can be supported
Lock-in and gateways
• Large networks are never made from scratch –
extending and improving the installed base
• Backward compatibility
• EPR: institutionalised (standardized network) of
practices
• Fit/support existing practices (otherwise no
bootstrapping)
• Makes a larger network – harder to change
• Gateways between old and new networks:
connected and different
Changing networks & infrastructures
• Extensions – transformations
• Changing large infra: Changing individual
modules
Change strategies
• “Flag day”
– Everybody changes at the same time
– Requires tight coordination
– Coordination must be possible
– Now needs for technological support
• Continuous
– No coordination needed
– Needs technological support
Example 1: IPv6
• Extending functionality (range)
• Continuous change
• Tunnelling (=gateways)
Example 2: E-mail
• Many gateways : Internet, AOL, nets based on
proprietary prot( cc:mail ++)
• Permanent solution
• Not trivial (addresses)
Example 3: NORDUNET
• Nordic universities: Establish interoperability
–
–
–
–
–
Many different networks:
HEPnet: physicists (CERN), DEC
EARN: ?, EDB-centres, IBM
Internet: computer science,
....
• Strategy: Common protocol - OSI !!
• Different interests – all users wanted a quick solution, i.e. based
on their existing technology
• OSI – slow progress, complicated, …
• Flow of money was about to be closed
• Had to find a pragmatic solution! Fast!
Solution
• Tried out various strategies and technologies,
..
• Two important events occurred:
– IBM wanted to transfer EARN to the univ.
– A Cisco-router that also was running DECnet, IBM,
X.25 over IP appeared
The NORDUNET Plug
IBM
DECnet
IP
Gateways
• Important because
– Quick, efficient, well working solution
– Compromise: Everybody’s interests were
accounted for
• Were considered traitors in the rest of Europe
Further developments
• Made connections to other networks easy –
install SW on own computer
– Especially relevant for Internet
– dual stack solutions
• Caused transition to Internet
• Important reason behind Scandinavia’s early
adoption of the Internet