EXPLORING THE BUSINESS VALUE IN SERVICE-ORIENTED ARCHITECTURE: SURVEY-QUESTIONAIRRE
Dear Sir/Madam,
I am conducting a research that investigates the main drivers of the integration of Service-Oriented Architecture within the organization. The purpose of this study is to help companies decide or have an insight if it is necessary to integrate and implement SOA or not. I have faith that given your experience and current job position, you are knowledgeable about this matter and qualified for answering this survey-questionnaire.
I am hoping for your kind consideration and participation. Thank you very much.
Many Thanks,
A. Demographic Information
Instruction: Please fill in the blanks with the specific answers.
Name: _______________________ Civil Status: ____________________
Address: _______________________________________________________
Occupation: _______________________ Sex: ______ Age: __________
Company Name: _________________________________________________
B. Perception of the Respondents
Instruction: Please encircle the number that best describes your position on the possible reasons of turnover. Please be reminded that there is no right or wrong answer, and that every data you will provide will be treated with utmost confidentiality.
5 – Excellent
4 – Good
3 – Average
2 – Poor
1 –Very Poor
1. SOA makes the service process easier for your company.
1 2 3 4 5
2. SOA provides the natural basis for unintrusive reuse of the back-end logic by multiple styles of clients.
1 2 3 4 5
3. SOA is a useful tool to improve web service.
1 2 3 4 5
4. The use of SOA in Web Service makes it work smoothly.
1 2 3 4 5
5. SOA is cheaper than previous software architecture?
1 2 3 4 5
6. SOA has more run-time overhead and transactional latency.
1 2 3 4 5
7. SOA addresses the issue of different information models operating in different enterprises or operational domains.
1 2 3 4 5
8. SOA addresses the related issue of different identity or naming standards and appropriate authorities for different operational contexts.
1 2 3 4 5
9. SOA is necessary to implement because it eases integration in heterogeneous environments and provides a transformational enhancement in agility, visibility, consistency, and interoperability.
1 2 3 4 5
10. SOA is necessary to implement because the previous architecture software that your company use is no longer compatible with new systems brought in.
1 2 3 4 5
11. SOA improves the service performance of your company.
1 2 3 4 5
12. SOA helped increase the sales of the company.
1 2 3 4 5
13. SOA made it easy for both the employees and the customers to access service information.
1 2 3 4 5
14. SOA made it easy for IT technicians to input new programs related to service.
1 2 3 4 5
15. SOA improved the organization’s service function and made it easy for them to organize services.
1 2 3 4 5
Open Questions
1. What are your reasons for implementing the Service-Oriented Architecture?
________________________________________________________________________________________________________________________________
2. Does SOA improve the service performance of your company? Please explain your answer.
________________________________________________________________________________________________________________________________
3. Does SOA made it easy for the company because it is compatible with latest information technology applications.
________________________________________________________________________________________________________________________________
4. Is SOA more beneficial in business, the technical side of the company, or both? Please explain your answer.
________________________________________________________________________________________________________________________________
Thank You Very Much for Your Participation!
CHAPTER 2
REVIEW OF RELATED LITERATURES
This chapter presents the related literatures that were collated and reviewed for the study. Most of the literatures came from online databases and some are unpublished academic journals that can be found in the web.
Software Architecture
Software architecture is the rules, paradigm, or pattern that helps to construct, build and test a serious piece of software (2005). It involves the integration of software development methodologies and models, which distinguishes it from particular analysis and design methodologies. The structure of complex software solutions departs from the description of the problem, adding to the complexity of software development. The purpose of this type of approach is a means of controlling the complexity of system construction and evolution, in particular for providing systems with the agility that is required to operate in turbulent environments and to adapt very quickly to new business requirements, new design technologies, or even to changes in the enterprise world which, like mergers and acquisitions ( 2005). The architecture of a system basically describes its gross structure, whereas the structure illuminates the top level design decisions, including things such as how the system is composed of interacting parts, where are the main pathways of interaction, and what are the key properties of the parts (2000). It basically includes sufficient information to allow high-level analysis and critical appraisal ( 2000).
In other definitions,(1998) defined it as a representation of an engineered (or to be engineered) software system, and the process and discipline for effectively implementing the designs) for such a system. According to them, software architecture is a representation because it is used to convey the information content of the related elements comprising a system, the relationships among those elements, and the rules governing those relationships (1998). On the other hand, it is a process because a sequence of steps is prescribed to produce or change the architecture, and/or a design from that architecture, of a system within a set of constraints (1998). Finally, it is a discipline because a body of knowledge or a general set of principles of (software) architecture is used to inform practitioners as to the most effective way to design the system within a set of constraints (1998).
Given that software architecture is being considered as a representation, process and discipline, it is acceptable to say that it is basically a tool that any organization can use to their advantage. Through it, an organization can easily manage sets of information without difficulty or without fear that it will all be mixed-up. The definition alone shows that that such approach offers flexibility to the company as it can handle and manage a large amount of information.
Software architecture, since its discovery, has been continuously evolving. Because software architecture has always been the subject of scrutiny in terms of performance and limitations, today’s practitioners have come to realize that getting an architecture right is a critical success factor for system design and development ( 2000). They have begun to recognize the value of making explicit architectural choices, and leveraging past architectural designs in the development of new products (2000).
Brief History of Software Architecture
Software architecture is a representation, process and discipline that evolved from programming languages ( 1994). Language programming emerged in the 1950s, along with the emergence of digital computers ( 1994). During that time, programmers placed instructions and data individually and explicitly in the computer’s memory (1994). There were basically no means of organizing or managing chunks of data from specific software ( 1994). (1994) noted: “insertion of a new instruction in a program might require hand-checking of the entire program to update references to data and instructions that moved as a result of the insertion” .
Because of the difficulty of insertion of new instruction of the entire program because of its manual-driven characteristic, designers and engineers looked for ways to make things easier for them. Eventually, they discovered that the memory layout and update of references could be automated, and also that symbolic names could be used for operation codes, and memory addresses (1994). Symbolic assemblers were discovered, and then macro processors, which allowed a single symbol to stand for a commonly-used sequence of instructions ( 1994). Soon, arithmetic patterns were discovered and offered a new angle on the management of data through the use of software (1994). Furthermore, progress in language design continued with the introduction of modules to provide protection for related procedures and data structures, with the separation of a module’s specification from its implementation, and with the introduction of abstract data types (1994).
In the 1960s, the idea “If you get the data structures right, the effort will make development of the rest of the program much easier” was intuitively realized by programmers (1994). From that realization, programmers discovered and developed the abstract-data type in the 1970s. The theory involves the understanding of: the software structure (which included a representation packaged with its primitive operators); specifications (mathematically expressed as abstract models or algebraic axioms); language issues (modules, scope, user-defined types); integrity of the result (invariants of data structures and protection from other manipulation); rules for combining types (declarations); and information hiding (protection of properties not explicitly included in specifications) (1994). Through this, the design level of several software systems was raised. Basically, it led to the understanding of a good organization for an entire module that serves one particular purpose. Furthermore, it was achieved through combining representations, algorithms, specifications, and functional interfaces in uniform ways (1994).
Today, with the advent of information technology, good software system designers now recognize useful system organizations. Some of the ways discovered to organize system include: Camelot; abstraction layering and system decomposition; distributed object-oriented approach; and the pipeline ( 1994).
The Role of Software Architecture
According to (2005), complexity is the key concern that software architecture should address. Quoted from (1992): ““as the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem… This is the software architecture level of design.” (2005). Programmers should also recognize that complexity presents itself in two primary guises: intellectual intractability; and management intractability ( 2005). Intellectual intractability means complexity is inherent in the system being built, and may arise from broad scope or sheer size, novelty, dependencies, technologies employed, etc; while management intractability means the complexity lies in the organization and processes employed in building the system, and may arise from the size of the project (number of people involved in all aspects of building the system) (2005). (2005) explained that software architecture may help the system intellectually manageable and understandable through providing abstractions that hide unnecessary detail, providing unifying and simplifying concepts, decomposing the system, etc. On the other hand, software architecture may make the development of the system easier to manage by enhancing communication, providing better work partitioning with decreased and/or more manageable dependencies, etc ( 2005).
(2005) explained that a systems priority setting should have to be chosen so as software architecture can function more effectively. One has to pick where to excel and choices include: the business, including business strategy and direction, core competencies and resources, and politics; the market including customers, competitors, suppliers and channel; technology including trends and opportunities; constraints including existing technology investments and legacy systems; challenges and impediments to the success of the system, the development of the system, and the business ( 2005).
Decomposition or composition is also another concern as there is a need for the programmer to assure that functionality or services of the system can be delivered by the components working in collaboration. Cross-cutting concerns are also present, whereas performance typically has to be considered in terms of the patterns of interaction that the architectural structure allows, and is not just a matter of optimizing the performance of the parts separately ( 2005). Other concerns include: system fit to context, which has to do with interoperability, consistency and interface with external system; and system integrity, which means having, or being conceived of as having, a unified overall design, form, or structure (2005)
(2005) also mentioned that software architecture has three main drivers. They are: Architecture Vision (expressing the desired state that the architecture will bring about); Architectural Requirements (capturing stakeholder goals and architecturally significant behavioral functional requirements as well as system qualities non-functional requirements and constraints); and Assumptions, Forces and Trends (documenting assertions about the current business, market and technical environment now and over the architecture planning horizon).
The Emergence of the Service Industry
Services are defined as a diverse group of economic activities not directly associated with the manufacture of goods, mining or agriculture (Organization for Economic Co-operation and Development, 2000). They are different from manufactured products because they are intangible goods, meaning they are not presented or sold as items, but as services (2000).
Services are important for developed and developing countries. Generally speaking, in economic terms, the service economy has great importance in gross domestic product (GDP) and the production of job opportunities. According to the Trade Enhancement for the Services Sectors (2004), a project supported by the United States Agency for International Development, the reasons why the service sector is important are the following: the services sector is the largest and fastest-growing sector of the world economy, providing more than 60% of GDP in many countries, and an even larger share of employment; services trade represented over one third of total trade in goods and services in 2000; services are critical to competitiveness as inputs for other sectors’ output, particularly in lowering the cost of production; it generates and promotes tourism, which is the world’s largest employer; and total measurable trade in services (as defined under GATS), represents 7.6% of world output, and currently stands at US .3 trillion. Because of the dominance of service industry (for instance in America, almost 70% of employment is in the service sector), many service enterprises and organizations compete for service quality. This involves the challenge of quality measurement. Based on the research of some authors, they have developed a conclusion that measuring quality is difficult because it involves too many intangible aspects that are complex to quantify.
According to (1992), the top six attributes for service quality includes: knowledge of the service; thoroughness/accuracy; consistency/reliability; reasonable cost; willingness to correct errors; and timely/prompt service. On the other hand, the stop attributes for poor service quality include: lack of knowledge about the service; employee indifference or “I don’t care attitude”; reluctance to correct errors; service inconsistency; sloppy service; and high cost ( 1992).
Service quality reflects both the manner and the location of the service delivery ( 2001). Clients often make inferences about service quality based upon tangible and intangible cues observed during interactions with the firm (Wakefield, 2001). These are called the tangible and intangible service quality. It involves both tangible and intangible aspects. Tangible aspects include: all that the client can see, touch, hear, and smell when the services are delivered ( 2001). Thus, tangibles basically involve physical facilities, equipment, and appearance of employees (1998). On the other hand, the intangible aspects of service quality comprise the manner in which services are delivered (2001). Service performance describes all aspects of the delivery of services, such as reliability, responsiveness, assurance, and empathy ( 2001).
Service-Oriented Architecture
In order to be more flexible and to meet several top attributes of service quality, many companies are using a service-oriented architecture (SOA) approach (Hewlett-Packard Development Company LP, 2006). This approach is a specific type of software architecture that is designed to create a dynamically organized environment of networked services that are composable and interoperable (2003). Furthermore, it is a distributed system architecture consisting of a collection of services ( 2006). Through this, a service encapsulates a reusable business function, loosely-coupled to other services, and is invoked through connection technologies services (2006).
(2003) stated that SOA is gradually replacing monolithic architecture as the premier design principle for new business applications. (2003) stated that the advantage of SOA over other software architectures is that a loosely coupled SOA provides the natural basis for unintrusive reuse of the back-end logic by multiple styles of clients. This basically makes the transition to multiclient and a multichannel application naturally pushes forward the SOA-based application design ( 2003). Furthermore, composition and integration of old and new business components into new real-time transaction patterns are a natural fit with SOA.
(2003) also stressed that due to the popularity and hype of SOA, there are several myths regarding its benefits. (2003) argued that firms should learn how to separate myths from facts. The true benefits that SOA can provide include: incremental development and deployment of business software; reuse of business components in multiple business experiences; low-cost assembly of some new business processes; and clarity of application topology. On the other hand, the following are the mistakenly attributed benefits of SOA: simple software engineering; free integration or interoperability; technology independence; vendor independence; and the ultimate architecture for the modern enterprise (2003).
A specific study explored SOA through focusing on its company ABC (2006). It was a case a study of a company known as ABC, which after the September 11, 2001 attacks, zeroed in on a home-grown fat client system, System E, as the enterprise data warehouse for risk management (2006). According to the case, it became mission critical for System E to remove key person dependencies and migrate from C++, a niche technology, to a more accessible platform. This problem, as well as due to the leadership of a new recruits, the SOA was implemented in the company.
(2006) found that the integration of SOA in ABC Company resulted in an Enterprise Service which supports business processes. Accordingly, it was a major improvement as transaction processing systems are loosely coupled from the internals of System E. Instead of only making one call from the System E, with the SOA, ABC can now make three calls. The implementation basically improved the functionality of the company.
Reliability has also improved. In the SOA Model at ABC, instead of approximately two dozen MQ queues, one MQ queue suffices for the Enterprise Service. Elimination of MQ calls translate to improved reliability because of removal of interdependencies that can be affected by MQ errors or time-outs (2006).
Finally, the best benefit that SOA offered to ABC was performance. Performance improvements include: use of parallel processing for adhoc service chaining; use of record structure (versus XML) as the message format; and use of MQ over HTTP as the connection technology.
(2004), on the other hand, examined automated planning in SOA. Planning, publishing, discovering and negotiating composed services was described and analyzed, based on three alternative abstraction levels of service descriptions: complete, functional and category. Two roles of service composer were taken into account, which are the provider and requester. The study found that as a service requester, a service composer depends on completely described services. A service composer relies on completely described services to specify the input domain. The study also found that service categories enable the best customization of composed services. Service categories can be implemented easily with the use of SOA ( 2004).
The Non-Centric Operations Industry Forum (2005) has a written a White Paper that discusses industry best practices in achieving SOA. The paper stated that one of the benefits of SOA is that it eases the integration of the heterogeneous IT environments found in many organizations through the use of standard protocols, such as web services (NOIF, 2005). Another benefit stressed in the forum is that SOA forces IT workers to think in terms of dynamic operational needs and, therefore, requires leaders to focus on the best ways to improve operations. The rationale is that by exposing and sharing information across once-soiled applications, organizations can extract more business performance data in real time, improving business intelligence and increasing responsiveness. Finally, another found benefit of SOA is that it can lead to a greater return on investment (ROI) because it facilitates easier integration and increased agility (2005).
Similar advantages of SOA were also stated by (2003). They are the following: the client of the service should not have to know about implementation details of the server; location of the server should be transparent to the client. It is only at run-time that client will know the location of the server; software should be able to interoperate with other software running on other platforms; and that multiple versions of server software should be accessible at the same time. However, there are also system requirements which are: performance; security (access control, encryption, temper proofing); availability; and reliability (, 2003).
On the other hand, (2005) found some industry best practices that may boost the implementation of SOA. They include: Vision and Leadership; Policy and Security; Strategy and Roadmap Development; Governance and Acquisition; Implementation and Operations. The conclusion of the study emphasized that implementation is better than theory. That is said, SOA implementation needs to be done with something that is operationally useful.
In a study sponsored by Adobe, (2005) examined many implementations of a Service Oriented Architecture, and also identified its most common concepts, and records the authors’ opinions on these concepts. In this study, some business drivers for adopting SOA were found. This includes: limited budgets; constantly changing technologies; evolving technologies for the same business function. An example of this may be a new version of software (and Application Programming Interfaces or APIs) for customer relationship management (CRM); business requirements that demand applications and technology silos that need to be integrated with each other; and Application functionality that must be extended to reach outside an enterprise firewall (the extended enterprise). The study found that SOA does not have a standardized, reference model yet; however, implementations share the main concepts of services, service descriptions, advertising and discovery, the specification of an associated data model, and the use of a service contract (2005). Furthermore, it may also implement optional concepts that include a service consumer, a service client, acceptance of the service contract and invoking the service (2005).
(2004), authors of an IBM red book that discusses SOA, also mentioned specific business drivers of the new approach. However, their emphasis is different from the rest of the main drivers discussed earlier because they mainly focus on heterogeneity and change. Their rationale is that most enterprises today contain a range of different systems, applications, and architectures of different ages and technologies, but implementing or integrating one of them has always been difficult. There is basically a need for an easier way of integrating and managing data. Also, changes are common in the business world today. Customer needs and requirements change more quickly driven by competitive offerings and wealth of product information available over the Internet (2004). There is a strong emphasis on service quality, requiring businesses to rapidly adapt to survive, let alone to succeed in today’s dynamic competitive environment, and the IT infrastructure must enable businesses’ ability to adapt ( 2004).
WebMethods (2005) also provided some insights on the benefits that SOA can provide. According to the company, there are three features of an SOA provide value. These are: the promotion of reuse; the ability to combine services into new, composite applications; and the use of loosely-coupled services through a standard interface. The business effectiveness of SOA may include: agility, responsiveness to market and competitive dynamics; greater process efficiencies; and deployment of resources based on business needs. On the other hand, in terms of cost efficiency, SOA may: reduce maintenance costs; reduce skills and effort to support business change; and price/performance optimization based on freedom to select platform, technology, and location independently. Finally, SOA may also reduce risks, i.e. higher level of IT quality, incremental deployment; and improved payback times. WebMethod’s rationale for the implementation of SOA is that it is both technical and business driven – in a sense that companies need to integrate it to achieve technical advancement over other competitors, which may then result in positive business results due to the enhanced customer service that the approach can offer.
CHAPTER 3
METHODS AND PROCEDURES
Research Philosophy
The research philosophy of this current study is positivism because it aims to generalize specific results by surveying large-scale respondents. According to (2003), positivism is applicable to researchers who prefer working with an observable social reality and that the end product of the research can be law-like generalizations similar to those produced by the physical and natural scientists. Here, the researcher is independent of and neither affects nor is affected by the subject of the research.
Research Approach
The research approach of the study is the deductive approach because it aims to determine a particular problem through survey of large-scale respondents. Furthermore, this study aims to determine a causal relationship between variables – on whether SOA is implemented because of the business benefits it can provide or because of technical issues.
Research Strategy
The research is a descriptive type of research that will illustrate the main drivers of SOA implementation within organizations.
A descriptive research intends to present facts concerning the nature and status of a situation, as it exists at the time of the study (Creswell, 1994). It is also concerned with relationships and practices that exist, beliefs and processes that are ongoing, effects that are being felt, or trends that are developing. (1970) In addition, such approach tries to describe present conditions, events or systems based on the impressions or reactions of the respondents of the research ( 1994).
Basically, a descriptive research utilizes observations and surveys. It is for this particular reason that this approach was chosen by the researcher, whose intention is to gather first hand data from technical architects, CIO’s and senior developers who are involved with SOA and who are planning to develop/upgrade their systems using SOA in near future and their initiatives. Moreover, this will allow for a flexible approach that when important new issues and questions arise at the duration of the study, a further investigation can be conducted. Also, with this type of approach, the researcher will be allowed to drop unproductive areas of research from the original plan of the study. Another advantage is that with this approach, the research will be fast and somehow cost-effective.
The primary sources of data are the survey interviews conducted by the researcher among technical architects, CIO’s and senior developers. Results were compared and were evaluated to determine the main drivers of SOA implementation within their respective organizations.
Meanwhile, the secondary sources of data will come from published articles from business and e-commerce journals, theses and related studies on welfare reform.
For this research, the researcher collated and gathered relevant, and collated them together with published studies from different local and foreign universities and articles from social science journals, then afterwards render a critical analysis on the collected documents and verbal materials. A summary of all the information gathered will also be provided by the researcher, as well as a conclusion and insightful recommendations on SOA implementation.
Research Methods to be Used
Because the method of the study is to collect and analyze the perceptions of large-scale respondents, quantitative research was used. This approach is compatible with the study because it allows the research problem to be conducted in a very specific and set terms ( 1992). A quantitative research plainly and distinctively specifies both the independent and the dependent variables under investigation (2002). It also follows resolutely the original set of research goals, arriving at more objective conclusions, testing hypothesis, determining the issues of causality and eliminates or minimises subjectivity of judgment ( 1996). Further, this method allows for longitudinal measures of subsequent performance of research subjects (2002). Finally, it provides achieving high levels of reliability of gathered data due to i.e. controlled observations, laboratory experiments, mass surveys, or other form of research manipulations (1970). This study should be based on surveys and statistical treatments, so basically the quantitative approach fits well with it.
Sampling
A total of 65 technical architects, 48 CIO’s and 30 senior developers who are involved with SOA and who are planning to develop/upgrade their systems using SOA in near future and their initiatives were surveyed in this study. The original target of the study is to have 75 for each respondent category. However, 10 technical architects, 27 CIO’s and 40 senior developers backed up. Overall, the respondents who participated in the study are in the total of 143.
The respondents came from different companies that belong in different industries. Qualified respondents were confirmed to have been involved in decision-making regarding the implementation of SOA and are highly knowledgeable about software architectures.
Because of the difficulty to identify qualified respondents for the study, the sampling technique used was the snow ball sampling. This approach is used when it is difficult to identify members of the desired population (Saunders et al, 2003). The strategies for snow ball sampling recommended by Saunders et al (2003) were taken into consideration in the sampling of the study. The strategies include:
Ø Few technical architects, CIOs and senior developers were contacted.
Ø Those who were initially contacted were asked to identify people they know who have similar cases or experience with SOA.
Ø The new cases were asked to identify further cases.
Ø The process was stopped when the sample was as large as manageable.
Data Collection
Data Collection Technique Used
The survey method, also known as the questionnaire method, is used in gathering the data.
Surveys are the most common form of research method for collection of primary data ( 2000). One of its purpose is to describe, e.g., to count the frequency of some event or to assess the distribution of some variables such as proportion of the population of different age groups, sex, religion, castes and languages, knowledge, attitude and adoption of practices about particular issues, and other information of similar nature about the population ( 2000). The descriptive survey of the population is valuable in understanding the audience, and in the definition of the existence and magnitude of the problems, and the survey data are also helpful in determining cause and effect relationships between variables (2000). Further, the preliminary descriptive survey results can prove useful for planning more sophisticated survey studies with a view to identifying areas where problems occur or where changes are required, to understand why people behave in a certain manner and what can be done to provide alternate solutions to the problems, where an attempt is made to understand the relationships between different variables, and the purpose of survey becomes to diagnose or analyze the situation rather than just describe the situation ( 2000). Surveys may also be done to measure the extent and nature of effect and impact of a project to the population exposed to it for a reasonable length of time (2000).
Moreover, surveys are done to gather data from the field in order to generalize results from a sample to a larger population. ( 2000) The primary purpose and advantage of surveys is generalization of the results (2000). Usually, surveys are interested in gathering data from many than in obtaining intensive, detailed information from a few individuals; therefore, it is seldom for a survey to consist of one or very few individuals ( 2000). Consequently, in designing a survey research study, one has to take into consideration the sample and the sampling procedure: the sample size should be adequate to allow generalization of the results, and the sampling procedure should also be such that small sub-groups within the population (such as landless farmers) are properly represented in the sample (2000). This is because errors in sampling procedures may not justify generalization of the results, thus lowering the value of the survey ( 2000).
Accordingly, basic knowledge and descriptions of populations and geography etc. are preconditions for survey research, particularly for sample construction and designing of tools for information gathering, thus, it is pertinent for a researcher to collect beforehand pilot data through case studies, observations and other methods before staging on meaningful survey studies ( 2000). Further, most survey data-gathering tools are structured to facilitate quantification of the responses ( 2000).
The major tools used for the survey consist of questionnaires and structured interviews ( 2000).
Instrumentation
A semi-structured questionnaire was constructed as an instrument for the collection of data. The questionnaire contains two types of questions: ranking questions and open-ended questions. The ranking questions were necessary to generalize the results, while the open questions were included to be able to give the respondents the opportunity to expand their answers.
This survey-questionnaire will have two sections. The first part will intend to acquire the demographic profile of the respondents, while the other section will contain a set of attitude statements. The purpose of the set of attitude statements is to determine the level of agreement or disagreement using a five-point Likert scale. In the Likert technique, the degree of agreement or disagreement) is given a numerical value ranging from one to five, thus a total numerical value can be calculated from all the responses. ( 2004) The equivalent weights for the answers will be:
Range Interpretation
4.50 – 5.00 Strongly Agree
3.50 – 4.00 Agree
2.50 – 3.49 Uncertain
1.50 – 2.49 Disagree
0.00 – 1.49 Strongly Disagree
Validation of the Questionnaire
For validation purposes, the researcher pre-tested a sample of the set survey questionnaires by conducting an initial survey to at least five respondents. After the respondents have answered the questionnaire, the researchers asked them to cite the parts of the questionnaire that needs improvement and were asked for suggestions and corrections. The researcher, afterwards, again examined the content of the survey questions to find out the reliability of the instrument and to determine irrelevant questions that have to be discarded, as well as to identify words that would be deemed difficult by the respondents so these will be changed to simpler terms.
Administration of the Questionnaire
The self-administered questionnaires were delivered by hand to each respondent and were then collected later on. This type of administration of questionnaires is called delivery and collection (questionnaires). In this type of administration, it is important that the covering letter, which explains the purpose of the survey, states when the questionnaire is to be collected, where a variation of this process will allow for the delivery and collection of questionnaires at the same day, does eliminating the need for a follow-up, unlike in postal and on-line questionnaires. ( 2003) This variation had guided the researcher in his own study, which had the following stages: first, ensure that all questionnaires and covering letters are printed and a collection box is ready; second, contact respondents by internal post or telephone advising them to attend a meeting or one of a series of meetings to be held (preferably) in the organisation’s time; third, at the meeting or meetings hand out the questionnaire with a covering letter to each respondent; fourth, introduce the questionnaire and stress its anonymous or confidential nature; and lastly, ensure that the respondents place their completed questionnaire in work before they leave the meeting. ( 2003)
Data Analysis
The study used quantitative analysis in order to statistically interpret the results that were derived from the questionnaires. On the other hand, the open-ended questions were analyzed through content analysis. The most common themes among the respondents’ answers were compared and gathered, and through those themes, conclude the overall consensus of their responses – on whether most of them agrees that the main driver of SOA is business or technical aspect or both. In a content analysis, documents, text or speech are examined to determine what themes will emerge from them, and this type of data analysis is theory-driven, because it is the theory which determines what theme a researcher has to look for. ( 2002)
Meanwhile, to interpret the quantitative data gathered, the researcher will use the following statistical formulae:
1. Percentage – to determine the magnitude of the responses to the questionnaire.
n
% = ——– x 100 ; n – number of responses
N N – total number of respondents
2. Weighted Mean
f1x1 + f2x2 + f3x3 + f4x4 + f5x5
x= ——————————————— ;
xt
where: f – weight given to each response
x – number of responses
xt – total number of responses
Credit:ivythesis.typepad.com
0 comments:
Post a Comment