|
Home > Archive > BizTalk Server General > April 2006 > Integration Design Documentation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Integration Design Documentation
|
|
| killbill 2006-04-27, 7:26 am |
| Hi All,
I have to start an EAI integration project. What are the standards i
have to follow to make Integration Design Document. This document will
be provided to managers and Biztalk developer team to develope the
integration system.
Any suggestion ???
Thanks
| |
| Tomas Restrepo \(MVP\) 2006-04-27, 7:26 am |
| >
> I have to start an EAI integration project. What are the standards i
> have to follow to make Integration Design Document. This document will
> be provided to managers and Biztalk developer team to develope the
> integration system.
I think it depends a lot on your situation. Personally, I've had good
success by separating the documentation in two categories:
- An Architecture document, explaining the core patterns and rationality of
the solution. This also presents the basic functionality and non-functional
requirements that should be part of the solution and how the proposed
architecture addresses those.
- A set of functional specifications detailing specific parts of the
solution. I also complement this sometimes with prototiping things like maps
in Excel documents, for example.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| killbill 2006-04-27, 1:21 pm |
| Hi Restrepo,
Thanks for response.
Do you have any sample document to share with me ?
Tomas Restrepo (MVP) wrote:
>
> I think it depends a lot on your situation. Personally, I've had good
> success by separating the documentation in two categories:
>
> - An Architecture document, explaining the core patterns and rationality of
> the solution. This also presents the basic functionality and non-functional
> requirements that should be part of the solution and how the proposed
> architecture addresses those.
> - A set of functional specifications detailing specific parts of the
> solution. I also complement this sometimes with prototiping things like maps
> in Excel documents, for example.
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
| |
| Tomas Restrepo \(MVP\) 2006-04-27, 7:20 pm |
| > Thanks for response.
> Do you have any sample document to share with me ?
Unfortunately, no, sorry, those I have are confidential.
That said, here's more or less how I tend to outline these kinds of
documents:
- Architecture:
- Architectural Principles
- Conceptual Architecture: High-level Problem description, high-level
solution concept, interfaces list, core data and work flows.
- Technical/Logical Architecture: Technical details of interfacing with
each source/target system/datastore/applications, security considerations,
identification of required components/artifacts, project conventions
- Deployment architecture
- Functional integration documents:
- Detailed information on the business scenario. Especial attention is
dedicated to events/actions that trigger the scenario, as well as value
derived from it and it's purpose
- Workflows deriving from the business scenario
- Document/Message especification (initially are just list of data
structures/entities and relevant fields, later can grow to accomodate more
detailed information)
- Identification of necessary mappings across applications (usually
especified with tables or in an Excel workbook)
-
There is probably stuff I'm missing, but this seems to me to be the core
information needed.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| killbill 2006-04-28, 1:14 pm |
| Thanks alot, now i have good idea about the documentation.
|
|
|
|
|