Sybase Mobile Evangelist

Ian Thain

Subscribe to Ian Thain: eMailAlertsEmail Alerts
Get Ian Thain: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, SOA & WOA Magazine

J2EE Journal: Article

Model-Driven SOA

Everything Should Start with a Model

Where the real challenge comes in is when there's change: change in requirements, change in business model, change in technological capabilities (new hardware or software standards) - or change in understanding the existing requirements. If we can become more effective and more efficient in coordinating the communication of that change between business and IT professionals, we can increase the agility of our IT development efforts, and so increase the agility of our business. As the team moves through the software development lifecycle, the business system model becomes more and more detailed as each phase of design adds more to the information about what's to be built through adding more diagrams and more descriptive text to the "model"...and in some cases, the code to be generated.

There are many different applications and application components to be built and implemented these days. It may mean creating a new Web application or new client/server application, improving an existing application to fit changing business requirements, modifying an existing application, or creating new application components to support a SOA. Despite the kind of application or computing infrastructure, there are some common tools and methodologies that can be used in its design and development.

Figure 3 shows typical development phases mapped to model deliverables, i.e., the type of model you might expect to result from the discussions held by designers, architects, and business experts in those phases. The process starts with the team defining and capturing the high-level business requirements and goals and using a high-level business process model to refine the functionality to be implemented by the system.

The information gets further refined into models that describe the functionality (in UML notation) and the data (database schemas). At design, the interface where the application objects call the data tables is often done using object/relational mapping that defines what objects are dependent on what data entities/tables and then the code is created or generated out of those more detailed specification models.

Not all applications will need all these methodology steps, perhaps some applications may not need UML sequence diagrams to be created, and perhaps not all programmers need all the automated tools. The experience of the design and development team will dictate which development process and what toolset is most appropriate for the problem at hand. Typically each project or effort defines the specific engineering process the design and development teams will use.

Figure 4 shows the models that could be best utilized in developing services

A requirements model is best at defining user goals, organizational requirements, and software requirements.

Use a high-level business process model to define business requirements and link the individual processes and resources back to the requirements. Business process modeling tools often have simulation capabilities so you can see the impact of automating or speeding up a specific process or use case.

Use UML models such as use cases, object definitions, class diagrams, sequence diagrams, and state charts to analyze and design the application.

Define data movement, data sharing, or data synchronization needs.
Generate your relational data model for the database from a conceptual data model or generate non-relational stores and related access methods as XML schemas from UML object or class models.

Use a physical data model to design and optimize the database characteristics for the specific RDBMS you're implementing.

Depending upon your protocol or SOAP, define your communication schemas in XML or WSDLs and discover external UDDI registries.

Develop components and services for processing logic in business process management engines or application servers using a specific Integrated Development Environment (IDE).

Develop a user interface using a related IDE from model-generated stubs.

So by now we should all understand why modeling is important.

Now For Some Specifics
Let's start with a definition: A process is a group of activities, which when performed together, add value for a stakeholder and all inputs and outcomes are defined. When we put the word business in front of process we get: A business process, which is a group of activities that when performed together add value for a stakeholder and the all inputs and outcomes defined constitute the business.

From a SOA perspective, a business process includes people, business services, and some sort of process management that manages the flow of work activities. A business process model (BPM) is a model that provides a description of the people and business logic and rules of a business process from a functional point of view.

A model is both the diagram and the descriptive text that illustrates and describes all the information and actions of a process from beginning to end

Business process analysts and architects generally use a business process model as an information gathering tool, a simulation tool, and documentation. Its purposes are two-fold:
1.  Process Improvement: Effectively measure the value added by a company's business processes, which helps companies remain competitive in the face of technological changes and increased competition. A BPM is the focal point around which business operations can be improved and working with a model increases understanding of a business and helps identify opportunities for improvement.
2.  Application Development: To document and understand current business processes and to help focus on the business processes that an organization performs that add value for stakeholders. To benchmark existing business processes as a basis for business process improvement and to develop a common understanding among customers, developers and end users of the organization and its processes during systems development.

A business process model can be key, when doing an impact analysis of changing a process, expanding a process, or making a systems change. When an analyst is creating or modifying a business process model, regardless of whether the goal is to assist the business folks in investigating the potential for business improvement/re-engineering or for defining the business for application development purposes, the methods the analyst uses to document the information is the same.

They describe the workflow of a process, identify the business actors (or organization units) and resources necessary for the processes to happen, describe interactions and messages that are the communications between organization units, resources, and processes

They identify what the goal or outcome of a process must be, document the business rules that govern the flows, and show decisions to be made and the various "forks in the road" that must be taken based on certain conditions. And, last, but not the least in a SOA environment, they identify processes or resources that seem to occur over and over again. This is our first indication and possibility for a reusable service.

BPM
A business process model comprises a number of visual and non-visual components. Figure 5 shows a fairly basic business process model with most of these components:
Process: A manual or automated action. When a process gains control, it performs the action. Depending on the result of the action, the flow is passed to another process. A process can be viewed as an action to reach a goal and must have one input flow and one output flow at least. A process can also be atomic or composite.
Start & End: Start designates the beginning of a process or composite process and the end represents the termination point of a process. A process may have one or more end points.
Flow: Describes the interaction between two objects. In each process model there is a progression of processes. A flow symbol indicates the next step in the sequence and a flow can apply to labor, materials, or resources. There will be at least one flow in and out of each functional process in a BPM except start and end points.
Decisions: Decisions are used when there's more than one alternate flow from a process. They must have one incoming flow and can have more than one outgoing flow. Each outgoing flow is labeled with a distinct guard condition. A guard condition is a condition that must be satisfied for an associated flow to execute an action. Across all these alternate flows, guard conditions should not overlap so as to avoid ambiguity but they should cover all possibilities.
Synchronizations: A synchronization point is used to rejoin several parallel executions. Flow will not continue until all input flows are complete.
Resources: A resource is similar to a data store and can be many things: data, document, component, and executable. Basically it's a special asset the process can use.


More Stories By Ian Thain

As one of the Sybase Technical Evangelists, Ian regularly addresses technical audiences all over the world and his sessions are always very well attended. He also writes education classes, whitepapers, demos and articles for various Sybase products and publishes regularly in Journals such as SYS-CON's PBDJ and International Developer Magazine. He is also the Sybase Unwired Platform & PocketBuilder Evangelist and works closely with the team in Dublin, CA and Concord, MA on new features and demonstrations for the products. In his customer-facing Evangelist role, Ian is very involved with the design, production and testing of Enterprise class Unwired Solutions, that have been implemented using Sybase's Unwired tools for Sybase customers around the globe. In addition, Ian is a dedicated technical expert continually working with Sybase's key partners and clients to enhance the capabilities of the Unwired solutions that Sybase can offer to its customers. Ian can also be found on Twitter @ithain

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.