SOA in Tax Administration

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

2. 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:00 09-09-2014

3. SKAT Organization and challenges Danish Tax Administration - SKAT • 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…

4. EFFECTIVENES Staff & ITCapabillities Improvecompliance Improved compliance Declarations audits, collectionsdebt cases Outcome InputCapabilities Output Mission Cost effectiveness SKAT Organization and challenges Business Strategy Tax Administration • Ultimate KPI: maximise compliance + maintain tax payer confidence • Challenge: Reduce cost (of IT) Business process Debtcollection Auditing Service Reporting

5. SKAT Organization and challenges Effective Tax Administration = Digitization & Automation Citizens e-declarations 1987 - 2011 Paper DeclareOnline ”No Touch”

6. Business process IT Governance in SKAT - IGIS Service Reporting Auditing Debt Collection Process owner Process owner Process owner Process owner System owner System owner IGIS System owner System owner Projects Platform Architecture

7. SOA objectives • 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

8. Lessons learned

9. Strategy Main drivers 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 • 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 SOA Transformation

10. Governance and Organization Main drivers Lessons learned 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. • 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

11. Technology Main drivers Lessons learned 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. • 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

12. Support and Maintenance Main drivers Lessons learned 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. 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