A Business Model for Managing SOA Initiatives

To obtain business benefits from a SOA implementation, it is not sufficient managing technical features. A strategy aligned to business should base activities for services implementation, validation, development and management. A business case, a reference model and organization architecture should be established. This paper specifies the goals, organizational roles and business process models for managing SOA initiatives. The processes were evaluated by SOA experts who argue they would adopt them in their organizations. Resumo. Para obter os benefícios corporativos com a implantação de uma abordagem SOA, não é suficiente tratar características técnicas. Uma estratégia alinhada ao negócio deve ser considerada como base para as atividades de implementação, validação, desenvolvimento e gestão de serviços. Um caso de negócio, um modelo de referência e uma arquitetura da organização devem ser estabelecidos. Este trabalho propõe objetivos, papéis e processos para governança SOA do ponto de vista da Arquitetura de Tecnologia de Informação. Os processos foram avaliados por especialistas na área de SOA que argumentam que adotariam os mesmos para a governança SOA em suas organizações.


Introduction
According to Deler and Weinreich (2006), many studies in SOA focus on creation and use of technologies for Web Services development.However, the adoption of such specifications (e.g., WSDL (WSDL, 2008), UDDI (UDDI, 2008), WS-* (Erl, 2005), SOAP (SOAP, 2008) and related activities (e.g., service creation, validation, implementation and management) do not suffice to obtain the expected benefits of a SOA initiative from business perspective.Specifications and development activities are not enough to ensure consistent corporation's dynamism according to SOA principles.This is a technical view with low adherence to business goals.The definition of a SOA strategy helps to focus SOA efforts, to clarify its expected results and to identify appropriate uses for services so as to foster business benefits.Establish a business case, define a reference model and build/update the enterprise architecture models.All previous tasks are addressed by defining and systematically adopting management procedures specifically focused on SOA environments.However, the deployment of an adequate SOA governance approach still faces several challenges, such as how to encapsulate business activities into services, how to manage service changes, the establishment of new responsibilities and architecture roles, how to define and use metrics to measure achieved results, and how to establish and implement policies and standards (Schepers et al., 2008;Kajko-Mattsson et al., 2007).
SOA Governance is the definition, implementation and subsequent enforcement of a decision model and a structure of responsibilities which ensure that an organization pursues a SOA strategy and that all SOA initiatives walk together to meet the organization requirements (Marks, 2008;Weblayers, 2005).SOA strategy must be aligned to business objectives.SOA governance has to ensure the implementation of this strategy in accordance with principles and policies, through committees or work groups, governance processes, checkpoints, reviews and tools and technologies.SOA governance includes the deployment of a SOA initiative according to business processes, technology standards and business priorities.Finally, SOA governance explicitly involves stakeholders from business and IT in the decision-making process related to SOA (Marks, 2008).On the other hand, Enterprise Architecture is defined as the organizing logic for business processes, data, and technology (Ross, 2011).This requires defining a SOA governance approach aligned to the Enterprise Architecture.
This paper specifies the goals, organizational roles and business process models for managing SOA initiatives, thus encompassing the "why", "who" and "how" perspectives that should be addressed when leading such a scenario.Our proposed set of models specifies the motivation, management procedures and responsibilities for a SOA initiative in an organization, and may be considered as part of a SOA Governance approach.
The remaining of this paper is structured as follows.Section 2 presents the related work.Sections 3 and 4 detail the organizational roles and business process models for managing a SOA initiative.Section 4 describes a qualitative evaluation of the proposal.Section 5 presents the conclusions and future work.
2. Related Work Niemann et al. (2010) propose a generic SOA governance model whose main elements are: SOA goals, SOA as enterprise architecture and governance control cycle.SOA goals are derived from global IT goals and correspond to specialized business goals.These goals are: SOA compliance (adherence to internal, technical and legal regulations); alignment between business and IT (integration and adoption of IT processes in the business environment is crucial to the success of SOA), and long-term reliable operation (resulting from the management of SOA).SOA as enterprise architecture consists of processes such as production, operation and maintenance of services, beyond the technical view including registers and enterprise service bus.The SOA governance control cycle is the central part that implements and operates effective governance.The cycle represents crucial processes, including and involving organizational entities (roles and responsibilities and governance processes), governance policies, catalog of best practices, compliance observation and enforcement techniques, and a component for measuring SOA maturity.Niemann et al. (2010) also investigated and compared approaches to SOA governance proposed by academia and industry.The following concepts of governance that were considered in these proposals were identified: impact on the organization, SOA maturity model, new roles and responsibilities, best practices, metric models, impact on people's behavior, SOA life cycle, SOA roadmap, policies catalog, services lifecycle, governance processes, policy enforcement mechanisms.The concepts presented by Niemanm et al. (2010) are generic and difficult to follow in practice.However, they address key aspects of SOA governance.Our proposal does not cover the SOA maturity model and best practices.On the other hand, our work discusses the concepts relevant to the application of SOA governance, and the level of detail allows its practical application.Schepers et al. (2008) define SOA governance life cycle as composed by the following processes: define SOA strategy; align the organization; manage services portfolio; manage services life cycle; manage SOA policies and manage service development.The authors point out SOA issues, such as: tracking of IT systems and services to ensure compliance with standards and legislation; creation of budget according to the property and service costs; impact analysis of services maintenance; quality assurance in service design and implementation; change of team behavior for adopting SOA in the organization.Brown et al. (2006) mention the impact of SOA governance in SOA life cycle defined in four stages: modeling, assembling, deployment and control.The authors argue that SOA governance life cycle is distinct of governed service life cycle.This SOA governance life cycle is characterized as a process comprising four phases:  Planning: Understanding the structure of governance and the current environment; creating a starting point for IT governance; defining the scope of the governance model; driving change;  Definition: Defining and refining governance processes, quality and decision making processes; defining organizational changes; defining IT changes in deployment of SOA processes;  Permission: implementing the transition plan; initiating organizational changes; implementing SOA infrastructure;  Measurement: measuring the effectiveness of governance process; measuring the effectiveness of organizational changes; reviewing and refining development and operational environments.Marks and Bell (2006) present a high-level model divided in iterative cycles where, periodically, the business is analyzed and the business strategies feedback are used in the iterative cycles:  Business iteration: discovery and analysis of business to be considered in SOA strategy and planning;  SOA strategy iteration: planning and analysis of SOA strategy;  SOA project iteration: implementation of SOA initiatives and projects in accordance with the same strategy and SOA governance model;  Service iteration: service update and improvement.
Regarding the related work, this work presents the proposed processes at a higher level of detail; explicitly defines roles responsible for carrying out activities; and presents the activities designed in business processes models in order to facilitate conducting related tasks by the participants of the SOA initiative.
3. The "Why", "Who" and "How" to manage SOA initiatives This work specifies the goals that should be followed when establishing a SOA initiative ("why"), a set of organizational roles ("who") comprising the responsibilities required for conducting and guiding a SOA initiative in an organization, and a set of business processes ("how") that should be executed for this purpose.The presented models comprise ideas proposed in the works of Botto (2004), Spewak and Hill (1992), Kajko-Mattsson et al. (2007), Niemann (2010) and Schepers et al. (2008).First insights towards these models were presented in our previous work (Azevedo et al., 2010a), and some of them were summarized by Diirr et al. (2014).In the present work, all processes and complementary models are presented in detail.

Why should SOA management initiative be established
Establishing the goals to be pursued when establishing any organizational initiative is a crucial starting point, since these goals will serve as a common basis to guide, justify and control all the efforts.We propose a set of goals that should guide a SOA initiative, represented in the diagram of Figure 1.A direct link from, e.g., goal g1 to goal g2 in the diagram represents that the "more specific" goal g1 contributes for achieving the "more general" goal g2.SOA Applications Analyst ensures all customer needs are fulfilled by the portfolio of available services.S/He understands customer requirements, defines service interfaces, and defines integration with existing applications.SOA Analyst models the organizational business processes, mapping business needs to existing or new services.SOA Architect ensures technical requirements of SOA initiative environment are fulfilled, so that there is no technical restriction for reaching the business needs mapped by SOA Analyst.SOA Developer develops and publishes services.Finally, SOA Manager maintains and governs SOA-based systems in a higher-level perspective; that is, s/he ensures business needs are met on a strategic, tactical and operational level.

How a SOA management initiative should be conducted: defining SOA management processes
We propose a set of business processes that should be regularly executed to manage a SOA initiative in any organization.To increase the quality of the representation of our proposed business processes from a cognitive viewpoint, the processes are described both graphically and textually.This follows the "dual coding" principle defined by Moody (2009), which suggests the combined use of graphics and text to increase the cognitive effectiveness of a conceptual model.Moreover, business process diagrams presented in this section follow the eEPC notation (Scheer, 2000;Sharp and McDermott, 2001), a widely-used business process modeling notation.
In the eEPC notation, high level macro-processes are represented as VAC (Value-added chain) diagrams, processes in a lower abstraction level are represented as EPC (Event-Driven Process Chains) diagrams or as function trees diagrams.VAC corresponds to abstract descriptions (macro-process) of organization's functions that influence directly the added value of organization business (Aris, 2006).EPCs show a dynamic view, detailing the process flows and how they are supported by the business infrastructure (Davis and Brabander, 2007).Thus, the EPCs were used in processes whose activities have defined sequences.Function trees show a static view of functions, illustrating how a function is detailed in sub-functions without regard to the processes' flows (Davis and Brabander, 2007).We use function trees to design activities whose execution sequence is not known or varies in each organization.More details about eEPC notation are presented in Appendix 1.
In a nutshell, managing a SOA initiative may be represented as a macro-process illustrated in the VAC diagram of Figure 3. Manage Service-Oriented Architecture macroprocess is decomposed into six sub-processes for: building the current and future environment for SOA support; maintenance of support environment; definition of policies and standards; prospection of technologies; and, monitoring SOA activities.These processes are detailed as follows.Build an Environment for SOA Support process documents the current organizational environment, comprising all existing services, systems that consume services, databases accessed by services, and service infrastructure.Activities comprised by this process are presented in the Functional Diagram of Figure 4, and described as follows.
 Survey the standards currently used: Identify standards currently used for service development, e.g., standards for service implementation, service orchestration, service portfolio;  Survey existing services: Identify and document existing services.This activity is responsible also to identify redundancy;  Survey existing infrastructure: Identify existing infrastructure, such as, Enterprise Service Bus, service registry, tools used for service modeling, implementation and orchestration, servers used for backup and service provision.
 Map services with the existing infrastructure: Map services to infrastructure used for provision, monitoring, backup, clustering etc.;  Map existing services and applications: Map applications which consume services, reporting problems, difficulties and facilities in service consumption;  Map services and databases: Map databases accessed by services, and corresponding CRUD (Create, Retrieve, Update and Delete) operations performed by services. Define SOA strategy: This process is responsible to create the strategy for SOA initiative implementation.It defines SOA initiative's funding procedures, which human resources will work and the objectives and goals.Metrics are defined to measure achieved results.Marks (2008) presents that SOA strategies are close to organizations' requirements, e.g., agility, responsiveness to market needs, software maintenance and integration cost reduction, increase capacity of partnership, increase software/service reuse etc.The following statements summarize fitness principles of SOA strategy and an organization: o Business alignment: the strategy should map business and IT requirements to support business goals; o Focus on clear business needs: the strategy should address business needs, and it should have support of decision makers; o Reachable roadmap: the strategy should define a roadmap whose results are clear to reach or a list of areas where SOA and services could solve current problems, add value and produce great impact; o Business case definition: a business case with high added value should be defined to apply SOA.
 Define scope: This process is responsible to define the scope of SOA initiative implementation defining priority business areas and process, identifying output products, and out of scope products.
o A gap analysis should be performed in order to analyze the difference between organization current situation and desired future situation.This analysis should produce a report about the differences between current and future situation.
o A roadmap should be created to define activities to be pursued to implement the new architecture.The roadmap should also define projects to be conducted in the defined scope.
 Establish project groups: This process is responsible to establish SOA initiative teams according to the areas prioritized in the defined SOA strategy.
 Assign responsibilities to project groups: This process is responsible to define which tasks each working group should execute, and working groups relationships;  Define control unit: This process defines the organization unit responsible for monitoring the implementation and maintaining the initiative;  Assign roles to stakeholders: This process is responsible to define stakeholders responsibilities;  Maintain Environment for SOA Support macro-process is presented in Figure 6.It is responsible for developing and maintaining available services according to business requirements, while tracking changes and motivations that triggered each change (e.g., new requirement or evolution of an existing one, new business rule or change in an existing one, an error reported by user).Furthermore, the infrastructure used in SOA environment is also maintained.This macro-process is composed by five sub-processes, which are detailed as follows.
Maintain This process is responsible for maintaining the strategy used by organization SOA initiative, performing changes in funding policy, human resources, and goals to be achieved by the initiative.In addition, maintenance should be evaluated through indicators to measure the results achieved by SOA.

Maintain scope
This process evolves SOA initiative scope, updating projects' information, including new projects, setting new priorities, updating difference analysis reports (GAP Analysis) and roadmaps.

Maintain project groups and responsibilities
This process is responsible for performing required maintenance in project groups and defining their responsibilities according to the results obtained and necessary developments.

Maintain control unit
This process is responsible for evolving the SOA control unit towards decentralization.In SOA, one central control team is initially set, but the goal is decentralization (Josuttis, 2007).
 Maintain infrastructure: This process maintains the SOA environment infrastructure, including tools, user access profiles, and resolution of problems in the computing environment.Table 2 describes these activities.This process is responsible for managing SOA environment tools licenses and their distribution to users.

Manage access permissions
This process is responsible for managing user access permissions to service repository, metadata repositories and services (for service invocation).

Create user manuals
This process is responsible for creating SOA environment tools manuals to support users of such tools.

Advertise manuals for users
This process is responsible for releasing and advertising SOA environment manuals.

Ensure the functioning of tooling
This process is responsible for ensuring the operation of SOA environment tools, preventing network outages and malfunctioning servers.

Manage tooling updates
This process is responsible for managing updates of SOA environment tools, keeping them updated and applying security patches and bug fixes.

Manage contracts with suppliers
This process is responsible for managing contracts with tool suppliers, dealing with the legal procedures required for their subscription, renewal and cancellation.

Provide support on tooling
This process is responsible for providing support to users of SOA tools to solve doubts about problems encountered during tool use.
 Maintain services portfolio: This process evaluates and maintains portfolio structure changes, service discovery ways and service documentations.It also evaluates the Service Level Agreements established between service consumers and providers.Table 3 describes these activities.This process is responsible for ensuring the documentation of the registered services in the service repository is clear enough for potential users.For this, it is necessary to verify if all required information is correctly described and if it addresses the standards previously established.

Control service version
This process is responsible for controlling services versions available in the portfolio.It ensures the version of each service is available to users and the users are aware of the need to migrate their applications in order to stop using a deprecate service version.Furthermore, in the right time, it must ensure that deprecate service versions are no longer used and available in the service portfolio.Advertising services This process is responsible for advertising new services available in the portfolio to potential users.It also aims to ensure that similar services are not created, encouraging developers to use services already available fostering service reuse.Assess service SLA This process is responsible for assessing SLA (Service Level Agreement) established between service consumers and providers.It assures the consumers are compliant with the contract, and whether the services are being provided in accordance with what was agreed.From the evaluation of provided services, if the contract is not being met by service providers, improvements in services are defined (for example, performance improvements, clustering services, changes in the granularity of services etc.)  Build services: This process is responsible to build new services and maintain existing services using a service development life cycle (as proposed by Gu and Lago (2007)).It includes activities such as identify services (e.g., using the method proposed by Azevedo et al. (2009) or the method proposed by Leopold and Mendling (2012) which identify services from business process models), analysis services (e.g., using the methods proposed by Azevedo et al. (2011aAzevedo et al. ( , 2013) ) that takes as input the services identified from business processes models, and using information from these models to execute a set of heuristic for service analysis), design and implement services (e.g., using the approach proposed by Diirr et al. (2012) which presents steps to design and implement services using UML diagrams and Java technology), test services (e.g., using proposals described by Canfora and Di Penta (2009) which presents a report of results obtained in services test area, in addition of approaches of unit test, integration test, non-functional test and regression test), publish services (e.g., using the approach proposed by Arnold et al. (2007) to gather models and tools, models-based standards using formal methods that represent deployment topologies), provide services (e.g., using the SPML protocol (Oasis, 2006) proposed by OASIS and on which different data models can be used to define the actual provisioning data), monitor services (e.g., using a module for service monitoring at the Enterprise Service Bus (ESB) as proposed by Bluenke and Warda (2008) -ESB is the core technology in SOA (Hewitt, 2009) -or using the extensible monitoring model from the perspective of others proposed by Qi et al. (2010)) and withdraw services no longer in use (as characterized by Josuttis (2007) who points the withdrawal of services as the last phase of the service development life cycle); Figure 6 describes this process.

Figure 6 -Build Service
 Consume services: This process corresponds to the steps performed by service consumers to discover and invoke services.If there is no service that fulfills consumer requirement, then the consumer request service development.On the other hand, if there is a service that executes the requirement considering some adjustment, the consumer request for service maintenance.If a service composition is required, the consumer orchestrates services.The consumer also has to negotiate service contract, invoke service, test application and monitor service execution.The process is illustrated in Figure 7. Define policies and standards for SOA process is presented in Figure 8, and it comprises setting policies and standards for SOA environment, including its creation, maintenance, disclosure and audit.The process is decomposed into four sub-processes that are detailed as follows.
Define policies and standards for SOA Create policies and standards for SOA Maintain policies and standards for SOA Divulge policies and standards for SOA Control policies and standards for SOA

Figure8. Define policies and standards for SOA
 Create policies and standards for SOA: This process (Figure 9) analyzes characteristics to be standardized, sets and validates policies and standards.The process starts due to a need for standardization of some task or item of SOA environment is identified.Then, the item or task is analyzed, and policies and standards are defined and approved.If policies and standards are not approved, they are redefined and reassessed.The process is finished when policies and standards are approved;

Processes evaluation
In order to evaluate the proposed processes, the Delphi technique was used (Helmer, 1966).This technique is a systematic and iterative estimation based on the experience of independent experts.These experts must be carefully selected to answer a questionnaire based on their experience.According to Rowe (2001), "Expert opinion is often necessary in forecasting tasks because of the lack of appropriate available information or using statistical procedures."In the case of this research, we used estimation because, since the processes are not yet implemented in a real environment, its applicability and reliability can only be inferred based on the experience of such professionals.A detailed view of the Delphi technique can be obtained from Rowe (1999) and Green et al. (2007).
We selected five expert professionals in SOA to participate in the evaluation.Due to the reduced number of participants, we focused on a qualitative analysis by conducting an interview with each participant.Our objective was to evaluate whether the processes are applicable in a real environment by checking some aspects, such as, understandability, compliance of the processes in relation to current practices, usefulness of the processes, degree of difficulty to deploy the processes, favorability to the adoption of processes, and strengths and weakness observed in the processes.The professionals have together performed several of the roles that were defined in Figure 1.Moreover, each participant played each role for at least one year in his/her institution.Two of the respondents have already played the role of a SOA Manager.Three of them have played SOA Architect role.Three of them played SOA Analyst role.One of them has been a SOA Developer.Moreover, one of the respondents is a researcher who published papers in SOA different subjects.All of them have been working for organizations with more than five thousand employees, in which SOA organizational initiatives are being (or have recently been) carried out.
During the interview, the proposed processes were presented to the participants before they answered the questionnaire.Participants pointed out some difficulties observed during the deployment of SOA in the organizations they work, which are directly related to the management activities.The difficulties are: obtain executive support, change team culture of development and train staff, management teams (e.g., define the responsibility of each team and each person in the initiative), define the technologies to be used, define security policies, manage data exchanged between services, manage services repository, define funding model (e.g., share costs of services between different projects that use them).Moreover, participants stressed the importance of the following components: management support for implementation of the initiative; definition of tools to be used; management of data exchanged by services; adherence to defined standards; management of service repositories; and, use of indicators and metrics to monitor activities.
Currently, participants are carrying out the following activities in SOA initiatives: modeling, design, development and publication of services, definition of management processes, definition of standards, and control the development, quality and publication of services.Some quality aspects of the proposed processes were asked to participants.Regarding understandability, the following question was done: "The proposed processes are easy to understand?" and, for each process, the possible answers to this question were "very easy", "easy", "medium", "difficult" and "very difficult.Five participants considered the processes are easy to understanding.Participants emphasized that some aspects that make the understanding ease are simplicity of process design and the fact process are presented in a high level of details designed in business processes models.These observations confirm what was presented in the related work section.
Then, participants were asked about the compliance of the processes in relation to current practices of SOA initiatives in the organizations where they work.The question asked to them was: "Are the proposed processes in accordance with the processes used by the organization you work within a SOA initiative?" and, to answer it, participants had to classify each process in "nonconforming", "little conforming" and "conforming".Some non-conformity and little conformity responses were presented and the reasons given by participants for these results were:  "Prospect technologies for SOA" process is not specific to SOA, but rather a standard process established in the organization to prospect any technology.Furthermore, there are cases in which the prospection of technologies for SOA did not occur.It happens, for example, when the organization has already previous contract to acquire software from a specific vendor;  Unlike what is proposed in process "Build future environment for SOA support", SOA initiatives have emerged in the organization on an ad-hoc manner and a general plan of the important aspects of its implementation was not carried out;  In relation to the processes "Define policies and standards for SOA" and "Monitor SOA activities," the respondents indicated that few (or no) activities are performed for monitoring activities and define policies within the organizations they work.As participants indicated, without the implementation of management processes, activities can occur without planning and monitoring, resulting in disorganization and causing problems in the implementation and maintenance of the SOA initiative.
Regarding the usefulness of the proposed processes, participants answered the question "Classify the proposed processes according to the degree of usefulness to the organization where you work.Consider the following scale: Useless (1) (2) (3) (4) (5) Useful".Thus, for each process, participants assigned a degree of usefulness.Five participants classified the processes "Build an environment for SOA support", "Build future environment for SOA support", "Maintain environment for SOA support", "Define policies and standards for SOA" and "Prospect technologies SOA" as processes with usefulness level equals to 4 or 5. Respondents justified these processes are very important for building and maintaining a successful SOA initiative.Moreover, the processes "Build an environment for SOA" and "Maintain environment for SOA support" were the processes which received more responses equals to 5.These processes are considered essential to implement SOA in organizations.On the other hand, the process "Monitor SOA activities" received only one response equal to 5, and the corresponding respondent argues that all processes are necessary to prevent future problems in the SOA initiative.The other respondents reported quality indicators are not defined and monitored in organizations where they work.There is more pressure to service provisioning than to verify the results obtained from them.
Considering the degree of difficulty to deploy the proposed processes, participants answered the question "Please indicate how you classify the difficulty to deploy each of the proposed processes in an organization.".Possible answers to this question were "very easy", "easy", "medium", "difficult" and "very difficult".Participants believe that, in general, the levels of difficulty are medium and difficult.Some reasons for these classifications were: difficulty to deploy the processes in alignment with business needs; large number of stakeholders (mainly in large organizations); lack of preparation and experience of SOA initiatives teams; and, the adaptation of processes' activities according to organization specific characteristics.Thus, according to participants, complexity involved in implementing and maintaining SOA initiative is the factor that complicates the use of the proposed processes.
Then, participants were asked about the adoption of proposed processes with the following question: "Would you adopt the proposed processes to support a SOA initiative in the organization you work?".Despite the difficulties considered for deployment, five participants answer "Yes".They justified they would use all processes as they recognize the importance they have in an SOA initiative and the benefits they can bring.
Finally, participants were asked to indicate strengths and weaknesses observed in the proposed processes.Weaknesses mentioned were: lack of activities about service quality, data quality and definition of SLAs.Strong points pointed out were: the processes are presented in a simple, objective, explanatory and well structured form (preparation, establishment of policies and standards, construction, maintenance, preparation for the future and measurement); processes are grounded in a pre-defined set of roles; processes emphasize the importance of planning and monitoring SOA initiative rather than a disorganized implementation; the implementation of processes resulted in greater maturity of the initiative and improve the quality of services.As mentioned in the related work section and pointed out by the participants, an important characteristic of our proposal is to define the roles that are part of the initiative.

Conclusion
This paper proposed a set of processes for managing SOA initiative based on works of Botto (2004), Spewak and Hill (1992), Kajko-Mattsson et al. (2007), Niemann (2010) and Schepers et al. (2008).The proposed processes were: Build an environment for SOA support; Build future environment for SOA support; Maintain environment for SOA support; Define policies and standards for SOA; Prospect technologies for SOA; Monitor SOA activities.In addition, roles responsible for executing these processes were proposed: SOA Applications Analyst, SOA Analyst, SOA Architect, SOA Developer and SOA Manager.
In order to evaluate the processes, five participants of SOA initiatives in different organizations answered to a questionnaire about the quality and usefulness of the processes.The results indicate ease of understanding of processes and their usefulness to organizations.Some indications of little compliance or noncompliance of the proposed processes according to what is executed by participant's organizations were obtained.They emphasized that this occurs because current activities organizations perform are executed without the use of well-defined processes, as well as with little or no planning and monitoring activities.They pointed difficulty to implement the proposed processes raises due to the complexity of SOA, which must be aligned to business and requires well-prepared teams.Despite the difficulties of implementation, five participants emphasized they would implement all processes due to its importance in SOA initiative and the benefits that can be obtained from their implementation.They also pointed out additional strengths related to: the way in which processes are presented; definition of roles who execute the activities; better maturity and quality of SOA initiative arising from the implementation of processes; emphasis on planning and monitoring of the SOA initiative rather than an ad-hoc deployment.However, despite the participants' opinions, there are some weaknesses in the study.The processes are not yet implemented in a real environment and, therefore, we cannot prove its applicability.Furthermore, the evaluation by specialists requires reading the proposed processes, which makes the evaluation time-consuming and may introduce bias if the participants do not understand the processes correctly.
As future work, we propose the improvement of the highlighted weaknesses through addressing services and data quality, more specifically, the definition of SLAs and handling deactivation of services.We also suggest using the proposed processes in real scenarios in medium and large organizations in order to assess the proposal in practice, and a more detailed evaluation, encompassing a broader range of evaluation criteria.

Process interface
Represents the interface between processes (existing in a VAC), indicating that there is communication between them.In general, it is an indication of another process that complements the flow modeled, but is not the principal object of the model in question.

Logical operator XOR (exclusive or)
Logical oprrator representing: -when the split flow: only one of the paths must be traversed, ie, only one destination events must occur.
-when they join the flow: just one of the paths traversed starts the next process or activity, ie, just one of the source events must occur.

Position
Represents the position (role / function) that interacts with a process (producing or consuming information).

Aspect position
Represents the position (role / function) that interacts with a process (producing or consuming information).

Business rule
Policy aimed at influencing or guiding the behavior of the business, as support to the business policy that is formulated in response to an opportunity.

Aspect business rule
Policy aimed at influencing or guiding the behavior of the business, as support to the business policy that is formulated in response to an opportunity.

Business Requirement
Requirements from the business that will define or restrict aspects of information systems.

Aspect business requirement
Requirements from the business that will define or restrict aspects of information systems.

Application system
Represents an information system that supports the execution or executes one or more activities of the process.

Aspect Application system
Represents an information system that supports the execution or executes one or more activities of the process.

Organizational unit
Represents an area of the organization (business unit, management, coordination or department) (formal or informal), which interacts with a process.

Value-Added Chain (VAC)
VAC diagram represents organization functions that directly influence the real aggregated value of the organization.Functions can be linked to other functions in order to represent sequence and hierarchy (ARIS, 2006).
The VAC diagram describes the business processes from the more abstract view.Each process model has one or more objectives that add values to guarantee organization life.A VAC model can be detailed in other macro-processes.The highest level value chain represents the organization business process.
Figure 7 presents a VAC diagram example.This model has the macro-process "Manage geophysical processing request" composed by three other macro-process.Coordinated execution of these three macro-processes enables the management of geophysical processing requests.

Manage geophysical processing requests
Analyze seismic processing request Perform seismic processing Evaluate seismic processing

Event-driven Process Chain (EPC)
EPC is the central model in process modeling.It describes a sequence of tasks or activities, that represent the process and adds value to the business (Davis, 2002).
EPC diagram includes flow of activities, roles and organizational units, lanes (according to roles), interfaces to other processes, process start and end events, intermediate events indicating circumstances relevant to the process and logical operators.indicators, equipments, glossary terms, location, risks etc. Modeling this level of detail depends on the scope of the business process modeling project.
Figure 9 presents an FAD diagram example.This activity is performed by the interpreter, considering the business rule "Seismic processing request".Input information is "Need for seismic processing" and output information is "Seismic processing request" and "Processing quality expectations".The system AIGG supports the activity and the business requirements "Register processing request" and "Register quality expectation" are necessary to execute this activity.

Figure 1 .Figure 2 .
Figure 1.Goal model for managing a SOA initiative 3.2 Who should take part in a SOA management initiativeOrganizational roles responsible for conducting a SOA initiative are presented in Figure2, and described as follows.
Figure 3. Manage Service-Oriented Architecture 3.3.1 Build an Environment for SOA Support

Figure 4 .
Figure 4. Build an environment for SOA support 3.3.2Build Future Environment for SOA SupportBuild future environment for SOA support process is presented in the EPC process of Figure5.It defines the strategy and scope of the SOA initiative, including the definition of stakeholders' responsibilities, creation of processes to maintain the initiative and to provide the environment infrastructure.The activities comprised by this process are:

Figure 5 .
Figure 5. Build future environment for SOA support 3.3.3Maintain Environment for SOA Support

Figure 7 -
Figure 7 -Consume Service 3.3.4Define policies and standards for SOA

Figure 9 -Figure 10 -
Figure 9 -Create policies and standards for SOA  Maintain policies and standards for SOA: This process is responsible for maintaining policies and standards for SOA.It includes the selection of standards to be analyzed, identifying opportunities for improvement and change in standards.The process starts due to the need to maintain a policy or standard within SOA environment.From there, a group for setting standards is created; the improvements in the standards are identified and analyzed.Then, changes in standards are made.; Advertise policies and standards for SOA: Provide and advertise standard, train resources to use the standards.The process starts when a standard is created or changed, or when a need for dissemination of policies and standards is identified.Thereafter, the pattern is available for business and communication on the standard is conducted for the company.Then training on the standard is performed.At the end of process execution, policies and SOA standards are published;

Figure 11 -
Figure 11 -Control policies and standards of SOA 3.3.5Prospect Technologies for SOA Prospect technologies for SOA process (Figure 12) continuously prospects technologies for SOA and comprises the following activities. Perform search for information about tools: Search for information about tools for SOA environment in forums, conferences, on the Web and contacting tool vendors;  Assess tools: Evaluate tools executing the following steps: define evaluation criteria, compare candidate tools and select tools.Azevedo et al. (2011b) present a systematic tool evaluation process; Define guidelines for integration technologies: Specify guidelines for technology integration in current environment; Publish results of tools assessment: Publish results of the conducted evaluations to SOA initiative stakeholders; Assess technology viability for SOA environment: Evaluate the feasibility of implementing the selected technology; Deploy technology: Deploy the selected technologies in the environment.

Figure 8
Figure 8 presents a EPC diagram example.This model contains activities executed by the interpreter, processing manager, geophysicist and the AIGG system.The activities under the responsibility of each role are respectively in their lanes and the flow between these activities is presented.
Figure 9 -FAD diagram example This process is responsible to conduct staff training on aspects of SOA initiative.The training should include main concepts, such as, infrastructure, tools, process for service development, service management and maintenance, standards and policies define for SOA environment.
Define SOA processes: This process is responsible to define processes for: service development; service registry; service maintenance; service monitoring; Service Level Agreement (SLA) -to consider performance and availability improvements, fault tolerance, data handling etc.; service evolution due to new requirements;  Define infrastructures: This process is responsible to define the required infrastructure for the future SOA environment.The infrastructure should be created considering standard technologies, such as, communication protocols, message formats, patterns for service description and discovery.It should define the service portfolio architecture, how to discover services, how service documentation should be stored and the required resources for a user to query service repository.It should define tools required for service design and implementation.Deployinfrastructure: This process is responsible to deploy the defined SOA environment infrastructure.A deployment roadmap should be defined.The roadmap should consider procedures to create tool acquisition contracts, acquire tools, install test the acquired tools.Infrastructure services should be created to support business applications and services to: discover services; transform messages according to defined protocols and standards; support internal and external service communication.All deployed infrastructure should be documented.Perform training: