Communicating the big ideas to a broad community of people.

The value of large format diagrams on walls is underestimated as a way of communicating essential concepts to a large community of people.

For a millenia (e.g. frescos, murals etc.) have been used to communicate common concepts to communities where the individuals didn't have the ability (let alone the time) to read the texts that provided the details.

It could argued that icongraphy proved an effective way of ensuring the main christian churches remained united (with people all seeing the same big picture), and that the divisions arose when people started reading the texts (and focusing on details of interpretation).

The essential elememts of many complex designs (of all kinds) can often best be described diagramatically e.g. buildings (plans, elevations, sections, perspectives), cars, electrical schematics etc.

It is surprising that this method of communicating the design of businesses and IT systems is often under valued.

IT must be the only complex design discipline in world that tries to communicate complex plans, designs, roadmaps etc. in a A4/Letter sized pages. In some absurd homage to Word (or similar document formats). Or in the futile attempt to pretend that these kinds documents are suited to communicating complex models, plans and designs (when their real strength is narrative i.e. they are good at telling stories)

The problem in this context i.e. complex design and planning is that there is an almost infinite number of possible stories (for different audiences, different perspectives etc.) and the underlying parameters change (albeit incrementally) - so any narrative ends up be at best partial and usually misleadingly or inaccurate.

Analysis and modelling

Analysis modelling

Basically modelling consists of doing the analysis - and recording the results in a modelling tool of some kind, whereas analysis consists of doing the analysis and recording the results on paper or narrative document/presentation of some kind. If the analysis is done soundly it represents 90%+ of the effort or modelling, and modelling ensures that the analysis is done corrected, is recorded, and can be examined and updated.

Why then do people have the impression that doing analysis on paper is far faster than modelling? It is because they do half baked job of analysis and the method of presenting the analysis (narrative document/presentation) allows this. Often in fact it encourages partial analysis because the "analyst" has formed conclusions (based on prejudice e.g. what worked last time, what would suit them) and good analysis could undermine these conclusions.

There are a number of ways of doing and presenting analysis (e.g. business analysis, technology issues analysis etc.). Often analysis is done in the head and results presented using unstructured data e.g. Office documents (Word, Powerpoint etc.). When this is done there are a number of problems - the exact relationship between data and the conclusions is often not recorded explicitly and in detail; and this almost inevitably leads to short being taken (which exposes the a major weakness of analysis done in this way). This is find for the analysts (as the data/relationship - to the extent they are known - exist in their heads), it is not OK for the person for whom the analysis is done.

Analysis consists
- determining the metamodel and semantics (based on the what is being analysed)
- gathering the items data
- relating the items data
- recording the data/relationships
- reporting on the conclusions (based on an analysis of the data and how it is related)
- presenting the conclusions and usually the basis of them (data/relationships)

The data/relationships includes (facts, beliefs etc. and goals, preferences) and the conclusions are usually in the form of recommendations.

Modelling basically consists of exactly the same steps - but the principle difference is a modelling tool enforces the semantics (which goes a long way to validating the data/relationships) and makes it obvious when data/relationships are incomplete and or inconsistent.

This means that in practice often gathering and relating the data with rigour (i.e. so that it is accurate, explicit, weighted etc.) is more difficult than is anticipated. This is not an issue with modelling - it is an issue with doing analysis properly.


See also:
- Why paper based approaches don't work
- Why EA can't be done on paper

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.

Linking SW Architectures with Enterprise Architectures

(prompted by an interface between Lattix and Troux)

In an Enterprise Architecture (e.g. Troux) an organisation would record its applications (hundreds to thousands). The level of detail they would record about applications would vary. Often not much detail is available (i.e. to hand) regarding the internal aspects of the applications (i.e. its internal modules/components and how these inter-relate).

Application portfolio optimisation work is typically focus on rationalising the set of applications at a macro level (e.g. often duplication of function arises as a result of mergers).

A next level of analysis would involve looking at the modules (or components that application is constructed from). This may present opportunities for more atomic refactoring of the application portfolio and will insights into candidates for service representation.

When an application is analysed using Lattix (SW architecture analysis) - we can use the information provided by Lattix (based on an examination of the actual code) to augment the information in the Enterprise Architecture (i.e. add the modules).

See also Enhancing EA

Model driven SOA

(prompt by Model Driven SOA emerges)

The following points are made in this item (that we have been saying for a number of years):

• If you want to address SOA in a scaleable way, you can't do it without support for modeling.
• Many people underestimated how fast BP modeling would become a topical issue for organizations.
• Historically, we only had UML process modeling that was low level and wasn't much use in SOA. Developers pretty much stuck with gathering requirements, which usually ended up gathering dust on a shelf, and then got down to coding applications.
• With the adoption of SOA and BPM (BPMN, BPEL etc.) that approach is going over the application development waterfall in a barrel.
• The idea of a BPMN specification linked to BPEL that allows automated code generation is intriguing, especially when you combine that with business rules capabilities.
• if you really want to get to reuse, you really want to have a higher level model-based oversight on what the different components are and how they interact.

It will of course be interesting to see how Telelogic's products prosper in UML oriented IBM unit (Rational).

Modelling Business Strategy

We have had a number of conversations with business people and consultants about the merits of modelling approaches for driving strategic alignment in organisations. 

Whilst there are many techniques for defining strategy and flowing it down through the organisation (e.g. Balanced Scorecard), the processes for managing the relationships between these organisational goals and initiatives are typically quite "loose".

Modelling these relationships in Troux Metaverse facilitates a mechanism for maintaining the ongoing integrity of such processes, as well as being able to use the tool to actively manage transformation initiatives and IT spend.

I have written a short document on this which can be downloaded here.

Guy