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

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.

Article: SOA Adoption using Agile Practices II

October 1, 2010

SOA Adoption Using Agile

Part 2 of a two part Article series on SOA adoption is up on the SOA magazine. The first part is here.


Leverage the Service Refactoring Pattern

September 6, 2010

The Service Refactoring pattern facilitates changes in service logic and/or underlying service implementation while preserving existing consumer contracts.

The Service Refactoring pattern allows the service provider to change the service implementation while preserving existing service contracts. This allows the provider the flexibility to honor existing consumers while taking advantage of streamlined service logic and/or better technologies. If this idea sounds familiar, it is based on the refactoring principles and techniques advocated by Martin Fowler in the object oriented design paradigm and aims to achieve the same result for services in a SOA context. This pattern requires the development of an adapter – that will translate messages conforming to the existing contract into the refactored contract and vice versa.

This pattern:

  • Allows for phased migration of consumers who use existing contract to a new one
  • Allows the provider to upgrade/enhance service behavior in phases. The refactoring can be accomplished via multiple steps and don’t all have to be bundled in a single release
  • Eliminates the need for consumers to change code to take advantage of refactored service
  • Allows new consumers to bind to the enhanced service contract and allows for new and existing consumers to co-exist
  • Potentially enhance performance, availability, and scalability as new consumers come on board

There is a need for strong and coordinated service governance to make sure that consumers are aware of the refactoring effort, retest to validate the behavior, and ultimately provide sign-off for the service capability to be turned on in a production environment. At a minimum, this pattern needs to make sure that existing consumers conduct regression testing to guarantee that the refactored service doesn’t necessitate code changes.


5 Signs Indicating Need for Service Governance

August 21, 2010

The word ‘governance’ seems to conjure up all sorts of negative images for IT folks – needless bureaucracy seems to top that list. However, without lightweight governance, SOA and systematic reuse efforts will fail to achieve their full potential. Can you spot signs that indicate need for governance? I believe so and here are five:

  1. Every project seems to reinvent business abstractions that are fundamental to your problem domain. No sharing or consistency of information models – this will be painfully evident when projects are happening back to back and your teams seem to be running into overlapping data modeling, data definition, and data validation issues.
  2. Directly linked to above – is service definitions seem to not reuse schemas – i.e. each service has a unique schema definition for a customer or product (or some key object from your domain) and your service consumers are forced to deal with multiple conflicting schemas.
  3. Legacy capabilities are leveraged as-is without mediation – increasing coupling between consumers and legacy systems. Tell tale sign here is if you see arcane naming and needless legacy data attributes sprinkled all over service interfaces.
  4. Services seem to have inconsistent runtime characteristics – new service capabilities are added without regard to performance requirements – issues tend to manifest in production where users or entire processes/applications get impacted to service behavior.
  5. Business processes bypass a service layer and directly access underlying data stores – if you have seen a business process invoking several stored procedures, doing FTP, publishing to multiple messaging destinations – all from a monolithic process definition that is a clear sign that governance is non existent.

These are few signs but key indicators that services are being built in a tactical fashion. In a follow up post, will expand on how governance can be leveraged appropriately to address these issues.


%d bloggers like this: