SOA in Tax Administration Meeting DG Taxud and SKAT Friday the 12 th of October 2012 Copenhagen

Agenda - tentative Introduction SKAT Organization and challenges SOA implementation and IT technical aspects Lunch 12:30-13:15 SKAT cantina SOA governance and methodology Break 14:30 Possible further collaboration AOB End of meeting 16: Page 2

Danish Tax Administration - SKAT Page 3 Reduction of staff from above 11,000 (2005) to below 8,000 (2011) Merger of local and state tax administration 2005 SKAT is responsible for taxes, VAT, duties, customs, collection, assessment of real estate, vehicles administration, tax on gambling IT Architecture office Supports business development, IT-projects, system owners – C2C/G Architect – Plan – Build Staff: 27 – mix of Architects, Service Modellers, Tech Coordinators… SKAT Organization and challenges

Business Strategy Tax Administration Ultimate KPI: maximise compliance + maintain tax payer confidence Challenge: Reduce cost (of IT) 23/10/2015 Page 4 Improve compliance Mission Improved compliance Outcome EFFECTIVENES Cost effectiveness Staff & IT Capabillities Input Capabilities Declarations audits, collections debt cases Output Service Auditing Debt collection Reporting Business process SKAT Organization and challenges

Effective Tax Administration = Digitization & Automation Paper Declare Online ”No Touch” Citizens e-declarations SKAT Organization and challenges Page 5

Service ReportingAuditingDebt Collection Architecture IGIS Platform Business process Process owner System owner IT Governance in SKAT - IGIS Process owner System owner Process owner System owner Process owner System owner Page 6 Projects

Page 7 The SOA based modernisation program requires us to establish the architectural foundations for:  Increased efficiency – reuse of services  Leaner and more transparent administration  Faster, cheaper and safer implementations of changes  Reduction of information technology risks – no -legacy debt  Facilitation of competition on it-solutions – no vendor lock-in  Simplification and normalisation of the access to the IT systems  Securing a clear separation of IT systems  Commitment from the main parties of the organisation SOA objectives

Lessons learned Side oktober 2015

Side oktober 2015 Strategy Main drivers Main drivers for the SOA modernization at Skatteministeriet Reducing cost of operating it Easier integrations and reuse Strategy was to centralize and gain from order of magnitude – one platform technology suite and one integration operations vendor. Recent change of strategy: Federate platform to multiple vendors Lessons learned SOA becomes complicated on its own Unknown performance hit on legacy- systems (expensive MIPS) Long road to realization Technology is not the driver, business is What we would have done differently Focus on keeping things simple Focus on business case in every decision Clear distribution of roles and authority SOA Transformation

Side oktober 2015 Governance and Organization Main drivers Governance is done through having a central resource pool for technical resources lend to projects. These resource handle governance and implementation of guidelines. For each application there is a process and system owner, whom also owns all provided services. Development, maintenance and operations are outsourced. Lessons learned Key skills needed for success Mediator Business modelers Primary need is the skill to assess consequences of decisions. Responsibility for resources and time need to influence architectural decisions in order to avoid technology driving the development. Place responsibility for maintenance and operations close to development partner during handover. SOA Transformation

Side oktober 2015 Technology Main drivers Architecture based on global principles that all implementations must follow. The idea is that the architecture is clear and determining for the solutions. E.g. all integrations must be services. Public contracts was the main driver for waterfall method. Now a change towards more agile methodologies are piloted. Lessons learned The architecture needs to be flexible in such a manner that solutions can deviate from guidelines, whenever It is reducing cost or time Not impacting other applications The complexity in going from white- board to operating solution was unforeseen. Thus delays and added cost resulted in weakened business cases. In the future focus will be on lowering risk and building solutions gradually. SOA Transformation

Side oktober 2015 Support and Maintenance Main drivers The goal was to gain a better overview of integrations and the architecture. This was planned through a shared service modeling tool and service catalogue. The documentation continues to grow, yet the necessary quality has not followed. Hence a change towards fewer service, with more focus on maintaining the overview is planned. Lessons learned The complexity of SOA is making root- cause analysis more difficult. This is worsened by integrations over multiple vendors. Single immature or poorly performing vendors cause serious problems across SOA. The modules of applications and systems in the architecture does not always match the business structures and processes. SOA Transformation