Event Handlers: Help you place processing logic for various business events in this category. The event handler itself can instantiate a brand new business process or hook into an existing one. Event handlers can be used as reusable entry points to various processes. E.g. a delinquent account event could instantiate a ReviewCustomer business process or a document expired event could trigger a DocumentTracking business process.

View Example

Sub-processes: These are micro-flows reusable across multiple business process. These assets encapsulate system steps, human steps such as escalation and routing. For instance, Purchase Equipment and Book Itinerary could leverage Finance Approval Process Flow (Note: obviously this has to be thought through carefully – the context for each business process would be different and appropriate data has to be sent to a sub-process for it to be truly useful).

Event Generators: These will typically have logic to assemble, transform, and publish an event. The event needs could be stored in a system and sent via nightly batch and over time become real-time. Event generators will shield business processes from such changes. These could be message generation components that publish messages at various stages in a business process. The event itself could be published from several business processes – so these generation components themselves are reusable. For instance, the AddressUpdated event could be published from the Account Maintenance or via the Purchase Widget business processes.

Business Services (or Task services): These often contain orchestrations that invoke external data services, perform business logic with the help of rules. They typically map directly to a business capability and tend to be less reusable than data services. But they can be reused as well across business processes. For example, a getCustomerCreditRating service could be leveraged by AccountOpening and AccountManagement business processes.

Data Services: These are service capabilities that encapsulate key enterprise data such as customer, product, account, document and provide create/read/update/delete operations as well as search, validate, enrich functions as well. They can be accessed from business processes directly or within a task service.

Decision Services: These assets facilitate decision making in the process, often by invoking business rules. Some rules might be reusable if they encapsulate logic that is applicable across multiple processes. This may not always be possible and will require rules to be at the right level of granularity. E.g. a validate customer decision service could be used by AccountOpening and DocumentManagement business processes.

System Adapters: These are connectivity components that provide access to legacy applications and other proprietary systems. They are used by your services layer to shield business processes from being directly coupled to external systems. These adapters could be leveraged by data services, business services, and event generators.

Like this post? Subscribe to RSS feed or get blog updates via email.

Data management interfaces typically consist of create/read/update/delete operations and additional functionality (e.g. transformation, search, enrichment, encryption, etc.). If you get a requirement to expose customer data for a project, you can provide a Customer interface that supports a getCustomer() function. If applications/processes need to get access to this data from varying platforms, you can expose this as a web service. If it is required within a single platform, you can expose it as a library (JAR or DLL for instance). The important thing is to resist placing data management logic alongside consuming application code. Every consumer would have to implement the similar code and you will add operational complexity every time you need to modify data structures or upgrade versions.  The library or web service can encapsulate most of the data logic and leave the consumer with what they really want – an easy way to get and update business data.

The data management interface could also support additional operations but you don’t have to build them immediately. Over time, you can enhance this interface to offer additional functionality.

Like this post? Subscribe to RSS feed or get blog updates via email.

Abstraction: Enterprise data entities are complex to assemble and deliver. Core data entities might be physically stored in several repositories often requiring several dozen queries to assemble a customer or product. The enterprise data service needs to abstract the data service consumer from the physical implementation details of multiple sources and source–specific data access logic and semantics. From a consumer perspective, the service is a capability that they can access and interact with as though it is a single record. SOA can provide this abstraction in the form of one or more web services.

Federation: If all the repositories and services for a core enterprise data entity reside in a single department or division federation will be less attractive. But, given mergers and acquisitions as well as the need for getting access to enterprise data from several touch points exist federation is a real business need. The data service can federate across systems or repositories based data category or other criteria. Alternatively, the data service can be part of a composition of services that are used to support a larger enterprise-wide requirement. Either way, SOA provides the necessary machinery to federate data.

Interoperability-Data services need to be interoperable across several computing platforms and technologies. This is a fundamental requirement because the enterprise has several different technologies that aren’t going to suddenly become homogenous. SOA stacks with support for open web-based standards such as SOAP, HTTP, and XML are ideal to realize this need.

Integration-Enterprise data services need to be integrated with external consuming applications via two primary message exchange patterns namely on-demand (request/reply) and event driven (publish/subscribe).  The service logic needs to be implemented by integrating across multiple data repositories and applications.  The integration glue layer has connectivity components, error handling considerations, data transformations, data cleansing/lookup rules, and various data source specific considerations.

Reuse-Data services are meant to be reusable assets that get leveraged across the enterprise. Services can be reused across multiple physical transports, distribution channels, and business process orchestrations. The real benefit provided by SOA is the ability to reuse a service from a number of different computing platforms via open protocols. The ease of interoperability is a key enabler for service reuse.

Versioning-Multiple versions for services as a whole as well as fine grained service capabilities are essential for the product line. SOA provides mechanisms to host multiple service versions either as co-existing units of logic (e.g. using XML schema namespace-based versioning) or by having an adapter layer that can support multiple service versions  (the adapter can translate the prior version request to a newer version and vice versa). This provides service consumers the flexibility to upgrade to newer versions of the service gracefully over time.

Like this post? Subscribe to RSS feed or get blog updates via email.

The data services product line can include data services across customer, account, product, and document data domains providing several capabilities for several internal and external applications and business processes. The vision for this product line? To create a suite of services that will:

1. act as the single point of entry into interacting with core enterprise data
2. significantly increase reuse of core data assets across business processes
3. decrease time to market for new applications and services
4. decrease development, maintenance, and support costs across the data service domains
5. be scalable and extensible as business usage and needs varied over time

There are typically several sources of variation within the product line that needed to be effectively managed. Listed below is a subset of these variations:

• Data Format
• Data Structure
• Data Source
• Event Trigger
• Data Visibility
• Error Handling
• Data Translations
• Physical Transports
• Workflow/Human approvals

Have you built data services at your organization?

Like this post? Subscribe to RSS feed or get blog updates via email.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

Service contracts that automate business processes should not mix contextual data with core entity data.  The following are examples of contextual business process data – initiator info (the user who started the business process, their role(s)), current user info (the user who is executing a particular activity in the business process, their role(s), the set of actions that are valid based on the state of the business process, as well as routing/delegation attributes. Authentication tokens, channel specific information (e.g. call center processes will have specific attributes).  This type of information should be decoupled (or not mixed with) data entities such as Product specific or Customer specific information. You want to keep them separate so they are candidates for future reuse. If they are coupled together, both the process contract and the data attributes become specific to the project or application.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

Article on Building Strategic Services was recently published by SOA World Magazine. The article covers various best practices and techniques relevant to service orientation and service delivery.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

When implementing business process orchestrations, look to reuse data schemas. This has several benefits:

• Reusing data schemes will make your business process interfaces simpler and more modular. You will be able to decouple processing data from core entity data.
• Data transformations from business process orchestrations to data services will be minimal (if any) because the interfaces will use identical data structures. This is often referred to also as using a canonical data model.
• This reduces maintenance effort on the schemas themselves because multiple business process will leverage these data schemas.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

1. Integrating user interface tier with the business tier – look to create reusable business services to initiate business processes and get status of business processes. If a business process needs to be customized encapsulate these variations using business rules and configuration. Aspire to define a “template” process which hooks for plugging in product-specific or line of business-specific variations in functionality. Also define a standard set of business actions that any user interface can leverage. This is effectively to decouple the user interface from the business layer so additional apps can leverage your processes
2. Integrating with legacy systems – this should be your #1 area for reuse. Never let go of an opportunity to wrap a legacy capability as a business or data service. Ensure your service capabilities are categorized appropriately and service interfaces are devoid of legacy semantics. Often you will find legacy systems have capabilities that are tightly coupled to additional data or processes that might need to be refactored. In those cases look to identify business rules and place them separately for reuse.  If legacy system needs data asynchronously publish standard messages and have the legacy system subscribe to them. Avoid one-off point to point integrations as much as possible and you will significantly increase the level of reuse
3. Integrating business processes with data services – look to reuse data services for managing your core data entities. Services may not always exist and it is tempting to build project specific services but you should resist that and strive to build standardized services. If necessary refactor existing services, plan a migration path for your existing consumers, and build towards reusable service capabilities.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :