The Residual World::Tag = 'Geneology'
Entries that have been tagged with 'Geneology'.-
What is the Point of this Site?
by Nic Plum on Saturday 31 October, 2009 - 13:00 GMT
Posted in Site
Tags: collaboration • dodaf • geneology • history • introduction • modaf • modelling style • naf • purpose • site • tool • trak • utility
Indeed, what is the point of this site? Why go to the trouble and suffer the frustrations in creating it? Why not simply “get a life”?
Background
It started with TRAK (very nearly a Hot Chocolate hit there!) - The Rail Architecture Framework - which I’ve been developing over the last year for London Underground Limited. This is based on the MODAF, the MoD Architecture Framework which is important to the rationale for the site. At the beginning it was thought that a framework would need to contain rail-specific constructs and views but in the end we realised that we’d created something that was domain or industry-free. It should have been obvious from a system-thinker’s perspective, but the journey to this point is just as important as the realisation.
Of course in developing and trying out the views, the UML profile and the plugin for Sparx Systems Enterprise Architect modelling tool similar questions arose. It was also valuable because it meant that the development was led by the pragmatic, down to earth needs and problems faced by architects delivering views and models to meet deadlines.
In reality the experience in TRAK is building upon the experience over many years first at the MoD at Abbey Wood and then at the Architectures Lab at Malvern. Most of the support and help was provided by the group itself. It had to be this way because we were modelling in the days before MODAF and discovering and making rules based on practical experience. Like most things in life you need to experience failings and problems to properly appreciate the wisdom of others!
Geneology
Since DODAF first appeared many other related enterprise architecture frameworks have appeared. They all continue to borrow ideas from each other as they evolve.
The Perceived Need - Support
The sorts of areas where help, advice and support is needed for enterprise architecture include
- frameworks
- definition - what must appear
- advice - what should appear
- what a framework can represent, what it can’t represent
- when something else is best used to represent
- modelling style
- how to represent particular configurations, functionality
- modelling patterns or conventions often encountered
- types of model
- utility or usefulness
- best views for a purpose
- fitness for purpose
- when to use a model / when not to
- dealing with stakeholders
- applicability of views to common development scenarios / lifecycle e.g. design review points, activities
- collaboration
- preparing for sharing models
- working with remote colleagues
- keeping in sync - models & understanding & consistency
- dealing with privacy
- communication - the primary objective as we need to be able to communicate findings, analysis, implications (as interesting as it might be it’s not for our own benefit!)
- detail, scope - what to include / leave out
- adjusting for stakeholders - maintaining the model & avoiding the simple powerpoint/visio syndrome (“just a diagram”)
- organisation of views / model - navigability - “telling a story” / the user-interface of the model presented
- documenting the model, findings
- tools for modelling
- limitations
- features
- compatibiity/interoperability with other tools
- model / repository organisation
- model/repository consistency
Apart from the very obvious framework-specific part many of these areas overlap and face common problems. Solved once the solution ought to be able to help others even if the framework being used is different.
Then there’s the people side. Many of us who work with one framework have and will work with others so why create silos? As with the models produced it makes sense to try and reuse, adapt and extend wherever possible. The centre of gravity ought to reside with the users and user-generated content not with the standards themselves - it has to be of use and pragmatic.
It therefore seemed if a means of enabling support were provided, to recognise this overlap between all the DODAF-related frameworks.
The Purpose
In short
The purpose of the site is to provide a means for users and practioners of DODAF/MODAF-related architecture frameworks
- to get practical advice and help
- to give advice and help
to help create, share and build-upon (extend) existing architecture models.
The watchwords are - useful, practical, understandable
The Belief
It might be that everything is already covered - there’s enough “how to”, FAQ, examples, advice when faced with typical project situations. It might be that as a bunch we like best to keep quiet and keep it all to ourselves or that we believe that knowledge is power. I’d rather believe that we like helping others (and in doing so we often help ourselves).
If you’re in the latter category then please sign up and please contribute - whether comments on entries, discussions in forums, examples of architectural views or adding to the wiki. You never know when it might prove useful. It’s also self-help and therapeutic to share!
Comments
Related Articles
- {REL[129][related1_blog]WIiflHjVREL}
Sharing tags:
- MODAF is Dead - Long Live ‘NAF’? (15% )
- Definitions - What Exactly is a Risk? (8% )
- Just When You Thought It Was Safe - EntiTy Returns (8% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (8% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (8% )