1. From Interoperability to Installed Base Cultivation

2. Interoperability Interoperability = standards Interoperability = paradise/nirvana? The more the better? Conflicts between interoperabilities?

3. 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

4. The EU’s eCustoms Initiative

5. 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

6. Figure 6. Development of the European e-Customs information infrastructure 2000-2010

7. Figure 5. Information flows in an export process 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

8. Figure 4. Organization of e-Customs projects at EU, national, and trader level. EU Domain Strategy/ProgrammeProjects EU Domain Strategy/ProgrammeProjects NCTS Multi-Annual Strategic Plan Customs 2002 Customs 2007 Customs 2013 ECS ICS AEO EORI... Danish Domain Projects/Subprojects Danish Domain Projects/Subprojects e-Customs Project NCTS ECS ICS AEO EORI... Arla Domain Projects Arla Domain Projects Adaption projects ECS ICS

9. 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) TBG18 Agriculture TBG2 Digital Paper TBG15 Trade Facilitation TBG8 Insurance TBG19 eGov TBG1 Supply Chain TBG4 WCO DM TBG3 Transport TBG13 Environment TBG5 Finance Figure 3. UN/CEFACT International Trade and Business Processes Group (TBG) and key relationships between these working groups. Redrawn from Dill (2007).

10. 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 …

11. Plus For each new system: – Control (RM) systems build on top of customs systems – Additional data collected for control purposes

12. 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

13. 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

14. 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

15. 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

16. Critical issue Understanding complexity – Network effects/externalities – Process, path dependency (& lock-in) Complexities cannot be managed! – Avoid creating it!

17. Design principles: Installed Base Cultivation Bootstrapping Simplicity – Maximum feasible simplicity – Maximum imaginable complexity – Minimum imaginable simplicity gateways

18. 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

19. Growing networks Manipulating preferences Arranging users Bootstrapping

20. ’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

21. Identifying and arranging preferences Multi-dimensional Personal, individual Use areas and situations Technological aspects Coordination/governance structures Arranging preferences and dimensions (dynamically)

22. 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

23. Individual/personal preferences Motivation, attitudes towards technology Knowledge about technology

24. 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

25. Aspects of technology “Distance” between users and designers/vendors complexity costs flexibility “allied with the future”

26. 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)

27. 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

28. 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

29. 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

30. 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

31. Changing networks & infrastructures Extensions – transformations Changing large infra: Changing individual modules

32. 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

33. Example 1: IPv6 Extending functionality (range) Continuous change Tunnelling (=gateways)

34. Example 2: E-mail Many gateways : Internet, AOL, nets based on proprietary prot( cc:mail ++) Permanent solution Not trivial (addresses)

35. 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!

36. 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

37. The NORDUNET Plug

38. Gateways Important because – Quick, efficient, well working solution – Compromise: Everybody’s interests were accounted for Were considered traitors in the rest of Europe

39. 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