TRMs and change

Categorisation systems

As with any system of categorisation when the data to be categorised is known and/or static it is easier to develop a useful system of categorisation, and the systems of categorisation seldom needs to be changed. When the data to categorised is unknown of changing quickly it may be necessary to change the categoisation system i.e. based on changes in the nature of the data.

Technical Reference models (TRM) are often used to categorise an enterprises technologies or the of types of technologies that could be used by an enterprise (often along with product catalogues, which indicate which specific vendors products are being employed).

TRMs for Technology Visioning

TRMs are put to a number of uses one of which is technology visioning (where the TRM provides categories for fact, beliefs, implications, standards, patterns etc.). TRMs are also used for investment planning (when the things categorised are assets, products etc.).

When looking ay technology visioning i.e. looking at technology trends and directions based on new and emerging technology products and announcement almost by definition the data to be categorised is changing quickly and/or unknown. So in this area it is likely that a TRM will need to evolve.

In areas where technology is fairly static the TRM will probably be fairly useful (correct, accurate, well balanced) because the technology is fairly static it will not be the focusing of technology visioning i.e. trends, directions and changes.

In areas where the technology is changing quickly the TRM will often need to be reviewed as technology and business paradigms change i.e. new categories may be needed (e.g. with old categories splitting or merging).

To make this feasible one needs a way of changing the TRM but keeping the associations of elements (facts, technologies, assets, products) to the TRM.

5 things SOA vendors are missing, and 5 things customers need

(prompted by 5 things SOA Vendors are missing)

This item is refreshing direct and points out that SOA is an architecture (a complex distributed architecture, leveraging many of the traditional EA concepts) and or a meta an architectural pattern. What is needed are products that are elements in an SOA, not products that in and of themselves aim "to be" the SOA. It says to Vendors:
1. Make sure your product works.
2. Make sure you know what SOA is - most who sell SOA technology don't understand the first thing about SOA and typically play "buzzword bingo" reciting terms e.g. agility, reuse
3. Get wise about the approach to SOA - how should each customer approach SOA.
4. Don't sell yourself as "one stop SOA shopping." - in reality, nobody is a one-stop SOA shop.
5. Consider the future - Architectures are journeys, not projects. You need to think long term when you work with a customer and a customer's architecture inserting yourself at key points in the process

What Customer need is people who:
1. Know how to make the product works. Or at least can confirm they don't work, or they are not working as they are meant to. This usually comes from someone who has worked with a number of products of each class.
2. Know what SOA is - often these will be people whose goal is not to sell a particular technology and rather focus on what the business aims to achieve.
3. Are wise about the approach to SOA - and know how to engage with customers at many different stages (before they need a product set, when they do need and are selecting a product set, when they have a product set).
4. Know "one stop SOA shopping." - doesn't make sense, and at it worst ends up in the customer being captured by the vendor (which is most vendors' goal)
5. Can consider the future - will be around for the journey, and are able to think long term when looking at a customer's and a customer's architecture.

It is staggering to think that Customer's would look to the major product vendors and outsourcers for independent advice in this area.