The idea behind the logical technology is architecture is that we define Technology Component Architectures, that we call Technology Composites. These are architectures of Technology Components, each of which represents a class of available technology, rather than actual products, e.g. Relational Database Management System (RDBMS) rather than Oracle 10g.
This enables Technology Architects to define Composites that describe logically how we want to support, e.g. Messaging capabilities, Application Server platforms etc. We can use Components from any section of the Technology scope, e.g. run time services, data management services, platform services (e.g. Operating Systems), hardware platform services.
Having defined this component architecture, we can then define the specific sets of products that we want to use to realise that Technology Composite. It is possible for there to be multiple of these Technology Product Builds that relate to a Technology Composite. e.g. We might have a different set of products - in particular in our choice of hardware platform for our development environment might be different to our production environment - in different builds for the same Composite.
The idea is that we can define 'standard' builds, e.g. for our database services or our messaging platforms using these Technology Product Builds. So we might have a 'Workgroup Database Server Build' which specifies the products that we use in terms of RDBMS product, Operating System and hardware. This supports the Technology Architects in managing the estate using 'standard builds'.
Alternatively, we recognise that some systems require specific builds of products, and so we can equally define Technology Product Builds that are essentially 'bespoke' or 'tailored' - certainly specific - to that system. e.g. we might have an 'SAP Production Environment Build' that defines all the Application Servers, RDBMS, OS, platform etc.
Both the Technology Composite and Technology Product Build are logical things, but the Product build is more specific about the design of how we will use products to realise our Technology architecture.
In addition, both of these use the same modelling pattern to define them. That is, each has a definition, which is a standard textual Form in Protege that captures the Composite or Build as a 'black box'. We know that there is such an architecture but we don't describe what's in it. Each of these definitions has an attribute that describes what's in this architecture. We create a new instance in this attribute/field and this creates a graphical model of the Technology Components or Technology Products that are used in the architecture and the dependencies between them.
These relationships are explored reported in the Technology Product catalogue Views.
The final point to note is that when we start using Technology Products, we don't use them directly. Rather, we must specify what we are using each product for. This is captured using Technology Product Roles. These enable us to capture the fact that, e.g. we are using Oracle 10g as an RDBMS.
Why is this important?
We manage our Technology Architecture Standards using these Technology Product Roles. Each Role has a Lifecycle Status that defines whether using this Product as the specified Component is Strategic, in Pilot, Off Strategy, etc. This means that it is still possible to use Products for off-strategy components but the Views will highlight this off-strategy or 'waiver required' use.
What we are addressing here is scenarios such as the fact that as Products develop, we can use them for multiple Components. e.g. We could use Oracle 10g as a Java Application Server. However, that might not be our strategic Application Server platform. Another example would be something like IBM Lotus Notes. We might use this as our strategic groupware platform but not allow it to be used as an Application Development platform (i.e. to build bespoke applications).
The Technology Product Builds are also used in terms of these Technology Product Roles, when we come to use them in support of deployments of application systems (which would include integration solutions, by the way). In the same way as we define a role for, e.g. Oracle as an RDBMS, we might define that we're going to use the 'ERP Standard Production Build' as our 'SAP Technology Component Architecture'. After all, we could use this same build for other solutions, too.
If we look at the Technology Product Catalogue and view it by Technology Capability, the products are listed by Capability, and then by Technology Component. Each product is then colour coded according to what the standards are in terms of using this product to provide that component.
Also, in the recent Strategy Management Pack, we included an Application Technology Alignment Report, which (assuming the model is populated sufficiently) evaluates the Technology Architecture of the selected Application against the standards defined in the Technology Product Roles.
Have a look at one of the
simple sample repositories. The 'Advantage' system has a worked example that covers all these aspects of the logical Technology Architecture and includes relationships between these and the Physical Application and Physical Technology elements.
Hope this helps explain the Technology Product Builds.
Jonathan