Method Engineering for SOA Realization based on Welke?s SOA Maturity Model

Service Oriented Architecture (SOA) is an architectural style for both business and IT. Its main components are services of different types, having separate concerns, yet abstracting/refining each other. SOA is foreseen as a response to the growing needs for greater reuse, integration, and composition of IT services to support business flexibility and agility. As such, most organizations understand the need to address SOA adoption and realization. Indeed, SOA promises in terms of reuse, integration, composition, flexibility, and agility constitute benefits for both IT people and business managers, two types of stakeholders having separate concerns and views of SOA, yet ambiguous and even conflicting for most of them. Moreover, SOA means different things for different people. Most of its current realizations are thought of as web service realization. Therefore, realizing SOA is not an easy task. This has entailed provision of new methods processes and tools (from both academia and industry) for provisioning services, especially fine grained services that can be reused in composition of service-based applications. But these methods, processes and tools suffer from having a comprehensive view and benefits from SOA for both IT people and business managers. In addition, the services are developed on case-by-case basis, which yields brittle SOA. Indeed, the comparison frameworks show that show that the current methods vary significantly in many aspects such as (i) the products (e.g. services or compositions), (ii) types of services (e.g. technology or business services), (iii) the three roles in SOA, and (iv) delivery strategies such as meet-in-the-middle, top-down, bottom-up, or green-field. Moreover, the current methods do not consider the complexity of SOA and its distinct levels of concerns, neither have they considered SOA maturity or orientation models that would guide the type of services and the service sourcing). Such models would guide the definition of each type of services, their sourcing, their control, and their management not only at each maturity level but also for each situation and context. SOA realization rather requires more than one method, each of which has its own: (i) definition of the building block that is service, (ii) view of SOA as an architectural style of the solution the method produces, and (iii) step-wise process to source the services. These methods should mainly concern with: (i) the engineering of the services as basic components, (ii) the engineering of compositions of services as composites, (iii) the management of services and compositions, (iv) the quality of IT-services, architectures, and compositions, (v) the engineering of business in terms of services (business functions and business processes as services), and (vi) the flexibility of business processes and agility of business, which constitutes distinct levels of concerns. Therefore, we need a new engineering method to realize SOA. In this project, we propose a novel approach based on a well-known SOA maturity model that is Welke and rsquo;s model, which recommends the development of artifacts for each view and benefits of SOA. Practically, this approach is expected to relax IT-people who invested in their legacy information systems, by providing them with an incremental process that reflects their reality. It is expected to bring solutions, in terms of methods, processes, and tools that benefit to many Omani organizations that are facing the problem of integration in the context of e-commerce in general and e-government in particular.

Service Oriented Architecture (SOA) is an architectural style for both business and IT. Its main components are services of different types, having separate concerns, yet abstracting/refining each other. SOA is foreseen as a response to the growing needs for greater reuse, integration, and composition of IT services to support business flexibility and agility. As such, most organizations understand the need to address SOA adoption and realization. Indeed, SOA promises in terms of reuse, integration, composition, flexibility, and agility constitute benefits for both IT people and business managers, two types of stakeholders having separate concerns and views of SOA, yet ambiguous and even conflicting for most of them. Moreover, SOA means different things for different people. Most of its current realizations are thought of as web service realization. Therefore, realizing SOA is not an easy task. This has entailed provision of new methods processes and tools (from both academia and industry) for provisioning services, especially fine grained services that can be reused in composition of service-based applications. But these methods, processes and tools suffer from having a comprehensive view and benefits from SOA for both IT people and business managers. In addition, the services are developed on case-by-case basis, which yields brittle SOA. Indeed, the comparison frameworks show that show that the current methods vary significantly in many aspects such as (i) the products (e.g. services or compositions), (ii) types of services (e.g. technology or business services), (iii) the three roles in SOA, and (iv) delivery strategies such as meet-in-the-middle, top-down, bottom-up, or green-field. Moreover, the current methods do not consider the complexity of SOA and its distinct levels of concerns, neither have they considered SOA maturity or orientation models that would guide the type of services and the service sourcing). Such models would guide the definition of each type of services, their sourcing, their control, and their management not only at each maturity level but also for each situation and context. SOA realization rather requires more than one method, each of which has its own: (i) definition of the building block that is service, (ii) view of SOA as an architectural style of the solution the method produces, and (iii) step-wise process to source the services. These methods should mainly concern with: (i) the engineering of the services as basic components, (ii) the engineering of compositions of services as composites, (iii) the management of services and compositions, (iv) the quality of IT-services, architectures, and compositions, (v) the engineering of business in terms of services (business functions and business processes as services), and (vi) the flexibility of business processes and agility of business, which constitutes distinct levels of concerns. Therefore, we need a new engineering method to realize SOA. In this project, we propose a novel approach based on a well-known SOA maturity model that is Welke and rsquo;s model, which recommends the development of artifacts for each view and benefits of SOA. Practically, this approach is expected to relax IT-people who invested in their legacy information systems, by providing them with an incremental process that reflects their reality. It is expected to bring solutions, in terms of methods, processes, and tools that benefit to many Omani organizations that are facing the problem of integration in the context of e-commerce in general and e-government in particular.