Establishing Integration Competency Center, Part 2

Part 2: Development and change

In part 1 we set the goals for ICC and chose right kind of persons to staff the mandatory roles. Next topics are covering ICC processes: ICC is a shared service so it obviously need some formal processes to run these shared services. Be extra careful on these topics: nothing is easier than to design beautiful processes that take care of almost everything, processes so heavy that running them ruins efficiency totally. I suggest that when establishing ICC, concentrate only to those processes, that gets your ICC towards your goal or vision.

Next we’re going to look at what I have found ICC’s most crucial processes:

  • Development and change (part 2, this post)
  • Release and deployment (part 3)
  • Incident management and problem solving (part 4)
Development and change

As said in earlier post,  ICC is not necessarily the organization doing the integration development. Depending on your company size and ICC structure, you might have developers inside ICC or development might be a job for a one or more Integration Supplier. More than implementation, ICC is a shared service that governs all integration work and manages integration platforms. Why development is then the first process to discuss about? In earlier posts I have embraced to build quality in (as in Lean integration). This means that ensuring quality in requirements (business user story enriched with artifacts) and development process is the key to high quality. No one can take your development process’ exact steps out-of-the box, it is always adapted and designed to meet your company’s needs, processes and capabilities which are just too unique to define generally. I would start to design development process with some good common framework and adjust that to meet my company’s needs and capability. Even though your process is unique, there are some common ICC aspects in development process that will find their place in agile or water-fall models.

First thing in quality is to measure it. How else you would know are your processes producing quality deliverables?  I won’t go through all the measurement methods – just few special ones for ICC use. One not so well-known yet good measurement for development is “Changes Before Accepted“. It is a number of times a single solution needs to changed after it was initially implemented and before accepted to production use. Use CBA together with “First time through percentage“. These two measurements actually measure how accurate the original user story was and how mature and accurate artifacts were with it as it entered sprint backlog and implementation. Look for more about these measurements in Build quality in in my earlier post about Lean integration and ICC.

Re-usability check is a gate for Functional Developer to do when transforming business user story to an integration case with related artifacts. This means that if we’re for example adding a new service to our SOA layer, we need to design it in a way that it will not only serve the business user story that initiated it, but also forthcoming similar needs. A classic example is a service that provides customer information of a certain customer. Service should return all fields related to concept customer, not just the ones defined in business user story. Common sense is applicable here, we probably do not want the customer history data with customer basic data. History would be an own independent service of its own. As a good accountant, we must also keep a book what services we already have. No use of creating superbly re-usable services and then forgot that we had those. For this, anything from Excel to full UDDI service will do.

Test automation is another goal if ICC targets for high quality and lower costs in the long run. Successful ICC releases re-usable components. Re-usable means that they will be constantly used in separate context and as a part of some new process. This leads to constant need of regression tests. Start building test-automation cases right in from the start and then increase test case reserves constantly.

In a ICCs where quantum and pace of changes is high, I would go straight to Test-driven development (TDD) or even Acceptance test-driven development (ATDD).

To summarize, your second task in ICC establishment is to design a development process that has:

  • Measurement (preferably automated reports)
  • Quality built-in (with for example test automation, TDD or ATDD)
  • Re-usability checks or gates
  • Service management (for example publish to UDDI)

In most of the cases, test-automation will produce great results even the building of test automation in EAI might need more effort than in software development.

3 thoughts on “Establishing Integration Competency Center, Part 2

  1. Pingback: Establishing Integration Competency Center, part 3 | Integration War Stories

  2. Pingback: Establishing Integration Competency Center, part 4 | Integration War Stories

  3. Pingback: Establishing Integration Competency Center, part 1 | Integration War Stories

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s