Bookmarks I’ve shared on 2012-11-16:
- Gremlin: A Graph-Based Programming Language
- Announcing Mastering ArchiMate Edition 1 | ArchiMate Musings
- Neo4j Blog: Announcing Neo4j on Windows Azure
- 10 things never to do with a relational database
Notes on stuff
Bookmarks I’ve shared on 2012-11-16:
Bookmarks I’ve shared on 2011-11-21:
Bookmarks I’ve shared on 2011-11-01:
Bookmarks I’ve shared for 2011-02-02 to 2011-02-08:
Bookmarks I’ve shared on 2010-10-26:
Bookmarks I’ve shared on 2010-03-08:
Bookmarks I’ve shared on 2010-03-04:
Bookmarks I’ve shared on 2010-03-02:
Bookmarks I’ve shared on 2010-02-28:
Bookmarks I’ve shared on 2009-12-16:
Bookmarks I’ve shared on 2009-12-08:
I’ve just been reading a couple of articles on this topic in the online version of Architecture and Governance Magazine. (registration required to read full article text).
Business capabilities can be modeled using a variety of simple techniques, using low-cost tools. There are four steps to create a capability model:
- Develop the capability hierarchy.
- Identify key relationships between capabilities and other planning elements.
- Develop demand models for the capabilities.
- Develop financial models for the capabilities.
The “how” of the approach seems to be similar to most modelling approaches – capture a hierarchical decomposition of objects and identify cross-relationships using matrices.
Of particular interest is the “what” – this approach is focused very much on identifying the characteristics of a business that create value (for customers or shareholders), and identifying the resources, investments and cashflows that underpin them. I can see this approach would be very useful in situations such as programme blueprint creation – identifying the desired future shape of the organisation.
In the second article Business Capability Modelling: Building the Hierarchy Leonard dives more deeeply into the “How” of the first two steps. I look forward to reading the next article, which presumably will look at steps 3 and 4.
(NB I’ve looked for a blog by Leonard, but can’t find one, hence linking to his LinkedIn profile.)
[bliki]Enterprise Architecture[/bliki] is one of those Humpty-Dumpty-like words that conveniently mean whatever you want them to mean.
I’ve also found that a lot of people have a violent antipathy to the term, as for them it summons up the spectre of IT geeks piling layers of jargon and obfuscation on top of their common-sense understandings of how a set of systems fit together with the business they serve. Add in a healthy dose of scepticism about the use of any jargon by someone who is trying to spend your money, and you wonder why any of us continue to use the term at all.
What I’ve found useful is to confine use of the words “Enterprise” and “Architecture” (together or apart) to those occasions when I’m talking to people from the IT world – for dealing with colleagues I resort to pictures. Although it’s incredibly tedious to manage big, comprehensive, models without specialist tools, for the level of conversation needed with most business colleagues I’ve found that fairly simple diagrams suffice.
The sort of situation I’d use this in would be to discuss with a business unit manager how changes to processes in their area would impact on the systems that support them (or conversely to explore the business impact of a technology change).
Keeping the diagram simple is an important part of making the conversation manageable – the key is to only show what is really necessary to help people make better decisions.
Here’s a generic example of the sort of thing I mean:
Of course this also relies on segmenting the areas you work with into sufficiently small and de-coupled chunks that one person can hold the key links in their head. This is an aspect of technological architecture that is (I believe) often missed in the quest for “economies of scale” – but that’s another post!