This dissertation has been submitted by a student. This is not an example of the work written by our professional dissertation writers.

1. Introduction

Service Oriented Architecture - SOA is a software architecture for complex information technology systems and it is an attempt to break down the silos of information that was created in the earlier traditional system architecture. Since the 1970s, matrix organisation structures have been used to facilitate the growing project orientation, an orientation that has dominated organisations throughout the 80s and 90s. Since the last decade, organisations have been experimenting with different organisational structures such as ambidextrous, spin out, networked, emergent and virtual organisation. Nevertheless, there are numerous traditional hierarchies and matrix organisations represented today. The paper explores the impact of implementing SOA in NAV/NDU on social structures and the organisational culture in the organisation. While SOA is a highly technical area, it is expected that the changes that SOA would bring in would extend to employee's new roles and designations, changes in the power hierarchies and how people are expected to react to the possible traumatic changes. The paper also makes some recommendations on bringing in change management techniques and principles to better manage the human face of SOA implementation

1.1. Background

Since the past few years, we have seen a number of concepts; technologies, products, ideas and innovations emerge and go. Through the same time, a number of strategic and tactical choices have been made and implemented in organisations, making many of the implemented choices as core systems. This has left companies with extremely heterogeneous IT environments often with monolithic systems. The rush of mergers and acquisitions in the last decade has further complicated this picture. These evolved IT environments have left many organisations with a number of concerns. From the IT perspective the systems can be very inflexible, poorly documented and resource demanding to maintain and develop. Some companies have a number of groups of specialists advocating their technology. Business demands have simultaneously become increasingly complex and demanding. Businesses need to react swiftly to changes and be continuously innovative. In order to do this, companies depend upon their IT to support the business processes. The evolved IT environments have difficulties keeping up with the agility demand from business processes. This gap between demand and ability is one of the core issues SOA seeks to address. The idea from the technical perspective is to exploit existing legacy systems by identifying reusable services and exposing them to consumers on the Enterprise Service Bus (ESB) with web service technologies such as SOAP and WSDL. From the business perspective, the thought is to implement business processes and orchestrate them to fit the business needs. The business processes are then programmed to access exposed services as needed. The orchestration and implementation of business processes is very agile and can be modified quickly. Thus the value of SOA lies in the following: Reusability, Agility, Flexibility, Drawing the business needs closer to IT and Cost efficiency. This somewhat illustrates the dimensions, diversity and perspectives on SOA. SOA is a flexible framework and a concept not easy to concretise.

1.2. About NAV/NDU and the Project Context

Like many other countries, Norway as well has introduced a comprehensive retirement pension reform. Part of the decision was that the IT technology and infrastructure to support the implementation of the political decision is that the IT infrastructure must be agile and modern when the political decisions are made and implemented sometime during 2010. Once the political decisions are made it is the responsibility of The Norwegian Labour and Welfare Administration (NAV) to put these decisions into effect. NAV is organised as a directorate (NAV) and a development and administration division (NAV/NDU). These are two separate organisations. The practical development and implementation of the pension reform is organised in a program (PP), which is responsible for deliveries to NAV and NAV/NDU. In order to facilitate the guidance of agility and innovative technology, NAV, PP and NAV/NDU have launched massive efforts to adopt Service oriented architecture (SOA).

The effort has been organised in the external program (PP) consisting of mainly external consultants. The implementation is multi phased and the estimated lifespan of the program is through 2010. First phase was set into production primo December 2007, once developed; the new infrastructure and applications need to be delivered to NAV/NDU, which has the technical IT, responsibility. To prepare for this NAV/NDU has established an internal project (MP). Among MPs main objectives is the preparation of the organisation, Quality Assurance (QA), documentation, training and approval/disapproval of milestones.

NAV/NDUs operations department has a traditional silo oriented structure, where most specialists have well-defined areas of responsibility. The SOA framework introduces a number of new roles and in order to prepare for the transition, organisational changes must be made from a silo oriented mindset towards a more cross-functional view. MP has established a model for a cross-functional administrative organisation, involving both NAV/NDUs operational line organisation and the PPs project oriented organisation. At this point the new framework comprises the pension reform, however strategic decisions have been made appointing the SOA architecture to be the new standard architecture for future development projects at NAV/NDU.

Among a number of new roles and structures, an operations manager for the new pension solution has been appointed. The organisational form pursued is the matrix structure. This strategic decision has implications for the existing organisation of NAV/NDU. The new framework must be adopted in the organisation and a cross-functional administrative organisation must be build to support this. It is the implications of this choice this study seeks to illuminate. In addition, I aim at suggesting improvements for NAV/NDU.

1.3. Aims and Objectives of the Research

The aims of this research is to identify organisational challenges while adopting SOA-operations and moving an organisation in Norwegian public sector towards a permanent matrix structure using the case of NAV/NDU.

The objectives are to:

* Chart the current organisational situation at NAV/NDU ICT-operations in the context of adopting SOA.

* Identify organisational strengths and weaknesses, based on the current situation and on research around SOA adoption and matrix structures.

* Provide suggestions for improvement on how to proceed in respect of transforming NDU operations to optimise facilitation of SOA operations.

1.4. Contribution to research

There is substantial research on matrix organisations; most of this however is in project facilitation context. There seems to be very little research on organisations implementing matrixes as a permanent solution, which is the case here. SOA is a new area and not much research has been done yet on the subject. There is a unanimous view among researchers and professionals that SOA is the future mainstream. This makes it a very interesting field. The diversity of SOA and possible implementation degrees, chosen timeframes, techniques, products and more will in my opinion motivate researches to present research on transferable cases with a high degree of detail. I believe this case has the potential to be such a contribution. I expect the implications illuminated in this paper to be valid to similarly organised ICT-operations departments adopting emerging concepts.

1.5. Justification of research

NAV/NDU is currently implementing SOA. While there are sufficient efforts underway to take care of the technical requirements, the human face of the implementation is largely ignored. By focussing on the social and cultural impacts of SOA implementation, the paper attempt to explain how people would behave with the new matrix organisation structure, how they would react to the loss of power structures and imposition of new roles and definitions. This is a very important aspect of the research as people and their management is very important for NAV/NDU.

1.6. Limitations of the Research

The paper has used the case study method to conduct research on various social and cultural aspects of SOA implementation. Findings of such implementations in different firms have been analysed and presented. Due to logistics reasons, the survey and questionnaire method was not followed.

1.7. Research Methodology

The research method selected will be an interpretive case study. The approach is to start by chartering the current situation at NAV/NDU. It will be done by studying internal documents and communications. Relevant literature research is intended to illuminate problem areas specific to relevant organisational issues. It was originally planned to conduct primary research with interviews from subject matter experts - SMEs from NAV. The original plan is modified and now includes a literature-focused study. This is also called as 'case study approach' to research and an accepted research method. Peer reviewed journals and periodicals by fellow research associates would be examined to see how their findings would suit the NAV organisation.

The deviation and change in method is justified by a comprehensive enterprise wide restructuring process forced by political decisions at NAV/NDU. This occupies many of the key interview subjects and complicates access to the subjects significantly.

The report may serve as a benchmark and guide for the SMEs. Later and as a part of the second phase, a proposal to conduct an additional primary research with interviews of key SMEs is made. I hope to provide new valid insights on organisational implications in moving SOA-operations into a permanent matrix structure and suggestions for future directions for NAV/NDU to consider.

1.8. Summary of the Main Findings

The main findings are summed up as below:

* SOA implementation should consider the impact on the social and cultural fabric of the firm. There would be two sets of employees and the management who would be impacted, specialists SOA developers/administrators who develop, implement and maintain the code and the users, who would be using the new SOA structures. Management would have a further task of overseeing the SOA implementation.

* New roles and designations would be created among the users and conflicts can be expected when the traditional and new matrix organisation structures work side by side.

* Alienating one while depriving the other is not a good policy and a proper change management approach is required to ensure that all functions operate smoothly.

* The SOA-operations manager should be given budgetary and personnel authority.

* Where required, extra personnel should be recruited to lessen the fatigue and workload of current SOA team members.

1.9. How the Paper is organised

The paper is organised into different chapters with each chapter discussing and important aspects of SOA. Structure of how the paper is organised is as given below.

Chapter 2. Literature Review: A comprehensive literature review of organisation structures, matrix organisations, social issues of SOA and other topics is provided in this chapter. Also given are brief reviews of SOA governance and the implications of adopting SOA for NAV/NDU, Gartners Hype Cycle for SOA, interactions in SOA, elements of SOA and challenges and drawbacks of SOA.

3. Methodology: The chapter discusses important aspects of qualitative and quantitative research and examines the case study approach used in this paper.

4. Organisational Science - Permanent Matrix Structures: The chapter first presents an understanding of the requirements at NAV/NDU and then discusses important aspects related to new and emerging organisation structures. Examples of matrix structures are given along with an analysis of creating and implementation of matrix organisations.

5. Organisational issues while adopting SOA: The chapter examines critical success factors for SOA implementation and examines SOA and the business process changes that are expected.

6. Conclusions and Recommendations: A summary of the findings are presented in this chapter and a set of recommendations made for NAV/NDU for the SOA implementation.

Appendix: The Chapter provides extensive write-ups of different data gathering method, technical aspects of SOA and details about technical SOA internals.

2. Literature Review

This chapter discusses at length various aspects related to SOA and create a thorough understanding of how SOA is designed to operate, what it can do and how it would help the organisation. The focus is on the social related aspects of SOA. Please refer to the Appendix “A2. Technical aspects of SOA' and ‘SOA Internals' for technical discussions of SOA.

2.1. Understanding SOA

To begin with, SOA is a software architecture system and not an application like Windows, SAP, Oracle or others. Portier (2007) notes ‘SOA creates a framework and system development method for integration of applications'. It has been created on concepts of matrix organisations, modular programming and distributed programming. It must be noted that in the early days of computerising departments, large organisations tended to develop software applications for a particular need or a departmental need. Fragidis (2008) notes that development work was sometime done in-house and in many cases outsourced to vendors. Over a period, organisations realised that they had a number of software applications but they realised that they could not access information of one system from another. In other words, silos of information had been created. The task of bringing these myriad applications to a common platform would not be so easy. The applications were created in different languages, platforms, databases and operating systems. As an example, accounts had one system that was developed by one vendor while marketing had another system from another. The same probably occurred with other departments such as stores and inventory, purchase, manufacturing, production, logistics and so on. So overall, the firm was equipped with a collection of systems that remained stand-alone and information could not be exchanged with one another.

2.2. Organisation and Social Aspects of SOA

Ribeiro (2008) argues that adopting SOA is not just about technology, upgrading software applications, migrating databases but it is also about the cultural changes and the changes in human and social interactions for an organisation. When a new architecture is to be adopted, it is expected that there would be merging and removal of some roles with new roles and responsibilities occurring. Lin (2009) says that thus, adopting SOA would require a change management approach. This section discusses the organisational changes expected while moving to SOA along with the drawbacks and advantages of SOA, matrix organisations, SOA governance and the implications on NAV/NDU while adopting SOA (Sun, 2006). .

2.2.1. Organisation Structures

Biggiero (2003) posits that organisations have assumed the form of ‘multi-criteria decision-making bodies'. It is assumed that ‘outranking methods for organisations are actually algorithms where the epistemological and methodological effectiveness can be improved by using algorithms'. Vinoski (2006) says that they prescribe the behaviour of decision makers. Decision makers on the other hand have their own intrinsic evaluations with multiplicity so that they would be able to imagine things from different points of view. Thus, there are multi criteria choices.

Hannan (1986) argues that the issue of multi criteria assumes a different form during group decisions that would have many criteria and are voiced by various members. There would again be different criteria for evaluating organisations and some of them would be the competitive capacity of customers, potential competitors, budget analysis that would give the valuation of a company, its financial stability and liquidity along with profitability. Enrique (2008) argues that similarly the design of organisation is constrained by the choice of multiplicity of criteria that cannot be assessed by cash flows. There are different theories that define organisation structures. Some of them are the contingency approach; transaction-cost theory; resource-based view; population ecologists; resource-dependence theory and agency-cost theory. Though there are a number of organisation theories there is no dominant paradigm that would have a purely scientific approach for the choice of appropriate organisational structure. By if all the theories are compatible and that each of the theory would address one criterion, then the choice would remain multi criteria (Cludts, 1999).

2.2.2. About Matrix Organisations

Kuprenas (2003) speaks of the concept of Matrix organisations, in the context of public sector organisations. In this concept, a number of horizontal project groups are created over the traditional vertical functional organisations. Chou (2008) points that in such organisations, employees would be working for a department where they would be drawing salaries and also for a project manager where they would be carrying out functional tasks. The team thus formed would be multidisciplinary project team. When the authority lines are drawn there would be a crossing of organisation lines that could be represented by matrix grids and thus the concept of Matrix Organisations has been created.

Espinosa (2007) notes that this form of organisation structure may be relatively lesser in large public organisations, in traditional firms such as automotive, steel manufacturing or even plastic and chemical industries. In such firms that can be called as manufacturing firms, the organisation is arranged around a process. However, with the introduction of the new age industries such as ICT, matrix organisations have been created with cross-functional teams. As an example, a firm such as Microsoft would become very complicated with a huge workforce if the departments were arranged as per the technologies. Therefore, the organisation is arranged into a matrix made of strategic business units that would cater to certain defined domains. Each SBU would again have a number of projects and project members drawn from a common employee base. Depending on the extent of work, the employee may be engaged in a single project or work on multiple projects simultaneously (Mumford, 2006).

Mashari (2001) points out that differentiated goals and values are common in all types of firms and there are several participation theories that consider this diversity. Therefore, participation should be deemed goal oriented and not merely task oriented. While all employees would not participate in the strategic decisions of the firm but they must have the chance to act in the shared value definition. Neumann (2007) says that all would probably achieve the amount of skill, competence and technical expertise required for this participation. Therefore, matrix organisation focuses on the individual excellence and gives them the opportunity to achieve higher objectives and goals.

Kuprenas (2003) again has indicated that there are a number of types of matrix organisations. Some of them are: functional, balanced and project. In a functional matrix, the employees that participate in the delivery process report to the functional manager. The project managers formally overlook the project for different functional areas. In this case, the project manager's authority on the functional staff is limited and so the project manager takes up planning and coordinating the staff. In this type of matrix, the functional manager would still have primary responsibility for specific project areas. In the balanced type of matrix, both the project and functional manager would be sharing the project resource responsibilities. In this matrix, the project managers would oversee the project and they would be interacting with the functional manager. Both would cooperate and approve the technical operational directives. In the project matrix, the functional managers have the smallest authority and they would assigning project resources and extend any technical consultation on a need basis. Project managers would oversee the whole project, take care of deliverables and be responsible for project completion.

2.2.3. Challenges for Matrix Organisations

Mumford (1995) reports that in theory, matrix organisations are expected to bring the best out of the project and functional managers increase the efficiency level and utilise the resources optimally. Weill (2004) says that it should be remembered that people do not like to share power and if they have to share power, then they want others to do the work. In addition, there are some social issues here since the matrix structure would be pitting the functional manager with the project manager. Usually in large organisations, the functional manager is the head of a process with good expertise in certain areas. It can be assumed that the functional manager would not take kindly to being placed in a secondary role to a project manager. Some of the challenges that are envisaged are: roles and responsibilities; reporting system; politicisation of projects and resources; need skills training and lack of project level focus (Nicolai, 2002).

2.2.4. Social Issues of SOA

Vinoski (2006) points that there have been instances of one in seven SOA implementations failing and the main reason for the failures was that the social aspects were not understood. It should be noted that services cannot work as standalone objects but they should be a part of a larger network. SOA success would depend on the fact that there are critical masses of services that are useful and are being used often. Trochim (2007) says that if a registry is provided, then services can advertise themselves and there are greater prospects of them being discovered. Dynamic discovery is more important. Maurizio (2008) notes that SOA adoption in many instances is not done voluntarily and developers and users suffer from this bias. People have been used to obtaining information or completing a certain task using a certain method. Now when the user is asked to suddenly change the methods and adopt a new service, there is a certain reluctance to do so.

Erickson (2008) says that there are some inherent barriers for SOA adoption. Some of them are getting the ‘buy-in' from the management; inherent reluctance and inertia of developers to take up changes as required; barriers from the upper management who would want justification in the bottom line for cost and return analysis; lack of proper communication and so on. SOA is not just technology but of merging systems and so ultimately, one manager would find that he would be reporting to another manager who until the other day was a colleague. Stemberger (2007) points out that this type of transformation would cause some element of frustration and resistance among workers who would attempt to erect punitive barriers and make the implementation very difficult.

2.2.5. Implications of Adopting SOA for NAV/NDU

NAV/NDU is a large public sector organisation with certain set practices and methods. SOA is designed to make an organisation to be lean and agile in its responses. There is a greater pressure on employees to perform and any failures cannot be hidden under the organisation mass. McAdam (1999) suggested that public sector organisations have rigid hierarchies with a rigid culture that relies on red tape and bureaucracy. Typically, there are multiple stakeholders for the processes and it is difficult to cross the boundaries. Bieberstein (2005) notes that Policy changes are frequently delayed by endless approvals and people have a reluctance to give up their power. While the current need is for large public firms to be more alert and responsive there is a certain amount of inertia that is difficult to overcome.

SOA is designed to change all these behaviour and social problems. However, SOA can only point out the means to increase efficiency. Public sector firms have a number of barriers. Among the problems and issues that were identified are: willingness to accept change; lack of empowerment of employees; poor internal communication; lack of matrix structures; lack of performance measurement outcomes and results; top management support and understanding and others (Sundberg, 2006).

The organisation structure of NAV/NDU-ICT-operations is illustrated below.

As per the information discussed in Chapter 1, ICT and computerisation has been in used in NAV/NDU since a number of years. However, the departments were silos of information and there was no proper integration. The organisation structure can be regarded as vertical with a mix with strong functional structures. SOA would be introducing a horizontal matrix structure where there would be cross functional teams. After the adoption of SOA in context of the pension reform, 2 new roles where defined. They are:

SOA-operations manager: This is a higher-level operations role functioning as head of the Value chain operations managers. In addition, a resource in respect to architectural discussion, new consumers/producers on SOA infrastructure, etc. The role has extended informal authority and may approve or reject infrastructure changes, releases, architectural changes, decide role back etc. and is the head of the teams that are assembled during major “go lives” and/or incidents. The teams are assembled, as needed by the SOA-operations manager thus the matrix structure. The SOA-operations manager sort formally under operational architecture à DB&MiddleWare but reports to the section manager and general manager for ICT operations as well.

Value chain operations managers: This is an operational role where the responsibilities are focused around major value chains leveraging SOA, such as the pension system and GOSYS. (Operations manager for the pension system and operations manager for GOSYS).

Stark (2000) notes that while implementing SOA would have technical issues, there are certain social issues such as sharing of power, disappearance of existing roles and emergence of new roles, perhaps redundancy of some roles and functions. Such an event would be expected to cause resistance among employees and efficiency of the organisation would come down. Smith (2007) points that there would also be a slowing down in the response and speed of the system simply because affected people are reluctant to act. With the system showing a degraded performance, the senior management would be forced to perhaps ask the IT team to roll back the changes and revert to the old system. This is a pessimistic view but it is known to happen (Davis, 2005).

It is suggested that a change management process should be initiated to control any untoward and ill will feelings that people may have about SOA.

2.2.6. SOA Governance

SOA Governance is the practice used by firms to ensure that all assets are utilised efficiently and add value to SOA implementation. Some types of assets include IT and business infrastructure, people and business processes. Governance implies that SOA principles have to be used effectively so that maximum benefits are obtained after integration. Investments made for SOA should provide appropriate long and short-term results. Some indicators that SOA governance has taken place effectively are through reduced costs and time for deployment of new applications; ease for end user use; faster assembly and coding of new services and so on. In auditing, there are other auditing requirements such as Sarbanes-Oxley act that must be satisfied. Since service producers and consumers are unknown entities, care should be taken to ensure that change management of services should not have unanticipated effects. When changes are planned, a thorough impact analysis has to be performed and there should be some facility to roll back the changes, if required. The roll back feature is not commendable but required when teams are new. The quality of service is very important since the process of verifying and proving newly added services are effective. It should be noted that service consumers and providers form a chain and if crucial links fails, then the system could crash (Peng, 2008).

Schwaninger (2006) says that other important activities in SOA governance include management of services portfolio. With proper management, new services can be properly planned and existing services can be modified and upgraded. Proper governance should ensure that when services are upgraded, existing links between providers and consumers are not disrupted. System wide rules and policies should be implemented that would control and monitor the behaviour of consumers and providers and that a consistent pattern is observed in the offerings. SOA governance also monitors the performance of services so that disruptions, downtime is controlled and that QoS is maintained as subpar performance can severely affect the system performance (Derler, 2006).

2.2.7. Gartner's Hype Cycle for SOA

The Gartner Hype Cycle for 2009 shows that SOA technology is on the rising ‘Slope of Enlightenment'. The years to mainstream adoption shows that it would take between 2 to 5 years for the technology to enter the mainstream applications. Until then, SOA is expected to have limited implementations and applications (Gartner, August 2009).

Organisations that take up new implementations can opt for SOA directly. Organisations such as NAV/NDU that wish to integrate their systems can adopt SOA as the architecture. Therefore as per the hype cycle, SOA can be expected to remain a viable and popular technology in the months to come. Hence, it is recommended that NAV/NDU can make the required investments in SOA.

2.2.9. Challenges and Drawbacks of SOA

Mahmood (2007) points out certain advantages, challenges and drawbacks for implementing SOA. These are briefly discussed as below:

Some of the advantages of SOA are:

* Increase agility and reduced response time for business

* Easy to create new applications and services to meet changing organisation needs.

* Chance to bring in continuous business process improvement.

* Easy support for new business channels and increased reuse of existing assets and applications.

* Ability to support and integrate multiple applications and modules in the networked environment.

* Ability to enforce uniform policies through the network

Some of the disadvantages and challenges of SOA are (Chen, 2008):

* SOA implementation may demand cultural changes, new roles, knowledge building and the manner in which reporting structures are organised. People may not be willing to accept such changes.

* Advantages and benefits may not be apparent immediately and a long-term commitment for the organisation is expected.

* Systems would become much more extensive and complex forcing extensive monitoring.

* It must be noted that one service can invoke another so each input parameter has to be validated fully. This may slow down the system and increase the load.

* A bug in a frequently used service would probably influence other services also, forcing system wide closure.

* Service metadata and messaging that can run into millions can be a problem.

* Granularity would be coarse so testing of each used case for services would be almost impossible.

* By having a loose coupling, binding of specific services to consumers would be impossible to control and this would lead to slowing down of system since each service request has to 'discover' a service.

* Integration is a good concept but in reality, integration of old legacy mainframe code to web based service is often a nightmare

* When web service is used for exchanging of SOAP messages over protocols such as HTTP, the integration of services, encapsulation of XML data being carried out in a heterogeneous environment becomes very difficult.

* Updating and upgrading services as per requests require skilled people with multi disciplinary skills. This may not always be available.

2.3. Chapter Summary

The chapter has examined in detail important organisational and technical concepts related to SOA. The following points form the summary of the chapter.

SOA is used in matrix types of organisations that have separate and independent departments with their own legacy IT systems. It was seen that over a period, these departments became information silos and there was no integration with systems of other departments. SOA can help to break down the communication barriers by configuring the legacy systems and their modules into services. With the appropriate network, it would be possible to have an integrated network of systems.

The SOA strategy and imperatives must be planned, discussed and documented and details such as current scenario and targeted outcomes must be specified. There is also a need to specify SOA metrics that would be used to measure the current and changed state. Transformation planning and deployment should be incremental since SOA is an iterative process. The process should first begin with extensive data collection and development should be done phase wise. Such an approach helps to observe and take feedback along with any corrective actions.

There is a need to first create a topology of different services that would reveal the business processes. There should be a common vocabulary of taxonomies so that there is a proper understanding of the hierarchies. With a common vocabulary, it is possible to manage different business areas and increase collaboration. Cross enterprise architecture is important as it removes boundaries between business partners and removes information silos. There is a need to have common interoperability standards by using standards such as WSDL and SOAP contracts.

Interoperability of applications must be developed to form many to many loose coupling web services. Such an arrangement helps to resolve problems related to versioning of services. There should be established directives and policies for reuse, governance, risk management, compliance, versioning and security. Security and integrity of services is very important and multiple approaches for ensuring security at the service level are important. There should be a facility to conduct audit trails of all transactions as and well required. It should be clearly defined if services are run for a user or a user role and this makes user identification management and authentication critical. Security must be enforced through strict security policies at the transportation and the messaging level.

There are certain social issues that have to be considered for implementing SOA. There should be a change in the mindset and think differently since the traditional deployment methods are not suited for SOA. Issues such as boundary, operational and functional scope has to be rethought. Since there would be a paradigm shift in the transformation, there is a need to manage issues related to strategic, cultural and other tactical issues related to the transformation. There is a need to address issues related to cross business and domain transformations since the firm would be dealing with resources across the organisation. There is a need to make cultural adjustment and not just the business processes.

3. Methodology

The term Methodology refers to the approach taken for the research process, from the theoretical framework, hypothesis to gathering and analysing of data. The term method refers to the various means by which data can be collected and analysed. The methodological assumption is concerned with the process of the research, from the theoretical underpinning to the collection and analysis of the data (Silverman, 2001). Please refer to Appendix ‘A1. Details of Methodology Used' for a discussion on the methodology used in this paper.

4. Organisational Science - Permanent Matrix Structures

Mumford (1995) had written about the socio technical design, a new approach for organisation design. According to the author, there has to be an equal weight to social aspects as well as technical issues when a new system is designed. This summation is very important in the case of NAV/NDU where SOA is being brought in.

4.1. Understanding the requirement at NAV/NDU

As per the NAV/NDU internal documents, SOA adoption was established in 2006 and the main driver was the pension system that was developed. The new pension system was to be created on SOA and from then onwards; SOA was to be the preferred platform. After the initial rollout, the responsibility for operations, maintenance, was to be a part of the ICT operations. ICT operations is organised as a traditional hierarchy in the organisation. As the impact of SOA on ICT operations was unclear at the time, NAV/NDU chose an emergent approach to prepare for SOA adoption. Two new roles where defined: SOA-operations manager and Operations manager for the pension system.

There were some other changes and existing WAS administrators where redefined as SOA administrators and given additional responsibilities. These roles had an open and not very well defined description and none of the roles have personnel or budget authority. The roles have to rely on interpersonal relations with those who have personnel and budget authority to be able to put together cross-functional teams. As these roles are permanent, these structures leave SOA-operations with the permanent matrix structure. A number of areas have proven to be of a more SOA specific permanent nature. Some of them are: Monitoring, Deployment, Incident management, Change management and Operational research. These areas and roles may justify personnel and budget authority to the SOA-operations manager. Within a short time, it became clear that the SOA team was understaffed both in respect to labour and knowledge in SOA operations. This was addressed by hiring external consultants. The consultants (have aided NAV/NDU for the last two and half years.

Therefore, this chapter and the next, attempts to find out how different structures have been used in other public sector firms and how the nature of roles has been handled.

4.2. New and Emerging Organisation Structures

Since the past few years, organisations are changing from hierarchies to networks and from a centralised to decentralised structures with some departments being run as strategic business units - SBUs. In the case study of Digital Equipment Corporation at Boston, the units have their own budget and recruitment authority and they often are profit centres with revenue generation capacity. In this case, it was found that the network structure lead to duplication of resources, improper competition among different units and therefore the conventional hierarchical structure was adopted. The firm had an issue of managing the new organisational structures; as such, forms were not clearly understood. Neither the HR department nor the managers had worked in such an environment before and there were issues over many things. Some of the issues were as to who undertook critical decisions; how was performance evaluated; if complexity could be managed through freedom; if cooperation and using inter personal relations to get work done is ethical since it would be regarded as a favour and so on (Mumford, 1995). There is a marked resemblance between the case of Digital Equipment Corporation and that of NAV/NDU.

There are also structures of the wired world where people who do not know each other work together in an online mode. People in the wired world would be working as individuals and not as members of teams and there would be little job stability, not much of a loyalty towards the firm and systems of social support and protection will have to be created. There are suggestions that the medieval structure of guilds and freemasons would be formed again in the wired world. However, these are esoteric structures and not very relevant in the NAV/NDU case. Only cause of concern is that with SOA, there is decentralisation at the work front but employees are still bound to their department. Therefore, new systems of work contracts are required along with the required support systems (March, 2001).

Hannan (1986) has written about organisational changes or upheavals where there are major changes in the organisation structure are more often social and political changes rather than just technical. This is especially true in public sector firms that have long and deep-rooted hierarchies and any changes in the structure would create a discontinuity. Davis (2005) has been critical about the new organisation structures that seem to create disparate entities out of employees. Kuehn (2006) likens the employees to loose ‘lumps of butter that float in a pail of non-cooperation where clannish behaviour and false loyalties are formed. Lehaney (2004) argues that the new organisation structures would expect the loyalty a consumer feels for the grocer from where he buys his groceries.

Kauffmann (1995) argues that a closer examination of the theories of Weber and Perrow would indicate that the theories of organisation science were formed considering MNC organisation structures that were rigid and stable. Hence, we had theories such as inducement and contribution theory, problematic search, transaction cost economics and others. These theories operated under the belief that organisation structures were not changing and process could be modified within the boundaries of these structures. Any change that was brought in was limited to the technical aspects only. This was truer in case of public sector firms such as NAV/NDU. As seen in ‘Section 4.1' with the introduction of SOA, the old world rigid structures are being replaced. Initially, only a few roles are being redefined and new roles are being created. These roles are being forced to comply with the old structures since they do not have budget and recruitment authority, thus putting them under stress and frustration. The new job realities require that a new flexible structure should be created that is independent of the old structures. However, that is not happening with ICT-operations. Any changes that are being done are cosmetic (Beynon, 2005).

4.3. Creation and implementation of Matrix Organisations

The purely functional structure, the product structure and the traditional hierarchy structure become redundant when dealing with projects within an organisation. If in an existing organisation or even in a department, separate mini project is introduced that would require some if not all the personnel to be involved, then matrix management is the best. It would be argued in this section that matrix structure and management would perhaps be the best method for ICT-operations at NAV/NDU.

Galbraith (2008) has presented his research into matrix structures as adopted by firms such as P&G and IBM. Matrix structures in these firms have been widely studied and adopted by other firms across the firms and the lessons learned here would help the NAV/NDU case that is being researched here. According to the author, matrix structures were initially used in the early 1960's by the US aerospace industry. After the matrix structures and their processes were publicised, these practices were quickly and improperly copied and wrongly implemented in many organisations of those times. The resulting failures pushed the matrix structures to the background until firms such as P&G, IBM, Microsoft and the Indian IT industry reviewed them. It is expected that NAV/NDUwill not fall into the same trap as the early failures.

Cardinal (2008) notes that the main advantages that firms must attempt to leverage is the skills and knowledge sharing and the next is that specialisation can be increased bringing more depth, experience and knowledge to the worker. Firms also have to watch out and see that the employee does not become a servant to too many masters; employees are not over utilised and there should not be any attempt to create conflicting loyalties. In addition, since the concept of shared human resources is important, the actual employee requirement and recruitment needs would remain a mystery. Since employees would be expected to work on multiple projects, a set of benchmarks have to be defined that would be used to measure the work (Galbraith, 2008).

In NAV/NDU case, the issues are if the matrix structure should be made applicable to only the SOA-operations team and again to only some members of the SOA-operations team or to the whole department and even the organisation. With hundreds of employees, an unplanned matrix structure would result in total chaos with no one knowing who their boss is and whom to approach in case of problems. The matrix structure should not be regarded as an opportunity to shirk work but rather for individuals to grow and increase their knowledge base.

Galbraith, (2008) has explored a number of matrix structures that are available and these include The Star Model, Two-Dimensional Structures, Two-Hat Model, Baton Pass Model, Consumer Goods Model and The Matrix Within a Matrix. Gupta (2003) speaks of the Three-Dimensional Matrix with various sub types such as: Geography-Dominant Matrix, Balanced Matrix, Business-Dominant Matrix, Differentiated Structures, Global Account Teams, The Front-Back Hybrid Model and a few other complex structures. An illustration of some sample matrix forms are as given below.

Borges (2004) comments that in the initial stages, functional organisation structures were the norm and these followed the mechanical school. The goal was to optimise resource allocation, take up work specialisation and cost reduction. The strategy used was to compete through efficiency in manufacturing and service delivery. According to Carter (2007), when business became more challenging with a number of new variables emerged and there was a need to create new and complex organisation structures to manage customers, geography and products. Cartwright (2006) comments that thus, brand managers, brand and product managers and other such new roles emerged. Business imperatives required that the roles had to be efficient in a minimum of two dimensions and thus the matrix structure was crated (Galbraith, 2008).

It would be seen from ‘Section 4.1.' that at NAV/NDU, some attempt has been done to introduce the matrix structures. This has been affected by creating the roles of SOA-operations manager and Operations manager for the pension system along with other new areas. However, the effectiveness and power of the new roles are not yet allotted.

4.3.1. Examples of Matrix Structures

The P&G matrix with three dimensions is regarded as a complex structure. The three dimensions around which the structure was organised are the regions; global function and global R&D function and the global product categories. After first understanding the matrix and how it functions at P&G, an attempt would be made to map it with the functions of NAV/NDU. As seen in the , the three-dimensional organisation chart has the profit and loss responsibility s represented by the solid lines. The cross regional coordination members are represented by the dotted lines and represent the influence on the decision making process that is formed by the functional senior vice presidents and the presidents. The structure of the matrix organisation allowed the top and bottom line enhancements and improvements to be done (Degen, 2009). Cotton (2008) suggests that with the formation of global functions, pooling of knowledge, standardisation of activities, best practices transfer was brought in, inefficiency, and redundancy was removed. With the creation of a one-product type supply function that managed the global supply chain, the manufacturing and distribution facilities were consolidated.

In the P&G case, the strong regional and global functions that were supposed to extend large benefits appeared to form an imbalance in the matrix structure to the loss of the country and product category managers. It was not the intention to create a balance in the matrix and the intent was to create a market dominant or product category dominant matrix. P&G unwittingly created a type of internal conflict where reporting structures were the issues. The relation between the functional managers and the country product managers was interdependent. The country product managers had a high amount of de facto control on the country functional managers as the career prospects, raises, promotions were dependant and controlled. The function managers would try to optimise their regional control along with regional managers who were singly responsible for the financial performance. There were also conflicts between the leadership of product category and the country managers who were not ready to bring in initiatives to improve the short-term results. Thus, a number of unresolved conflicts were created and it was difficult to make regional profit centres to take the responsibility for financial results. Each dimension was attempting to optimise its own parameters and there was not attempt or trade off to optimise the overall performance of P&G. This incredible situation caused P&G revenues growth to drop from 8.5% in 1980 to 1.4% in 1987. P&G then announced a six year restructuring plan called ‘Organisation 2005' to unravel the mess that was created by the wrong implementation of matrix structure (Degen, 2009).

The problems that were identified were manifold. P&G had business managers who were trained in the best B schools of the world, were class competition and individual excellence was encouraged. There was very little concept of team play and so managers assumed that everyone else in the firm were the competition. Edleman (2002) comments that the matrix structure allowed the managers to continue the mayhem and power struggle until they succeeded individually but P&G as an organisation failed. Total victory in any one of the dimensions at the cost of the other only destroys the balance, ultimately the matrix, and the organisation.

Time Warner - TW also brought in a matrix structure for its unit. TW serves as a holding company with a conglomerate structure. TW has a number of independent businesses and the corporate centre of the holding company has only a few corporate functions. As seen, these functions have a relation with other entities and the relation is identified by a dotted line. So in this case also there would be two bosses for an employee, the line boss who gives the operational direction and the performance reviews. The functional boss controls and guides the career development and functional direction. Saunders (2006) argues that such an arrangement has been known to cause severe problems for the lower level employees since they are tied up between two bosses who may have a different agenda. With skilled resources hard to find, the operational level employees are often overloaded and this can increase their dissatisfaction

4.4. Chapter Summary

The following strong points have emerged from the analysis.

* At NAV/NDU the management has to realise that power struggles between dimensions cannot be wished away as there are deep-rooted sociological motives present. A change management initiative that would change the culture of the people is required. Matrix leaders should be made capable and worthy adversaries and they have to turn conflicts into constructive uses. Win-lose situations are to be avoided and a win-win situation is the best solution. Leaders should always have the perspective of the whole organisation in their mind and people who do not comply may have to be removed.

* There is a need to reduced excessive burden on employees at the operational level. Hiring additional staff can reduce such problems. However, getting skilled employees is difficult and these people should be ready to occupy the new roles with very little functional training.

* There is a need for a central office, like the project management office. Managers of the SOA-operations teams could indent the required budget and work force.

5. Organisational issues while adopting SOA

Sundberg (2006) had reported about a case study involving a Swedish Insurance company where changes had to be implemented in the organisation structures using eBusiness. In Sweden, the National Insurance Board and the social insurance offices together administer the social insurance schemes and they take the responsibility of Sweden's society financial safety cover. These two entities are identified as the social administration. Please refer to the following .

Donaldson (1991) noted that the IT department of the board maintains the development of the IT systems used by the national social insurance system. A need was felt to bring in business process reengineering practices into the system so that the public sector would have increased effectiveness from the restructuring. Accordingly, a detailed survey of 16 participants, made up of software developers and the management was taken. The government had contracted the Swedish Agency for Public Management called the Statskontoret to highlight and promote public agencies that would provide e services. The intention was to provide e-government services and its introduction requires a major change if the business process. Turner (2008) says that public sector firms face a different scenario when compared to the private sector, publicly elected bodies control them and these firms have a number of objectives. These bodies also face a large number of demands from the consumer and they have to operate with reduced budgets and restrictions. In such cases, there is a tremendous amount of culture change required and the rigid hierarchal structures would in effect serve to oppose the change for flatter and looser structures. In some cases, the authority would be shared among different stakeholders and the process would go beyond the framework of the department (Cherns, 2006).

Espejo (1989) says that a number of issues and problems during implementation have emerged. The most difficult problems that were anticipated occurred in managing cross-functional boundaries and deciding whether to bring in radical or incremental change. The other issues were in dismantling certain dominant processes without clearly understanding their importance. There was also a need to change the collaborative culture. Birrell (2004) notes that merely by changing from a functional unit to a process unit would not create an instantaneous sense of culture and responsibility among the employees. Van (2007) has was observed that when claims of integrating the core processes were made, only a few fundamental changes were made while power still resided with the older vertical silos. Such an approach would not help the new structures. It was also realised that while removing a role or modifying a process, it is important to first perform an impact analysis that would ascertain how each stakeholder is impacted (Adler, 2002).

This case is important for NAV/NDU since it dealt with the public sector organisation from the Scandinavian country Sweden. Many of the issues that the firm faced would occur for NAV/NDU. Some of the areas to watch out while moving to SOA are the issue of process standardisation.

5.1. Critical success factors for SOA Implementation from BPR Failures

There is not sufficient literature to determine the critical success factors for SOA implementation. However, there is ample research on the implementation of BPR activity across different organisations in the public sector. Coulson (2007) notes there is some level of similarity since both deal with modifying and upgrading processes; there is a move towards changing systems and the promise of bringing in new structures. Hotle (2004) notes that, BPR was not regarded as very successful after 70% of the implementations failed and these failures were mainly due to wrong requirement analysis. Therefore, a case can be made between SOA and BPR implementations and the failures of BPR can be considered as learning's for SOA (Espinosa, 2005).

McAdam (1999) studied 45 cases of BPR implementations in UK public sector firms. There are a number of issues with relevance for SOA implementation. Some of the factors are rigid hierarchies; culture and multiple stakeholders for different work processes and whose boundaries cannot be crossed. Other factors include: changes in policy direction can be sudden and dramatic; there can be an overlap of initiatives such as market testing; wide scope of activities and unrealistic expectations and there are instances of either overstaff or lesser number of staff. The following critical success factors have emerged.

It is interesting to note that the level of importance with the highest points is Top management understanding of BPR and Maintenance of job security. There are other issues in public sector firms and these have larger political interference. Sudden changes in the public sector policy can occur at any point of time and these would negatively affect the implementation and functioning of SOA. Knorr (2005) suggests that one of the main fallouts would be role change and while role changes are expected to be for the better of the firm, policy changes due to pressure may not allow this to actually happen. In such a case, the whole effort of restructuring would be undone or would be done in patches and this is not acceptable. Hyde (2005) notes that employee empowerment is important and the involvement of staff, external teams and consultants is essential. It would be observed that complex processes in firms would have certain specialist areas. Gil (2005) argues that to properly model the workflow and ensure that all phases and steps are documented; staff should be empowered to speak and take decisions. McCollum (2003) comments that it is expected that in later stages, there would be decisions to be taken on retaining or eliminating some process and by co-relation, roles. In such instances, it helps the implementation process if the employee is aware of this fact and better still if he sees where he fits in the new process layout (McAdam, 1999).

Katzner (2005) says that the question of change management and then if radical or incremental changes have to be considered. Keeping in mind that NAV/NDU is a public sector organisation, change management with widespread reorganising or job cuts would be difficult to resolve. For SOA to have a higher success rate, a proper change management approach is essential. Gobeli (1986) argues that emotional and employees can research psychological factors of change management with greater maturity than a rash and blunt communication approach. Malone (2004) notes that the question of radical and incremental change is best answered by the nature of change planned and the preceding and succeeding steps in a process. A radical change that expects a start over with a clean sheet may be relevant in some cases where there is no need to follow the old process (Johns, 2009).

5.2. SOA and Business Process Change

Indihar (2007) has written about how business process is changed when SOA is implemented. To help public sector firm understand the changes that are brought about during radical changes such as SOA, ERP and EAI integration exercises, a BPC - business process change initiative has to be performed that allows a strategy to be defined. Rollier (1979) says that the strategy would try to leverage a competitive advantage by effecting changes in the relations between information, management, people, processes, technology and organisational structure. According to the author, for SOA to be acceptable and successful as a business tool and not just as a technology, it must fit in with the organisation strategy and other initiatives that have been running for some time. Singh (2005) notes that the organisation would have initiated other practices such as TQM and even BPM and these would be the primary strategy of the firm to meet market requirements. SOA in such a case must not demand a separate agenda or ask that the firm's objectives be changed. This very important issue has to be considered. Any advantages or purported benefits would not be of any use unless the new initiative is in line with what the organisation wants (Saran, 2006).

5.3. Chapter Summary

The following points have emerged.

* It is essential that before taking up any radical changes, processes must be improved and made better. Appointing new people, giving them real authority and budgets could do this.

* Understand process ownership, tracking old process in the new system and making people accountable along with giving them power is important.

6. Discussions

The paper has analysed and discussed important aspects of SOA, Matrix organisations and how the implementation of SOA would impact wide ranging social aspects of NAV/NDU. In this chapter, a discussion of the findings from all chapters is presented and these would be later consolidated and presented as conclusions and recommendations in Chapter 7.

6.1. Issues revealed about Matrix Structures and the Social aspects

The move to SOA seems to be much more complicated and it is not restricted to only technical issues such as migrations of application, buying software, making changes in the hardware, etc. The issues that have emerged cover social issues such as cross-functional boundaries, shared power structures and new structures, erosion of old systems and emergence of new systems. There is also the strong possibility of struggles and clashes and dual reporting for lower level of functional employees. Employees in many organisations have grown to be like gladiators and they are interested only in winning. Worst, for many, winning is equated with defeat of the ‘enemy' in this case, other colleagues against whom they would presumably be pitted against to achieve success.

Such incidents have occurred in other organisations and they have been discussed at length. A similar situation would occur at NAV/NDU and since this is a public sector firm with the important tasks of pension management, utmost care and caution has to be taken. It is obvious that there are multiple forces at work and the management should not take sides or adopt a ‘let the best man win' attitude. In all probability, the older managers who have vast social networks in the firm would emerge the winner and they would in fact ‘kill' the SOA project. The SOA project is not about winning a feud but rather about integrating and consolidating the efforts to bring in more efficiency.

If NAV/NDU had been already exposed to an ERP implementation cycle, then some of the issues would have already been experienced. A certain ‘cleaning up' of the system would have occurred and many of the issues related to old processes and power structures would have been resolved. Since the organisation has many traditional aspects and also the customers are senior people, the duty of the SOA professionals would be to make the switch over smooth and not abrupt or callous. People should not be left wondering about where the system has disappeared and how they would perform their jobs, etc. Rather, SOA should have a clear road map that explains the phased manner in which things would change. When people have sufficient time to get used to something, it is always better and they can prepare themselves for the worst. There is also the possibility of job losses, as many of the tasks would be turned to automated services. In such cases, the reaction to SOA would be vitriolic and opposition would be harsh. SOA functional teams or the SOA manager should not attempt to get involved or should be expected to do the firing. The job is best left to HRM or other related departments.

It is important that the moral and social fabric of the firm should not be changed for the worse with SOA implementation. The organisation has a wide customer base and it enjoys a reputation as a helpful social welfare organisation. In this context, SOA has to carry the burden of maintaining the relations with the customers. This would be in the form of services and external interfaces that would be accessed by the customer. Customer would be accessing information using a website. Now with SOA as the architecture, the experience for users should be much more encouraging.

An important aspect that has emerged is the amount of free hand and leeway that the SOA functional managers can expect from the traditional power structures and managers. At a base level, one would be acting against the other. Therefore, how much of cooperation would the SOA manager expect from the existing traditional power structures. It is not possible to immediately dismantle the traditional power structures since SOA is yet to be fully implemented and the testing, proving, user acceptance still is months or even years away. Considering these disturbing apparitions, the management should consider giving some level of autonomy and authority for the SOA managers. The authority could extend to drafting their own budgets, appointing their own teams and taking other decisions. There would be some caps on the spending and the normal channels of audit and approvals would be followed.

It would also become evident that SOA professionals that are appointed would have to be very gifted and talented as there is no room for mistakes. Typically core IT developers, programmers, technical solution architects, requirement and functional analysts and others would be hired. Such people would have a requirement for a higher salary than that paid to other people from the traditional systems. This is bound to cause a lot of dissatisfaction among the staff but they have to live with this wage difference.

Once SOA is implemented, to keep the services running smoothly and without any issues, the reaction time, approach to problem solving and decision-making has to be fast. Very often, decisions would have to be taken in the late evening when senior staff has gone home. Having a long-winded decision making system that requires a chain of approvals and counter verifications would be a barrier. Decision-making should be given to the employees who would be given training on possible scenarios and the possible ways to apply solutions. Formal authority to the SOA-operations manager may help in achieving this.

6.1. Suggested Matrix Structure

The following matrix structure is proposed to NAV/NDU.

SOA-operations are proposed to be a separate section under the department of ICT operations. By creating SOA-operations as a separate section, it would be conferred with budgeting responsibilities and have the means to recruit employees, make allocations for budget, decide on the team structure and have a certain level of independence. SOA-operations would be headed by an SOA-operations manager who would be in charge of the overall SOA-operations at NAV/NDU. It is recommended that the SOA manager forms a team as per the requirements at NAV/NDU. Typical teams would consist of analysts, technical SMEs, solution architects, testers and so on. The core human capital would be permanently based in the SOA-operations section and could be utilised as needed thus reducing conflicts introduced by matrix structures. Defining a SOA-operations section would further legitimate the SOA-adoption efforts and establish an adequate partner for the integration center in the Systems and project division that will handle development once PP is phased out.

It is further suggested that two offices are established, ESB-operations and middleware. ESB-operations would be responsible for ESB-operation. The ESB is by far the most crucial and complex component in NAV/NDUs SOA infrastructure and the office would be staffed with technical SMEs. While the utilised middleware technology would be handled by the middleware team.

Then there would be the cross-functional teams who would be assembled from different sections and departments of the organisation. These teams would together with the SMEs and value chain operations managers be able to offer a CERT-function to NAV/NDU.

7. Conclusion and Recommendation

The paper has examined how SOA has been implemented in different public sector and commercial organisations across the world. A very thorough case study approach along with focussed literature review has been used to understand how SOA implementation would impact NAV/NDU. In this chapter, some conclusions have been drawn from the study and a set of recommendations has been made specifically for NAV/NDU.

7.1. Conclusions from the Study

Conclusions drawn from the study are:

* SOA life cycle and its impact on the organisation are not just restricted to technical aspects but cover the social structures and the organisational culture of the firm. Therefore, while making an assessment of how SOA would impact the organisation, it is not sufficient to consider only technical aspects.

* It is expected that the change demanded in the social structure would be more severe than mere technical changes. A proper change management process must be initiated.

* When a traditional organisation structure is made to undergo a makeover to a matrix organisation structure a number of old and accepted power centres and lines of hierarchies would be disrupted. The new lines of work that would be formed would have to co-exist along with the old structures. The relation between the two entities cannot be expected to be cordial.

* When new power structures are formed, they would tend to be more work oriented and would be tasked with carrying out recommendations and work details. Typically, the people in this group called the SOA specialists would be specialists and time is a premium for them.

* It is expected that these specialists would be assuming multiple roles and performing many, more duties and tasks than a person from the traditional structures would be willing to do. The organisation should be willing to pay them much higher wages and perks than other employees.

* There would be some clashes in the perceived importance and relevance between the old traditional structures and new matrix organisational structure.

* In light of the above points, the new matrix structure should be vested with sufficient authority and should have budgetary authority to take any decision regarding the working of the new groups.

* It is expected that the SOA implementation would have two sets of employees and the management. One set is the elite SOA administrators and implementers who would be technical and process specialists. The other set of employees are the ones who would be carrying out the new defined routine tasks after SOA is implemented. The management would have to play a facilitator role and mediate between various power groups and provide proper conditions.

* The latter employees would experience frustration. These employees would be operative level or middle management employees and they would be migrated to a new work culture that would require different levels of punctualities and adherence to work rules. SOA has a lot of promise and it may deliver the promised benefits. However it is a hard task to master and employees are expected to assume new rules and responsibilities much beyond what the traditional job definition expected from them.

* SOA is not a process improvement tool or methodology. Existing processes have to be understood fully to find the different workflows and interaction nodes, stakeholders and actors. If there is any inefficiency, then the same should be removed before SOA is implemented. Creating services for inefficient processes and methods would not serve any purpose, lead to waste and wrong use of resources.

* When a service is created, a proper change impact study must be performed to asses areas that would be directly or indirectly impacted, roles that would be eliminated or modified and new roles that would emerge. To make the transition to SOA less traumatic and smoother, HR managers and senior staff should conduct meetings and open house sessions and be ready to address any issues that may arise. Depending on the organisation policies, some jobs would become obsolete and employees may be let go or offered retraining and alternative positions. The firm must consider these issues and prepare accordingly.

7.2. Recommendations for NAV/NDU

SOA adoption related recommendations in ICT-operations:

* Staffing: SOA adoption benefits are in business and development. However, in ICT-operations the impact of SOA adds severe complexity and need for more resources. The new resources would be specialists and technical experts and people well versed in change management methods.

* Change management: An effort should be taken to counsel all affected efforts and prepare them for change management counselling. At the same time, people who are not impacted should also be made aware of what is going on.

* Location: the added complexity suggests that the SOA team should be located together in open landscape. Currently the SOA team is scattered throughout the buildings. They should be brought together in one location and preferably under a dedicated section. A dedicated and independent section is required since a dedicated section would have budgetary authority and take care of staffing, recruitment and other needs. With a dedicated SOA-operations section, it is expected that some of the problems would be done away with.

* Mandate: The SOA-operations manager should be heading the new section, thus having personnel and budget authority over the SOA-operations team. Operations manager for the pension system should have responsibilities for the pension value chain and act as glue between the functional department and operations. Further value chains should have an operations manager pointed out as they migrate towards SOA. The value chain operations managers should report to the SOA-operations manager in a form of staff function.

* Resource requirements: There must be an understanding of the resource requirements for SOA-operations in senior management. A full buy in and senior management presence is essential for the initiative to be successful. A person from the top management should be made to assume a visible role and mentor the initiative.

* Role descriptions: There is a need to thoroughly define different roles, new roles and existing roles that would emerge from the new matrix organisation. There should ideally be a role mapping and each role in the chain should be listed along with details such as reporting, work profile and what is expected from the role. A dedicated ITIL approach could facilitate this.

7.3. Concluding Remarks

The move by NAV/NDU to take up SOA and the willingness to adopt matrix type of organisational structure is brave and commendable. It would impose efficiency on the system and the PP may be seen as the pilot project that would be adopted by NAVs future development projects. The potential for improving the system is huge and the prospects for knowledge advancement are huge for NAV/NDU. However NAV/NDU should exercise caution and avoid the pitfalls described in literature for projects of this nature. There are plenty of examples on companies not providing proper conditions for such initiatives and suffering greatly for it.

A.1. Details of Methodology Used
A.1.1.1. Qualitative and Quantitative Research

Studies that use data cover areas of economic study, unemployment, health of the economy, scientific study, patterns of demography and others. Different type of data is collected using methods such as databases, reliable government studies, secondary research published in peer reviewed journals, experiments, observations, interviews and others. Data that is collected can be designated into two basic categories, quantitative and qualitative. This also formulates what type of research a study will be conducting: quantitative or qualitative. Denzin (2000) described quantitative research as “the research which gathers data that is measurable in some way and which is usually analyzed statistically”. This type of data is mainly concerned with how much there is of something, how fast things are done, and so on. The data collected in this instance is always in the form of numbers. In order to obtain quantitative data, one should have a specific framework about what has to be researched, what should be known, types of inputs that are admissible and so on. Such an approach can help in designing the questionnaire, make observations and so on. Denzin also defined qualitative research as “the research that gathers data that provides a detailed description of whatever is being researched”. Both types of research have their supporters and detractors and while some claim that quantitative research is much more scientific, others argue that qualitative research is required to examine a specific issue in depth.

Researchers who support that quantitative research argue that numerical data can be statistically analysed and in this way, it can be established whether it is valid, reliable and whether it can be generalised. By using numerical data, these numbers can be used to compare between other studies, which also use the same numbers, the same scales, etc. With qualitative research, it is not so easily possible to achieve this result, as no specific method or scale of measurement is kept. This is the main disadvantage of qualitative research, as findings cannot be generalised to larger populations with a large degree of certainty and validity. The reason that this happens is because their findings are not tested and evaluated statistically in order to establish whether they are due to chance or whether they are statistically significant and to what extent. Another advantage of quantitative to qualitative research is that qualitative research is descriptive and many times subjective too, as it depends on the researcher's perspective or how the research registers certain behaviours. Another researcher conducting the same study may observe the qualitative data, which is given in a completely different way. Quantitative research does not show this disadvantage as all the data is in the form of numbers and, therefore, it may be translated in only one possible way, that which is given from the objective value of each specific number. However, qualitative research has many advantages to offer too, which are not offered through quantitative research. It is usually through such type of research that a rich, in-depth insight can be given into an individual or a group, by being far more detailed and by recognising the uniqueness of each individual. This type of research realises the importance of the subjective feelings of those who are studied (Denzin, 2000).

Qualitative research analysis does not have to fall into the pitfall of being ‘forced' to have all its values into certain numerical categories. It is clear that not all phenomena can always be adequately assigned a numerical value, and when this does happen, they lose much of their naturalistic reality (Rice, 1953). Qualitative research can simply describe a data for what it actually is without having to assign it to a number. Qualitative research can give attention to occurrences, which are not so common. For example, it is very difficult to find enough participants to conduct statistical correlations between nations on women being more accident prone and indulging in rash driving because women will not be willing to be used for such studies. In such cases, quantitative research is impossible and it is only through qualitative research that such cases can be examined in depth and conclude to specific findings and results (Byrne, 2002).

A.1.1.2. Case Study Approach

Yin (1989) regards a case study in much the same way that the natural scientist regards a laboratory experiment. According to the author, the case study approach is an umbrella term for a family of research methods having in common the decision to focus on an enquiry around a specific instance or event. More formally, a case study may be defined as an empirical enquiry that "investigates a contemporary phenomenon within its real life context, when the boundaries between phenomenon and context are not clearly evident, and in which multiple sources of evidences are used. In a case study, the researcher examines features on many people or units, at one time or across times. It uses analytical logic instead of numerical statistical testing.

The researcher will select one or a few key cases to illustrate an issue and study them in detail. It is the aim of the case study to provide a multi-dimensional picture of the situation and it can illustrate the relationships, corporate political issues and patterns of influence in particular contexts. The researcher can do so by using combined sources of data collection such as archives, interviews, questionnaires and observations. However, based on this research strategy a researcher is an observer and a large number of variables are involved with little or no control. Outcomes deriving from a case study can be either qualitative, quantitative or both.

A1.1.3. Data Gathering

Gathering data is a very important phase and due consideration must be given for the period of the research.

Sample Selection

The sample to be researched largely determines the data collection method that is used. Surveys are better suited when used to obtain information from participants, while focus groups would require a different method since the groups are diverse. The sample size would also depend on the project requirements and the group that has to be studied. While considering large number of subjects is best since the results are more reliable, the costs of studying such large samples increase. If the project has sufficient budget allocations, then it is possible to include larger samples and members in the study (Byrne, 2002).

Cost Considerations

Cost is an important aspect for research projects and choosing the method for data collection depends on the budget. For tasks such as running observations, program and project document review can be achieved with lesser costs, but tasks such as the design of the survey instruments, administering the instrument to subjects and analysing the results would need the help of an external evaluator (Byrne, 2002).

Sample Size

The sample size used in research has always created disagreements and controversies. Various issues such as ethical issues and statistical problems arise and these need to be addressed properly. When very large sample data sizes are used, the ethical issue of wasting resources will arise, while selecting a smaller size will create another ethical issue. When the research objective is large, then a difference that is statistically significant may be observed even with a smaller sample. However, the difference that is statistically significant may happen when a smaller sample size has been used and such differences do emerge and when there is actually no difference (Freiman, 1970).


Questionnaires produce quantitative information about the social world and describe features of people or the social world (Neumann, 2007). They are also used to explain or explore about people's beliefs, opinions, characteristics, and past or present behaviour. The survey is the most widely used data gathering technique in sociology, and it's used in many other fields as well such as communication, education, economics, political science, and social psychology. The survey approach is often called correlation. Survey researchers sample many respondents who answer the same questions. They measure many variables, test multiple hypotheses, and infer temporal order from questions about past behaviour, experiences, or characteristics. The association among variables is then measured with statistical techniques. Survey techniques are often used in descriptive or explanatory research. This study has used the survey method to obtain data.

A.1.1.4. Research Paradigm and Method

Typically, the research design, methodology and approach are driven by the research question being scrutinised. Galliers (1991) infers that depending on the field or research there may be several research approaches and methods that are considered appropriate; this is a view, which is also shared by Vitalari (1985). The research paradigm will influence the selection of an appropriate research method and approach by the researcher. They could choose either qualitative or quantitative research, in some cases, as stated by Orlikowski, (1991) mixed method procedures which incorporate both elements of qualitative and quantitative research are obtaining a level of validity within academia where it has aspired to a level of legitimacy within the social and human sciences. Orlikowski (1991) identify that there are three paradigms evident in Information Systems research, which are, the: Positivist paradigm; Interpretivist paradigm and Critical theory paradigm.

The ‘Positivist Paradigm Positivism', as stated in Neumann (2007), sees social sciences as "Organized method for combining deductive logic with precise empirical observations of individual behaviour in order to discover and confirm a set of probabilistic causal laws that can be used to predict general patterns of human activity". Interpretivism, as defined by Neumann (2007) is the "systematic analysis-of socially meaningful action through the direct detailed observation of people in natural settings in order to arrive at understandings and interpretations of how people create and maintain their social worlds". Critical theory is derived from the works of Marx, Freud, Marcuse and Habermas (Neumann, 2007). Critical theorists disagree with what is viewed as the anti-humanist and conservative values of positivism and the passive subjectivism of Interpretivism. Critical theorists go beyond seeking understanding of an existing reality and critically evaluate the social reality being studied in order to implement improvements to it.

A. 2. Technical Aspects of SOA

The subject of SOA is steeped in technology and a good understanding of the basic technical requirements is required for the thesis. Galliers (1991) argues that in SOA, the functionality of systems group is arranged around the organisations business processes and these are categorised as services. These services are interoperable and available on demand. When the applications are arranged around SOA, these services speak with each other and allow the required business processes to be run by exchanging data. The services are linked together loosely with the programming languages and the operating systems. Lämmer (2008) says that the functions are segregated into discrete services and with SOA, the services can be accessed through the common backbone of the network.

The most important features are that the services can be remotely placed, in different departments or even organisations. The services can be reused as required, combined with other services to create separate business applications and most important, they help to integrate information and systems of different departments. IT personnel and other employees would go from one system to another, take copies of the required data and then feed into other systems manually. Lu (2008) points out that this was a colossal waste of resources and the data was never live, thus denying planners to reduce the inventories and improve throughput time. Firms have been trying to solve this problem by using EDI formats that were web enabled. Initially systems such as EDI were used to give provide some amount of integration, but since EDI is rigid and has its own formats, success was limited. SOA on the other hand is flexible and has a standard architecture that supports the connectivity requirements and allows data to be shared among various applications. The following shows the SOA foundation reference model.

Mulik (2008) says that typically, large applications are usually made of a number of smaller services and modules. Users can access these modules as per their requirements. Integrating the services can also create new applications. Orlikowski (1991) notes that once data is entered at one point into the system for a service, then there is no need to enter the same data multiple times. As an example, a customer profile is created by assigning an ID, entering the name and contact details. With SOA in place, such information can be entered only once in the customer master and other modules of the application would access the customer details when the customer ID is entered. Such a system would be used while opening savings, IRA or current account. Throughout the systems, the interfaces and UI elements would be the same and thus users would have the same look and feel.

A.2.1. Business Case and Strategic Advantages and of adopting SOA

Mulik (2008) notes that SOA is becoming more popular with IT professionals worldwide. Adopting SOA is not a one-time activity like installing an application but a roadmap for the firm over a long time. It is more of an architectural pattern where system modules are loosely coupled with each other in a network through their interfaces. They deliver the required functionality. The pattern can be used for the single system architecture such as the insurance claims management system or at the enterprise level architecture system of a large organisation. The services that are interlinked can be anything type such as web services, Jini or Corba services and so on. However, web services are the best technology to realise SOA advantages.

Since SOA principles are loosely coupled, the systems are maintainable and adaptable, however, loosely coupled modules have a lower performance than tight-coupled modules. Loosely coupled modules would have higher hardware costs than the tightly coupled modules. By adopting SOA, the flexibility in design in increased and information can be easily modified using SOA. However, it should be noted that switching to SOA requires some foresight and planning and a roadmap of the destination. Modules and applications that are required and the ones that should be keep aside should be identified and segregated. If possible, small upgrades, migration and removal of dirty data should be taken before converting the modules to web services. By using a structured methodology, it is possible to have higher benefits at lower costs. There are typically four destinations that the systems manager can choose from and they are: foundation for business process management; composite applications; service-oriented integration and reusable business services (Mulik, 2008).

Reusable Business Services

Firms would have systems that made up the supply core data and this may refer to the product data, customer data and so on. When new systems are to be developed, there have to be interaction among the systems that are tightly coupled. If any changes are made n the core systems, then there would be changes in other systems that are fed by the core system. The change could cause more problems if the systems are more tightly coupled and in such cases, it is a neat solution when services from systems that give the core data are exposed. As an example, a service that gives employee information would have operations such as searchEmployeeByLastName, getPersonalDetails or getContactDetails can serve as a single source for employee related data. Designing the interface of such services means taking into account the fact that there are multiple users who would be needed for different tasks and these may be required for future integration. Firms have to connect some part of the internal systems with other networks and business partners by using the Internet. Having different mechanisms for each partner can be a problem and become complex to maintain. Rather, firms design interfaces of generic services such as Accord or Onix and these follow the industry standards, are secure, easily maintainable at both ends, affordable and reusable. The reusability of business services becomes useful when some applications and functionality are developed using legacy technology. Such applications can be wrapped up as services rather than coding them from the start. These services can be used by mobile devices, smart clients and by portals (Mulik, 2008).

Service-Oriented Integration

Internal application integration is a challenge that IT managers face since there would be multiple and heterogeneous platforms for the applications. FTP is the common method use in organisations as the mechanism for integration. Since 2000 when vendors such as SeeBeyond, Tibco, webMethods, and other offer a number of EAI tools - enterprise application integration. These tools can connect packaged and custom applications in an enterprise using a single hub or bus to satisfy the integration needs. However, since the tools are proprietary, switching from one vendor to another becomes a problem and expensive. This problem is met by using the enterpriser service bus, which is a software infrastructure tool. This tool helps for content based routing, messaging and XML based data transformation for integration of services. Following shows how the ESB is used (Mulik, 2008).

Some firms use SOE or the service-orchestration engines for integration in addition to ESB. Such tools are used for visualising the business process execution and in the orchestration of services. The speed of response for reacting to the business change is much faster as the business change is translated into a business process change. The language used in this case is BPEL or Business Process Execution Language and many types of service orchestration engines support it. It is also possible to switch to a different SOE. When ESB and BPEL are integrated, then the processes are based on service oriented integration (Mulik, 2008).

Composite Applications

If some components are not properly structured, then they cannot be used and hence there would duplication functionalities in the application. Duplication can be reduced by reviewing the existing systems to decide how they can be developed for the reusable business services. While isolated business applications can be developed, new applications can be built by reusing the existing services and then taking up the remaining functionality. Composite applications can be dynamic or static. Static ones are created by writing new code and these would then connect to existing services. Dynamic applications are created using BPEL engines that have a GUI to orchestrate the services. New applications can be created by orchestrating existing services and the new services. The orchestration can be exposed as a service and make the service composition to be multilevel. Loose coupling is required in the case of such composite applications. Thus, there would be flexibility in helping users to access more and more applications (Mulik, 2008).

Foundation for BPM

The tasks involved in BPM would include improvement of business process performance, measurement, monitoring and modelling of business processes. With digitisation of business processes, BPM can be initiated with software tools such as Savvion. Since these tools are proprietary, they would create tight coupling issues. In such cases, SOA can be adopted and the BPM infrastructure can be built over this so that the service layer and foundation can be used. Following shows the four options compared. Issues such as upfront investment forms the X axis while flexibility forms the Y axis.

As seen in the above , the reusable business services approach has the lowest flexibility and also the least up-front investment. Organisation should define it as the first stop and show the business benefits of investing in and adopting SOA. A balance can be struck between flexibility and the upfront investment (Mulik, 2008).

A.2.2. Layers in SOA

SOA can be visualised as having a number of layers and stacks with a number of components. Following shows the functional layers in the SOA architecture.

As seen in the above , the SOA would be made up of a number of functional layers. The lowermost layer is the operational systems and included here are the IT assets that would be used in the SOA. There would also be packaged applications, OO apps along with custom applications. The service component layer comes next and it is integrated with the application layer and its components. When users access the applications, they would be doing so through the services layer. The service atomic and composite layer comes next and it specifies the services that are made available in the system. At the operational level are the business processes and these are used to implement the orchestration of business processes as services. The uppermost layer is the consumer layer and it refers to the channels that would be using the applications, business processes and the services. In addition, there are also some non functional layers, placed on the adjacent sides. Another layer is the integration layer that gives the system the capability for transporting the service requests, routing and mediating them as per the requests that are raised by the consumer for the specific provided. The Quality of Service is important as it initiates the requirements for the reliability and availability of the service. The information architecture can also support business intelligence, metadata and other forms of data. Governance foe the system is used for enhancing the capacity for supporting the lifecycle management of the SOA (Portier, 2007).

A.2.3. Service-Oriented Modelling Framework

Lu (2008) points out that SOA uses the Service-Oriented Modelling Framework - SOMF to solve problems of reuse and interoperability. SOMF is used to simplify the business rules and helps developers to understand different environments by using modelling practices. SOMF also is used to identify different disciplines in SOA and developers can analyse, visualise the assets, and create the architecture. It is a type of map of work structure and spells out the key elements used in the identification of required tasks for service development. The modelling system allows developers to develop a project plan to set the different milestones of the service-oriented initiative. Please refer to the following that illustrates the SOMF layout.

As seen in the above , SOMF offers a modelling language or a notation for modelling. This notation covers the main requirements by integrating IT services and business processes. SOMF also offers the life cycle methodology that can be used for service oriented development. There are a number of modelling practices that help to create a life cycle management model. There are entities such as the modelling discipline and the modelling artefacts and these make up the modelling environment. The environments provided are the conceptual environment, analysis environment and the logical environment. These are subsets of the abstraction practice and the realisation practice. Modelling solutions include the solution service and the solution architecture. A number of best practices have emerged and these include the business transparency, architecture best practices and trace ability, asset reuse and consolidation, virtually, loose coupling, interoperability and the modularity and componentisation (Ribeiro, 2008).

A.2.4. Integrate SOA with BPC and TQM

There are six steps in the strategy and these steps are designed to integrate SOA, BPC. TQM and other initiatives. The steps are (Kurtz, 2003):

Envision: In this stage, the management commitment and vision is established. A review would be done for the SOA implementation strategy and see how it fits in the overall organisation objectives. There would also be an effort at identifying the key business process that would be defined as services and taken up.

Initiate: In this stage, the project goals are set along with project planning tasks, organising teams and so on.

Diagnose: In this stage, the processes are analysed and broken into sub processes. They would also be modelled as per different techniques. It is also possible to use quantitative analysis such as simulation analysis, activity based costing and so on. By using sophisticated techniques, it would be able to predict with certainty how the process would perform. Any inefficiencies and drawbacks are noted accordingly (Tatum, 2008).

Redesign: In this stage the new process id developed that has been redesigned and various alternative processes are also defined by using brainstorming and creativity techniques.

Reconstruct: In this stage, the new process flows that would be due when SOA is implemented are created. Effects of various other initiatives are also studied

Evaluate: The last stage include evaluating the profess performance and to verify if the goals and targets are met with.

The accuracy with which modelling is done helps to reduce the negative impacts of SOA implementation. It is true that social impacts and feelings of employees would not be possible to model. However, the impact that one set of changes has on the overall organisation is important (Mason, 1981).

A.2.5. Interactions in SOA

As an example consider a tourist operator who does car reservation for customers as per their request. The operator reserves an automobile after getting instructions from the airline operator for a customer who is online. If there were no SOA, then the tourist operator would have to take the requests from the airline operator, enter manually the information in its own system, and then send the confirmation manually. With SOA the problem is removed and the customer would send the request directly using the Internet. The request would be routed through the airline operators system that would be running on Oracle and to the small tour-operator system that would be using a Windows based application. Therefore, SOA has provided the required framework that would help to design with the goal to create a quick and low cost system development environment (Peng, 2008).

There are different entities such as users, SaaS, DaaS and PaaS and these refer to the services that the user would interact with. However, there are some challenges when using SOA for real time applications since there is the problem of handling the response time, asynchronous parallel applications, providing support for event driven routines, ensuring reliability and availability of the applications and so on (Peng, 2008).

A.3.1. Elements of SOA

SOA can be visualised as a collection of different services that would exchange data, interact, and communicate with each other. The interactions would be based in request handling for transfer of data and then ensuring that two or more services would run in a synchronised manner. Services are built by using different software applications. The services may have some independent functionality units that would operate as standalone units and would not have any call function that are embedded in them and which would allow them to communicate. Some types of services provided as ticket booking, online form, online shopping with credit cards and so on (Chou, 2008). An SOA system would have some elements as shown in the following .

As seen in the above , the lowest layer is the business logic and data. In addition there are the layers of the application front end, the service and service repository and the service. All these entities are enclosed in the SOA framework. These services would not have any code to call other applications since the calls for hard coding would create a problem as millions of code snippet would have to be written for every instance of tasks. Therefore, protocols that are structured and defined are used for specifying the manner in which these services can interact. The architecture would then use some business processes to form the links for sequence and services in which the calls are done. This process is also called Orchestration (Chou, 2008).

A.3.2. Web Services

Lammer (2008) notes that a web service is a software system that is used to support the machine to machine communication over the Internet or the Intranet. It is also called as a service that is a 'discoverable resource' and which can be used to run a repeated tasks. It is described by an external service specification. Web services are web API that could be accessed from a network and made to run on another system that has a need for the services. The services are applications that are run using web services.

There are different concepts that are used to quantify the meaning of services. Business alignment services are created on the business needs and not on the IT expertise of a firm. Specification services are used for describing the semantics, dynamic behaviour, policies, interfaces and the service quality and they are self contained. Reusability services have a reusability feature while agreement services are agreements and contracts that are created between the service providers and consumers. Hosting and discoverability services would have items such as metadata, repositories and registries. These are hosted by the service provider while the service consumer discovers them. Aggregation is the composite applications that are created by loosely coupled services. Internet is the main method used for connection and http is the main protocol and thus web service has come into common use (Erickson, 2008).

IBM has a very large market share, almost 80% and it has introduced a number of products such as Websphere Process servers, Websphere application servers, Websphere DataPower++ and the IBM Tivoli monitoring portfolio to establish monitoring capabilities for SOA. Some web services application suites that are used to create web services are iWay Data Integration Solutions, Actional, BEA AquaLogic, iBOLT Integration Suite, webMethods Product Suite, ReadiMinds WebServices Applications Suite, Novell exteNd Composer, Sonic ESB and many more. A good tool used that can be used for web services desktop integration is Ratchet-X. Some of the tools that are used for development of web services are AttachmateWRQ Verastream, Redberri, OrindaBuild, Altova MissionKit for XML Developers, soapui, FusionWare Integration Server and many more (Erickson, 2008).

A.3.3. Web Services Description Language

WSDL - Web Services Description Language is used to describe interfaces of web service. It describes the services that are offered and how binding of these services to the network address is done. It has three components: definitions, operations and service bindings. Following shows how these components are related (Chen, 2008).

XML is used to specify definition and there are two types, data type and message type. Message definition is done by using data type definitions. Operations are used to describe the actions requested by the message on the web services. There are four types of operations, one way, Request and response, Solicit response and notification. Operations can be grouped into port types that are used to define a set of operations for web services support. In addition, service bindings are used for connection of ports that are specified by attaching the network address to a part. Different ports together would form a service and they are bound in turn by using SOAP. Some other technologies that can also be used include WebSphere MQ, .NET, DCOM, Corba, Java Message Service and many more (Chen, 2008).

A.3.4. Application Servers and Databases

Application server is placed in the middle tier of the architecture. The server is component based and is used to create the middleware services used for persistence, state maintenance, security and data access. There are different types of application servers and these are based on various languages, Java app server for Java 2 platform, J2EE server for multi tier distributed model and so on. Typically there are three tiers such as middle tier, EIS and client (Enrique, 2008). Please refer to the following .

App servers are used when the existing databases and systems need to be integrated and there is a requirement for website support. The servers are also used in e Commerce and web integrated collaboration and reuse of component.

A.3.5. Orchestration

The process of Orchestration refers to the method where complex computer systems, assets and components such as middleware and services are arranged. The process also refers to how these assets are managed and how they coordinate and communicate with each other. Some commercial orchestration packages available are NetBeans Enterprise Pack, ActiveVOS, Intervoice Media Exchange, Apache Orchestration Director Engine, Microsoft BizTalk Server, TIBCO BusinessWorks, Oracle BPEL Process Manager and many more. The process is needed when creating the SOA framework as it forms a layer for business solutions. Information flows that start from different systems are used and a control is formed that gives a point of control for different services. The orchestration engine is used to change the business functions as needed. Following illustrates the arrangement (Fragidis, 2008).