More on the context… I am planning to continue with this topic – Enterprise Architecture models and tooling – in my blog as well as applying it to daily work. Aslo, this particular entry is extending on the previous about using ontology (Protege) for capturing systems in the EA context.
The whole topic has started from an immediate need to capture architectural details of a specific domain in the enterprise. I had a few goals for this activity
- be able to form and capture my understanding of systems, and I did not want to be restricted to any specific meta-model or schema
- be able to capture details, build a “knowledge base”, of my domain so I can work with it, and support to other domains as well as other roles (business architect, solution architect, etc)
- be able to query the knowledge base to search, discover dependencies and perform impact analysis

The biggest achievement with the current version (more to come as the ontology evolves) of this ontology is including the “time factor” in the form of the life-cycle and being able to use it as an aspect on any system or sub-system.

Additional aspects you have mentioned: intentions/goals, meaning/semantics would be interesting to capture as well and I can see some of them emerging soon.
I am slowly building the knowledge base by capturing the details to answer specific questions, and at this time the questions are mostly around the current/as-is system, for example: what applications will be impacted if a particular platform is decommissioned?

Bringing in the “time factor” I am slowly starting to focus on the future and transition (strategical vs tactical) state of the systems and together with these aspects some of the goal/intention oriented questions are emerging, for example: what components are supporting strategical capabilities in the domain? (the scope could be application in the enterprise).

On the quality-behaviour-intentions topic, I will have to think about this a bit more. These are different (orthogonal) aspects of a system in my mind. However I can see that the model may benefit from having a traceable (query path) link between these, thinking of an example: In order to provide 24×7 operation (goal) the system has been made highly available (quality) following a clustered configuration (structure) and supporting fail-over (behaviour).
I suspect I will see more clearly in this regard as I include more strategy/goals/intentions in the knowledge base, and these new relationships should start to crystalize.

This looks very interesting, but I could do with a bit more context.

As far as I can see, this ontology provides a largely behavioural view of a system. There are other things that a systems analyst might want to think about, including intentions (e.g. goals) and meaning (e.g. semantics). Are these topics out of scope?

Quality could be modelled as an aspect of behaviour or as a way of representing intentions. Could you say more about this?

Looking for something else, but very fine site. All the best….

Csak nem voltál blúmengrupp koncerten? Egyik kedvenc el?adóim, de ?k se tolják ide az északbalkánra az orrukat.
Na hirtelen ennyi.

Majd beszélünk

Levi

The first group tell me they’ve been doing it for years and can’t understand all the hype.

The second group tell me they’re not convinced by it and think it’s just hype… the latest buzzword.

I give the same answer to both of them… which is something like:

“Organisations have been architecting and building IT solutions for decades. Some have had more success than others. A common theme amongst the successful implementations – and companies – has been a decoupled, distributed architecture based on common standards and well-defined business-relevant interfaces. SOA is an attempt to distill this knowledge so that it can be applied by everybody rather than just the lucky (or clever) few who discovered it for themselves or happened to hire a good architect.

The reason for the apparent “hype” is because we believe there are two critical components to ensuring organisations are successful going forward:

1) The successful patterns and architectures that have been identified must be evangelised widely and loudly. The constant shouting about SOA is an attempt to do this. It is, in effect, the leaders in the industry saying: “based on our analysis of the past, this is what we think you should be doing in the future”.

2) Tools need to support this approach. That is: we know that developers are busy and pressured. They will, more often than not, use tools in whichever way allows them to produce their solution most quickly. Therefore, the most natural mode of working in our tools must be the “correct”, service-orientated approach. IBM has invested heavily in SOA-inspired tools so that developers can be both productive and architecturally “correct”.

I’m not sure if I’ve fully captured the thinking around SOA but I do suspect that the “evangelism plus tailored tools based on analysing the best architectures of the past” argument could be a powerful way to overcome the scepticism from both groups of people.