Enterprise Integration Patterns - Useful vocabulary and abstraction tool
There is a web site call EAIPatterns.com
that is pretty cool. The author of the site, Gregor Hohpe, has looked at
integration solutions for a wide variety of situations.
He has come up with a set of patterns that (almost)
all integration points follow. He has documented the various types of
integration solutions (e.g., shared databases, message channels) and provided
icons for most of the patterns.
We are looking at using his patterns as a basis for a database of integration points through-out the enterprise. These patterns will provide a common vocabulary to describe the architecture of the integration points. The icons will work with drawing programs (there are tools export XML into graphic apps for example). I have hopes that we can get the integration point developers to enter their description of the integration solution in terms of the patterns into a central repository along with some metadata (owner, source system, target system, type of information shared, type of integration level (e.g., real time, near real time, tightly coupled, loosely couple, etc)) and provide a pointer to their schema.
I can think of several interesting use cases for this system:
(1) A developer needs to build an integration point between two systems. Search the database to see how others in the enterprise have solved this issue.
(2) A developer needs to connect to system X. Find out what integration points already exist and find the schemas for those points.
(3) I need to build an integration point that is made up of the following patterns: X connected to Y feeding Z. Who else has built one and what did they learn? Do they have code that is reusable?
(4) Who is consuming the data that I feed from my integration point? If I change the schema, who will be impacted?
Use case 2 has some interesting possibilities. If you can find an integration point and find the schema (and if the schema is in XML), then you there are drag-and-draw XSLT tools that will let you transform the schema data into into another schema format - like the one you need. Imagine, looking up an integration data source, finding the schema, using a drag and draw XSLT tool to build the interface, call the owner and discuss security and policy, then turn it on.
Use case 4 is also intriguing. There is a story about the code for the phone switching system. This code has been maintained for decades by a variety of companies. One company wrote new code to replace old code. They tested the new code in place and everything went fine. They put the new code in line and all went well as things went into production. After a while, they removed the old obsolete code. 50,000 switches went dead. No one could explain how or why the old code was being used. Ever since, there is a rule that you add code but you never never remove old code.
Knowing who is consuming data feeds is as important as feeding the data. We have a project running now to replace part of our credential system and we aren't sure who will come complaining that their system is broken. There are lots of stories of "reports that are only run every other year and now they don't run because you did X". Hopefully, this system will help us track "who is using this feed" in a productive and searchable way.
I'll let you know how the project comes along and if it turns out to be as useful as the Force tells me it should be.
- JJP
We are looking at using his patterns as a basis for a database of integration points through-out the enterprise. These patterns will provide a common vocabulary to describe the architecture of the integration points. The icons will work with drawing programs (there are tools export XML into graphic apps for example). I have hopes that we can get the integration point developers to enter their description of the integration solution in terms of the patterns into a central repository along with some metadata (owner, source system, target system, type of information shared, type of integration level (e.g., real time, near real time, tightly coupled, loosely couple, etc)) and provide a pointer to their schema.
I can think of several interesting use cases for this system:
(1) A developer needs to build an integration point between two systems. Search the database to see how others in the enterprise have solved this issue.
(2) A developer needs to connect to system X. Find out what integration points already exist and find the schemas for those points.
(3) I need to build an integration point that is made up of the following patterns: X connected to Y feeding Z. Who else has built one and what did they learn? Do they have code that is reusable?
(4) Who is consuming the data that I feed from my integration point? If I change the schema, who will be impacted?
Use case 2 has some interesting possibilities. If you can find an integration point and find the schema (and if the schema is in XML), then you there are drag-and-draw XSLT tools that will let you transform the schema data into into another schema format - like the one you need. Imagine, looking up an integration data source, finding the schema, using a drag and draw XSLT tool to build the interface, call the owner and discuss security and policy, then turn it on.
Use case 4 is also intriguing. There is a story about the code for the phone switching system. This code has been maintained for decades by a variety of companies. One company wrote new code to replace old code. They tested the new code in place and everything went fine. They put the new code in line and all went well as things went into production. After a while, they removed the old obsolete code. 50,000 switches went dead. No one could explain how or why the old code was being used. Ever since, there is a rule that you add code but you never never remove old code.
Knowing who is consuming data feeds is as important as feeding the data. We have a project running now to replace part of our credential system and we aren't sure who will come complaining that their system is broken. There are lots of stories of "reports that are only run every other year and now they don't run because you did X". Hopefully, this system will help us track "who is using this feed" in a productive and searchable way.
I'll let you know how the project comes along and if it turns out to be as useful as the Force tells me it should be.
- JJP
Posted: Mon - August 25, 3 at 04:56 PM
