Service Oriented Design and Development
SOAD – Service Oriented Analysis and Design
The term Service Oriented Analysis and Design was first used in the publication Elements of Service Oriented Analysis and Design. Service Oriented Analysis and Design is also covered in the publication Service Oriented Architecture Compass. Service Oriented Analysis and Design is a strategy that IBM created especially for Service Oriented Architecture. SOAD added innovations for service orchestration, the enterprise service bus, as well as service repositories. Moreover, it helps the construction, design, aggregation, and deployment of applications as web services based on UDDI, SOAP, and WSDL technology.
Service modeling is descriptive of a sub process of the service oriented analysis process that is explored in the work of Thomas Erl called Service Oriented Architecture: Concepts, Technology, and Design. This process is responsible for defining and refining service candidates based on a number of vital considerations, including a particular subset of service orientation methodologies.
SOMA – Service Oriented Modeling and Architecture
This is another IBM concept. Service Oriented Modeling and Architecture refers to the general domain of service modeling that is necessary for the creation and design of Service Oriented Architecture. Service Oriented Modeling and Architecture covers a much larger scope and implements service oriented analysis and design via a specification, designation, and actualization of services, as well as the components that help realize those services and the flows that can aid in the process of building such services.
Service Oriented Modeling and Architecture is inclusive of an analysis and design system that extends traditional component based and object oriented methodologies to include things that are both supportive of and relevant to Service Oriented Architecture. Service Oriented Modeling and Architecture consists of three major steps of realization, identification, and specification of the three core components of Service Oriented Architecture.
Business Driven Development
Business driven development is a method for the development of Information Technology solutions that immediately satisfy the requirements of a Business. This goal is attained through the adoption of a model driven approach that effectively begins with the Business strategy, goals, and requirements, and then transforms these components into an Information Technology solution. Such a transformation is usually attained through the application of model transformations.
Owing to the alignment of Business and Information Technology layers, it is often possible for the propagation of changes in the Business to take place automatically in the Information Technology systems. The result is an increase in flexibility as well as shorter turnaround times during the period that the Information Technology system is being adapted. Business Driven Development shares these objectives with both Service Orientated Analysis and SOAD. This makes it one of the premiere methodologies for Service Oriented Architecture design. Business Driven Development and SOMA can be used together, as well.
A Business process can be viewed as a set of connected activities that effectively manages to create value through the transformation of an input in to a more valuable output. Output and input alike may be artifacts or data. Machines, human beings, or a combination of both might perform the transformation.
There are three main types of Business processes. The first, management, refers to the type of process that governs the operation. The second, operational, refer to the processes that forge the primary value stream that are part of the main Business. Finally, there are the supporting processes, which are meant to support the core processes; examples of supporting processes might include accounting or Information Technology support.
We might also further decompose Business processes in to numerous sub processes that possess attributes of their own. These sub processes also contribute the goal of attaining the super process. Analyzing Business processes usually entails the mapping of processes and sub processes down to the level of activity.
Activities can be thought of as those parts of the Business process that do not entail decision making actions. Thus, they are not considered worthy of decomposition, even though it would be possible to do so.
Within a workflow, Business Process Modeling Notation is often employed as a means for drawing Business processes up.
Workflow can be thought of as the movement of projects or tasks through a particular work process. In other words, workflow describes the operational side of a work procedure – that is, how are tasks to be structured, who will perform them and in what order, how are they to be synchronized, how data should flow as a means of supporting the tasks, and how those tasks should be tracked. The dimension of time is also considered in the workflow. Thus, throughput is considered a distinct measure in the workflow realm. Problems relating to workflow are typically analyzed and modeled by utilizing such graph based formalisms as Petri nets.
The concept of workflow is not specific to IT. Support for workflow, however, is integrated in to both imaging and document management software. Since the year 1993, the Workflow Management Coalition has existed as a trade consortium to focus on workflow management as well as the interoperability of work flow management systems.
It is vital to make a distinction between Business and scientific workflow paradigms. While scientific paradigms tend to be concerned with the throughput of data via numerous algorithms, services and applications, Business paradigms are focused on the scheduling of task executions. These might include dependencies that are not necessarily driven by data. They may also include the use of human agents.
In the early part of this century, scientific workflows found major acceptance in such fields as cheminformatics and bioinformatics. It was in this field that the workflow paradigm was able to meet the need for the handling of multiple data formats, large data quantities, as well as multiple interconnected tools. What is more, the scientific workflow paradigm fell close to the established tradition of Perl scripting in life science research companies. Thus, this adoption was representative of a natural step towards structured infrastructure set ups.
Of course, Business workflows tend to be more generic, as they are able to represent any task structuring and can be applicable as well to task scheduling with application servers and the organization of paper or electronic document trails within a company.
Business Process Management
Business Process Management is regarded as the field of knowledge that is situated somewhere between Information Technology and management. It encompasses tools, methods, and approaches to the design, control, enacting, and analysis of operational Business processes that involve people, applications, documents, Businesses, and other sources of data.
The phrase “operational Business processes” is used in reference to Business processes that occur often and are performed by Businesses in the context of their day to day operations, rather than strategic decision making processes that are strictly performed in the top management level of a Business. Business Process Management is different from Business process reengineering, which was an approach that was very popular in the last decade, because of the fact that its goal is not one off revolutionary changes to Business processes, but at the continuous evolution thereof. What is more, Business process management tends to combine Information Technology with management methodologies.
Business Process Management entails activities that are performed by Businesses as a means of managing and improving their corporate processes. This goal is of course not a novel one, but in recent years, such software tools as Business management process systems have helped improve the rate at which such activities are improved, while also reducing the costs. Business Process Management Systems look after the way Business processes are executed, allowing for managers to change and analyze those processes in response to hard data, rather than just hunches.
Service Oriented Analysis
Service Oriented Analysis refers to the process that is centered on defining conceptual service oriented architecture. Just like in object-oriented analysis, the ultimate goal is to attain an ideal representation of the model. As part of its SOAD framework, IBM is known for providing a variation of service oriented analysis. One of the very first service oriented analysis processes to be published was documented in Service Oriented Architecture: Concepts, Technology, and Design by Thomas Erl. In that publication, conceptual services were deemed “service candidates.” As part of its Service Oriented Architecture Compass, IBM published documents relating to its service oriented analysis.
Service Oriented Design
After a service oriented analysis has been deemed complete, then a service oriented design process will follow up, utilizing the result of the service oriented analysis as a departure point. The process typically subjects conceptual factors to real world services and conditions. The end result is concrete service designs.
Author Thomas Erl is also credited with publishing the very first vendor agnostic service oriented design process in his publication Service Oriented Architecture: Concepts, Technology, and Design. As part of the process described in that book, service candidates produced by the process of service oriented analysis were used as input for service oriented design models. There was some coverage of service oriented design featured in the IBM publication Service Oriented Architecture Compass.