SOA Project Overview - Building Composites - Part 1

[Former Member]

In this article I am going to focus on the implementation (also known as building) of a concrete business process based on a service enabled platform. Let’s assume that the scope of the concrete project is already defined and the project is part of a comprehensive enterprise SOA program. Besides this I will describe the roles, skills and tools (development / design) required for the different steps of the project implementation phase. I will not cover topics related to planning or running (operating) SOA Projects as well as setup, service management and some other topics that are naturally part of project implementation phase (I save the right to describe it in the following articles ).

Introduction

There has been a lot of buzz in the last year about opportunities around SOA, we heard a lot of paeans to SOA and many famous analysts predict that all the roads lead to SOA. According to article from Gartner : “Through 2008, SOA and Web services will be implemented together in more than 75 percent of new SOA or Web services projects (0.7 probability)”; (by the way , I found this very nice article with very good links inside). It is clear already today that services based applications software will ultimately experience the highest growth in the next few years, fueled by the innovations of application suite vendors which will use services as an abstraction facade to decouple and deploy their applications. I saw a lot of articles about SOA lately but could not really find something talking about SOA Project best practices, not implementation details (that are missing as well) but rather about the methodology. This is why I would like to cover some gaps in this article and describe:

• Steps (not required but optional) in the implementation phase of an Enterprise SOA project
• The Role of developers, business process experts and enterprise architects in these projects
• Classify the Tools and describe what in my eyes the right tolls are for Business Process Experts and Developers. I would like to describe a number of Development / Design tools (ARIS , ccBPM …) that are not covered in “A Solution Architect's Guide to Selecting Development Tools ” and look on all these tools from different perspective: What are the right tools for different project phases and who should use it ?

Project Implementation Steps

Once you have a good understanding of what SOA is all about, you have a SOA strategy/roadmap (all this is done during the planning phase) and the required SOA infrastructure is in place, it is time for the real test – the implementation of your identified project/projects. Each SOA implementation project brings a new set of issues and challenges. I believe that an SOA project implementation has 4 major steps. These four steps (please see below) are the pattern that I created for myself and I am following it in all my Enterprise SOA activities, you are welcome to adopt it as well.

1. Process Modelling - According to Wikipedia: “Business process modeling is an activity performed by business analysts within a company. Analysts use modeling tools to depict both the current state of an enterprise and the desired future state. The activity of modeling a business process usually predicates a need to change processes or identify issues to be corrected.” Process Modelling is all about designing the processes which enable people to carry their daily tasks efficiently and this is why processes supposed to work FOR people rather than people are working for systems and have always adopt themselves and fight different restrictions of these systems. People won’t be happy if they have to live in some house that was not built for them and they do no like it. The business process modelling is very similar to building a house, you need well defined architects drawings (which are based on the prospects/customers requirements) describing different systems in your house, sequence, regulations … only then you can start the building works. I consider Process Modeling as a first step in the implementation phase; it is all about understanding the business and people requirements and model it.
2. Services Provisioning - After the process model has been defined, it is necessary to identify which business objects and services exist and can be reused or what should be developed / bought in order to enable the business processes in scope. The specification of the missing building blocks then should be forwarded to development and they will decide on whether to build or buy the missing blocks. Development of services requires a long-term commitment by both business sponsors and I.T. staff so it is very important to specify and design the service properly, keeping in mind main key SOA principals: loosely coupled, reusable, granular. Consumption of standardized services across the enterprise improving reusability of software components and creating agility in responding to change. Development is the second step in SOA project implementation but it is not all that should be done at this phase. You need to take care of the infrastructure aspects of your solution as well, including security (was a big barrier until standards such as Web Services Security were passed), data integration and management.
3. Services Orchestration - Once we have all our services ready (= all the building blocks for building our house), we can proceed building our originally defined business process (= build our house according to architectural draws). We should stick to the process that was modelled at the first stage and do the implementation of the process now. Our previously modelled business process should specify the information flows between services as well as services and user interface during the whole lifecycle of the process. Business processes typically involve the exchange of messages between the process and other web services, known as partner services: hence the term web service orchestration. It is very important to define how the web services are going to interact with each other at the message level and at the execution level and define the sequence of activities that make up a business process I know that the orchestration step might be confusing for some of you (as it was for me at the beginning) so I would like to provide an example: In order to process a Purchase Order (= Process), a company might need to Request a list of possible suppliers (= service), make a Price Quotation (= service), submit a Purchase Request (= service) and finally arrange for shipping and delivery. Some of these steps are interdependent and must be coordinated (Price Quotation -> Purchase Request), while others are more isolated and can be processed in parallel.
4. Services Consumption - Services might be consumed in Services Provisioning, Services Orchestration and Services Consumption steps. It is very important to describe what I mean by services consumption in all these phases in order to prevent confusion in the future:
   • Services Provisioning - developing new services by consuming (reusing) standards-based Web services and wrapping them with the associated business logic to make them useful at an enterprise level. You can either reuse your existing services or buy it from different vendors and then wrap them into new Web or Enterprise Services. This activity is sometimes called “services composition”.
   • Services Orchestration - consuming services to implement the processes.
   • Services Consumption - consuming services for building user interfaces.
   You can start with Services Consumption even before finishing the first 2 steps (Services Provisioning and Orchestration), the main requirement for starting this step is that all the services are well defined. The ideal situation will be to have all the Meta data of the services in one central repository. An Enterprise Services Repository is one of the central and standard parts of a SOA based system landscape that enables organizations to find their own web services and also to publish web services to the outside world. Services are an abstraction layer Therefore you do not need to care about the business logic and implementation inside, all you have to know are input and output of the used services. You might also want to use web services that are outside of your organization, perhaps web services that your business partners offer. In this case after process modeling you can move directly to the service orchestration or service consumption phase and consume an existing service. You have a number of different tools for building your applications by consuming services, some of them does not require development skills at all (the tools will be covered in the next parts).

It is important to mention that “Process Modelling” and services definition is a prerequisite for all other phases and should be executed at the beginning of the implementation phase, all other steps can be even executed in parallel (e.g. developers can start with the services provisioning while business process expert or other developers can already start building UI that is based on the well defined service interfaces). This is possible by using the Enterprise Services Repository and it’s interface descriptions. The ESR is the central part of the architecture connecting between the service implementation world and the consumption layer. In an SOA environment, all the relevant building blocks for a composite application are maintained within a repository, including the contextually relevant Meta data associated with each object. ESR and the building blocks enable the construction of a new type of application.

---

Stay tuned !!!! In the SOA Project Overview – Building Composites – Roles and Skills I will describe the role of Enterprise Architect, Business Process Experts and Developers in Enterprise SOA Driven Projects!!!