Have a Reuse Strategy for Business Process Integrations

January 29, 2012

When implementing process automation initiatives, it is important to have a reuse strategy – why? Because, the process flows are a rich minefield for reusing services and common interfaces across a variety of use cases. It can also act as a service provider for other teams to invoke/integrate a common set of processing flows.

Host business process definitions and instances

  • Provide a modeling and execution environment for designing and implementing business processes
  • Implement a generic data structure for manipulating & orchestrating workflow state
  • Provide the ability to reuse a workflow patterns across business processes. E.g. enable reuse via sub-processes, process extension points, etc.
  • Provide the ability to access and orchestrate activities requiring interaction with data services and business rules, and legacy services

Act as services consumer & provider

  • Host process orchestrations, while consuming persistence, validation, and security services
  • Abstract legacy capabilities and reduce tight coupling between internal systems
  • Publish and consume business events to reduce application to application coupling

 

Evolve a reusable asset catalog

  • Ensure technology components and APIs have domain relevance – data, events, and relationships are fundamental abstractions need to be brought together
  • Reduce learning curve for application developers to identify, evaluate, and integrate process definitions and services from a library of reusable assets
Advertisements

Detect Service Availability Issues Before Your Clients Do

January 17, 2012

When service capabilities get reused across applications and processes, high availability becomes imperative – key question: do you detect availability issues before your clients do? This is important for several reasons:

  • Unlike stand alone applications/processes, shared services impact several consumers. Not every consumer might be okay with your service being unavailable for an extended period of time. The same service might be in the critical path for some and not so much for others
  • For some service capabilities, running them in a partial mode might be acceptable – e.g.  operating out of a cached copy of data rather than fetching it from a live database, or servicing only read only operations during an unexpected outage, etc.
  • Some consumers might have regulatory processes that are dependent on services being available – a service being unavailable might cause SLA breaches

Finally, consumer trust is key for systematic reuse – if they perceive service availability as a limiting factor, it will be harder to convince them to use services – including current and upcoming integrations


10 Signs Services Are Accumulating Technical Debt

November 6, 2011

Your teams are busy building services and service enabled processes – great! – how do you know if these services are built at the appropriate level of quality? Here are ten signs that your services might be accumulating technical debt:

  1. Service contracts are modeled for a specific consumer, and/or exposes technical implementation details (e.g. service interfaces that force the client to set ‘default’ values on legacy system attributes).
  2. New clients are integrated to services without doing performance testing – this increases the likelihood of sudden spike in volume and consequently the risk of breaching SLAs
  3. Each service is implemented using an ad-hoc set of technologies, design patterns, and idioms – if you are starting to see the same functionality over and over being implemented across modules that’s a sure sign!
  4. Service dependencies are not captured and managed – each service uses a rat’s nest of dependencies causing classpath conflicts and maintenance burden when updating versions.
  5. Deployments are manual – binaries and configurations are assembled and made available via manual steps – automated deployment scripts either don’t exist or they are out of date
  6. Exceptions are not handled consistently – depending on the nature of the exception your service might need manual support intervention, adjustment to resources, and/or targeted alerts.
  7. Services are not reusing business object definitions and introduce redundant definitions instead
  8. WSDLs don’t import schemas and instead define them in-line – this might be easier to implement to start with but will cause a maintenance burden over time.
  9. Context information is not shared when implementing service to service interactions – as more reuse happens across services, it becomes essential to share context data among them. It will make authorization, logging, and integration much simpler
  10. Service business logic is in end point classes and not encapsulated well – if your service endpoints contain any logic beyond data transformation, question it to make sure that it really belongs there. Don’t implement validation rules, defaulting logic, or complex domain rules in them

In the upcoming post, I will elaborate on each of these above to provide concrete examples. Are there other signs you can think of?


Benefits of Decoupled Service Contracts

March 13, 2011

The Decoupled Contract pattern separates the service contract or interface from the physical implementation. The service interface is independent of implementation yet aligned with other services in the domain or enterprise service inventory.This is a follow up to the podcast episode on building contract-first services

Distributed development technologies such as .NET and Java allow easy creation of service contracts from existing or newly created components. Although this is relatively easy to accomplish the service contract tends to get expressed using the underlying technology platform – one of the many anti-patterns to avoid. This inhibits interoperability and increases integration effort for service consumers. Additionally, service consumers get forced to a specific implementation thereby considerably increasing technology coupling. Finally, this is problematic for the provider as well. If there is a need to upgrade/replace/change the service implementation, there is high probability that existing consumers will need to change their code.

The Decoupled Contract pattern solves above problems by decoupling the service contract from the implementation. Instead of auto-generating service contract specifications via a WSDL document, this pattern advocates the creation of contracts without taking implementation environment/technology into consideration. This contract will be free of physical data models instantiated in a backend data store and proprietary tokens or attributes specific to a technology platform. Consequently, the service consumers are bound to the decoupled contract and not a particular implementation.

The service and the consumers will still be coupled with any limitations associated with a service implementation (for instance, an implementation may not be able to realize all features of the contract or guarantee policy requirements etc.). It is also possible for a particular implementation technology to impose deficiencies across the service inventory in its entirety. But even given these impacts, the contract-first approach that this pattern facilitates is significant and foundational to service-orientation.

This pattern is beneficial to several design techniques that use Web Services or benefit from a decoupled service contract. Contract Centralization and Service Refactoring patterns are greatly enhanced by this pattern. Service Façade is often applied alongside this pattern as well to realize Concurrent Contracts.


Abstract Utility Functions for Effective Service Reuse

February 23, 2011

The Utility abstraction pattern enables non-business centric logic to be separated, reused, and governed independent of other services.

Utility Abstraction pattern encapsulates cross-cutting functionality across service capabilities into a separate component. For instance, cross-cutting functionality such as logging, notification, and auditing are required by several service capabilities. Dedicated services based on the utility service model guided by enterprise architecture specifications.

This pattern provides several benefits: 

  • Reduces and potentially eliminates cross-cutting logic from individual services. This keeps the individual services domain-specific and lightweight.
  • Reduces and potentially eliminates redundant cross-cutting logic that might be implemented across the service inventory. This will reduce development and testing costs while minimizing duplication.
  • This pattern also enables the reuse of utility capabilities across both business processes and service capabilities.
  • In addition to being the central component for a cross-cutting function, this abstraction will facilitate changes to implementation. For example, logging may use a file store and later switch to a database-driven solution. Likewise, with a utility abstraction component, it is simpler to migrate to an alternate provider – replace an in-house implementation with a cheaper cloud provider.

Separating the utility component also has benefits from a non-functional standpoint. The utility function can be executed asynchronously (to save response time for a service) or additional instances can be supported to enable concurrent processing.

This pattern also makes it easier to perform additional functions surrounding the core cross-cutting function. Taking logging as an example again, if archiving/backup policies change there will be one piece of logic to update rather than touch individual services. It is important to note however that this pattern can increase the size, complexity, and performance demands of service compositions.

There are a variety of strategies to realize this pattern – via service mediation layer in a service bus based architecture or using a lightweight proxy that intercepts service methods.


Capture Service Metrics

October 22, 2010

Metrics are very useful to understand service usage, volume trends (growth/decline) – leading to improving performance/capacity planning,  diversity of user base, etc.

A service mediation layer can initialize and persist metrics and can help efforts to mine that data to generate reports using the data. What specific metrics can be captured? Here are a few attributes:

incoming time, outgoing time (or publication time) , transport (whether service was invoked via HTTP, JMS, or some other transport), requesting host name/queue name etc. Additionally, if a request processing resulted in an error – error details including stack trace can be captured. Finally, service/operation-specific metrics can be captured – if you don’t have demanding reporting requirements,  these attributes can be stored as a set of name/value pairs.

In a follow up post, will elaborate on how specific metrics can be captured throughout service processing.


5 Reasons for Building Tactical Services

October 7, 2010

Tactical services introduce higher than necessary coupling between service providers and consumers and have brittle contracts that forcing service implementation changes on consumers. They do not reuse standard schemas and datatypes increasing data transformation and integration costs and could tightly couple service business logic and transport-specific logic.

In short, tactical services inhibit reusability, increase maintenance costs and reduce the overall effectiveness of service oriented architecture (SOA) efforts.

So, why do teams end up with tactical services? Here are five reasons:

  1. Lack of time to design proper service interfaces – service contracts are rushed to clients exposing needless internal details, introducing redundant business object definitions, and providing inconsistent behavior
  2. Lack of a conceptual data model – if there isn’t a conceptual data model, capturing key domain concepts and their relationships – it is natural that multiple service operations start to define concepts in their unique way.
  3. Insufficient coordination between teams building service capabilities within the domain – when teams don’t talk to each other, many opportunities to reuse schemas, service semantics, behavior, and utilities are lost. As the number of teams increase, there is a greater need for service governance and alignment across projects.
  4. Lack of coherent strategy tying business process management, business events, and messaging within the context of service development. Business processes could be service enabled and standard business schemas can be used to notify interested consumers. However,without an overall strategy – teams will look at these independently thereby increasing implementation costs and missing opportunities for greater alignment.
  5. Insufficient technical leadership – when confronting multiple projects that are either occurring within a short time window or back to back, it is critical to demonstrate leadership. Why? there needs to be strong voice evangelizing use of business facing services, loosely coupled interfaces, and mediating service requests.

%d bloggers like this: