My company has a patterns libary where we maintain patterns that we use. Recently we added the ESB patterns from the Thomas Erl's SOA Patterns book to the library. I have been tasked with mapping the patterns to their usage - which is essentially to a "Technology Product Role".
It seems to me that the Technology model would help me map those patterns to product roles, if patterns were considered Technology Functions.
I am curious to see how others relate large grain SOA patterns like ESB, message transformation, reliable messaging, or Service Broker to Technology Functions.
Thanks!
Technology Function vs Patterns
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi.
I recommend using the Technology Composite and Technology Product Builds to capture Technology patterns.
Technology Composites define a configuration of a set of two or more Technology Components (e.g. RDMBS, Application Server, Web Browser, Operating System). We can define this as a 'black box' and leave the definition of what's inside for later (e.g. "Database Server Platform") but when we are defining patterns, we typically want to describe "what's in the box". We do this by creating the Technology Component Architecture, which is a graphical model of the components in the Composite and the relationships between them.
Note that the Technology Composite defines a logical model of the types of technology that are used, rather than specific products, so is a pattern that lets us describe re-usable 'templates' or capture specific (e.g. bespoke) technology architectures required by particular solutions. So, we might have an ESB Component Architecture that describes the set of components that are required, such as ESB Platform, Relational Database, Service Consumers etc.
To describe the actual Technology Products that we want to use, we can define a Technology Product Build. Again, we can treat this as a black-box and define relationships to it - e.g. to the Technology Composite that it is being used to realise (via a Technology Provider Role - see Technology Product Role comments, below, as a Build could be used to provide more than one Composite!).
However, as with the Technology Composite, we typically want to describe the particular products that are to be used and the dependencies between them, e.g. in our ESB pattern. We do this by creating the Technology Provider Architecture for the Build. In this architecture, we define the specific products, each being used to provide particular Components and the dependencies between these products. If we have a single product being used as multiple components, we show all of the usages on this architecture. In a top-down design, the Technology Composite is typically used to guide the definition of the Technology Provider Architecture but there are no requirements, e.g. to mirror the Technology Component Architecture.
We can re-use Technology Product Builds, e.g we might have one for our 'standard server build' and treat them as a library of logical, technology implementation designs. However, we can also indicate that a build is a reference model by assigning it the Lifecycle Status of "Reference".
The semantics of the Technology Product Role is that this is a relationship class to capture the fact that we can use a particular Product to provide a particular Component, e.g. Oracle 10g as an RDBMS. The reason that this is a relationship class is that we recognise that Products can be used to provide multiple Components and that some of those uses we want in our architecture and there will be others that we don't want people in our organisation doing! Technology Product Role, allows us to capture this by associating a lifecycle status on each Product Role to reflect the architect standards for particular components.
The Technology Product Build Role (both the Product Role and Product Build Role are subclasses of Technology Provider Role) has the same semantics as the Product Role but relates Technology Product Builds to Technology Composites.
In summary, you can use the Technology Composites and the Technology Product Builds to capture and manage the technology patterns in your architecture.
Jonathan
I recommend using the Technology Composite and Technology Product Builds to capture Technology patterns.
Technology Composites define a configuration of a set of two or more Technology Components (e.g. RDMBS, Application Server, Web Browser, Operating System). We can define this as a 'black box' and leave the definition of what's inside for later (e.g. "Database Server Platform") but when we are defining patterns, we typically want to describe "what's in the box". We do this by creating the Technology Component Architecture, which is a graphical model of the components in the Composite and the relationships between them.
Note that the Technology Composite defines a logical model of the types of technology that are used, rather than specific products, so is a pattern that lets us describe re-usable 'templates' or capture specific (e.g. bespoke) technology architectures required by particular solutions. So, we might have an ESB Component Architecture that describes the set of components that are required, such as ESB Platform, Relational Database, Service Consumers etc.
To describe the actual Technology Products that we want to use, we can define a Technology Product Build. Again, we can treat this as a black-box and define relationships to it - e.g. to the Technology Composite that it is being used to realise (via a Technology Provider Role - see Technology Product Role comments, below, as a Build could be used to provide more than one Composite!).
However, as with the Technology Composite, we typically want to describe the particular products that are to be used and the dependencies between them, e.g. in our ESB pattern. We do this by creating the Technology Provider Architecture for the Build. In this architecture, we define the specific products, each being used to provide particular Components and the dependencies between these products. If we have a single product being used as multiple components, we show all of the usages on this architecture. In a top-down design, the Technology Composite is typically used to guide the definition of the Technology Provider Architecture but there are no requirements, e.g. to mirror the Technology Component Architecture.
We can re-use Technology Product Builds, e.g we might have one for our 'standard server build' and treat them as a library of logical, technology implementation designs. However, we can also indicate that a build is a reference model by assigning it the Lifecycle Status of "Reference".
The semantics of the Technology Product Role is that this is a relationship class to capture the fact that we can use a particular Product to provide a particular Component, e.g. Oracle 10g as an RDBMS. The reason that this is a relationship class is that we recognise that Products can be used to provide multiple Components and that some of those uses we want in our architecture and there will be others that we don't want people in our organisation doing! Technology Product Role, allows us to capture this by associating a lifecycle status on each Product Role to reflect the architect standards for particular components.
The Technology Product Build Role (both the Product Role and Product Build Role are subclasses of Technology Provider Role) has the same semantics as the Product Role but relates Technology Product Builds to Technology Composites.
In summary, you can use the Technology Composites and the Technology Product Builds to capture and manage the technology patterns in your architecture.
Jonathan
Essential Project Team
