Integrations: a common language

Integration,

2012.01.13 [IMG_8794]

For anyone who wants to start an integration project and who has not come across Enterprise Integration Patterns by Hohpe and Woolf – Stop! I would highly recommend reading this book first, or at the very least visit the website:

EIP_book_cover          http://www.enterpriseintegrationpatterns.com/

One of the aspects of this book I really like is the ‘Gregor-grams’, which are symbols representing the particular patterns described, here is an example:

gregorgram

and this is what it says: a document messages is transformed, enriched and sent to a pub-sub channel. You can get these as a Visio template (see website above) and I find this really useful, not only as a source of symbols, but as a recipe book for integration.

Don’t get me wrong, I’m not saying this is the only way to approach integration work: the Gregor-grams are focussed on messaging solutions and don’t cover database, file or screen integration; you are also likely to need other views of the integration, e.g. from a user (actor) perspective or a view of the technology stack.

Gregor-grams do make a great part of the toolkit and if we all use them it will be easier for those inheriting our designs to understand them.

 

Email, RSS Follow

Integration: who’s driving ?

Integration,

2011.12.25 [IMG_8521

When considering an integration it is important to be clear about which part is the customer and which is the provider. This is probably fairly obvious in a B2B relationship but may require some thought for internal scenarios. My default position is that the consumer, or customer, should drive the conversations. Consider this high-level scenario:

integration_initiation

Fairly typically, A is asking B for some information or to enact a transition. As this may take some time an asynchronous response is required (what is in the response is not important here, it could be some data, the result of a transaction or an error condition). Now it may be tempting to have A initiate the conversation with B when making the request (1) but have B initiate the conversation when providing the response (2). Now this can work well, especially in internal situations but if A and B are in separate organisations, or if B needs to know how to respond to a variety of clients (As), then there is an overhead in that both parties need  to build solutions to both act as the initiator and responder in a conversation. I firmly believe that it is simpler to have one party initiate all conversations and the other to only ever respond to requests. Look at the more detailed solution:

integration_initiation_detail

Here A initiates all conversations. This has advantages:

  • A does not need to open firewall ports to receive responses from B
  • A does not need to build an endpoint for B to respond to
  • A gets to run things at its own pace
  • A does not need to correlate responses from B if using the pattern shown above (it does need to maintain its own state)
  • If A is temporarily down B is not impacted (simplifies SLAs)
  • A might not need to authenticate B (depending on what is being returned)

Of course there are always exceptions but start with this pattern and then justify changing it based on specific requirements.

Email, RSS Follow

Migrations: when not to

Migrations,

2013.01.01 [IMG_0098]

The first question to ask about a migration project is do you really want to? Maybe this is a strange question but I don’t think due consideration is given to the benefits of keeping two (or maybe more) solutions with duplicate capabilities.

Migrations broadly come from four sources:

(1)   Acquisition: in general the goal of the migration is to move onto systems of either the acquiring or acquired organisation to realise cost-savings

(2)   Divesture: sometimes an organisation sells a part of its offering; in this case it is only interested in the migration to remove data and systems it no longer requires

(3)   Internal rationalisation of systems with the same motive as (1) but different politics

(4)   Moving one system to a new, replacement, system

I don’t address (2) here as there is not an option for keeping more than one system but before undergoing the pain, and expense, of a migration for (1), (3) or (4) consider the benefits of having two:

  • I have written about the size of effective groups when it comes to communication.  Unless the result of the migration will be a significant reduction in the developers, ops, users, managers, customers, etc. then it becomes harder for the resulting ecosystem to be agile. Keeping two systems, and their surrounding ecosystems could give an organisation two agile components as opposed to a single rather more stodgy one.
  • It’s easy to sell one part of the organisation if it is neatly packaged-up around its own system(s)
  • The focus of each system can be different, and make use of different skills. For example one system could focus on retaining existing business whilst another can be focussed on acquiring new business.
  • Some friendly rivalry between teams can help drive innovation
  • Being aware there is another team that could take over the work of a team might help control pay demands but be careful teams don’t become over protective and put-up barriers (e.g. by hiding knowledge)

Also consider that a migration can be a major distraction and there may be other opportunities lost; if the business case is marginal then look for other opportunities before committing resources to a migration.

Email, RSS Follow