Notes on stuff

Tagged Posts: Enterprise_Architecture

Links for 2012-11-16

Bookmarks I’ve shared on 2012-11-16:

Links for 2011-11-21

Bookmarks I’ve shared on 2011-11-21:

Links for 2011-11-01

Bookmarks I’ve shared on 2011-11-01:

Links for for 2011-02-02 through 2011-02-08

Bookmarks I’ve shared for 2011-02-02 to 2011-02-08:

Links for 2010-10-26

Bookmarks I’ve shared on 2010-10-26:

Links for 2010-03-08

Filed under:

Tags: , , , , ,


Bookmarks I’ve shared on 2010-03-08:

Links for 2010-03-04

Bookmarks I’ve shared on 2010-03-04:

Links for 2010-03-02

Filed under:

Tags: , , , , ,


Bookmarks I’ve shared on 2010-03-02:

Links for 2010-02-28

Filed under:

Tags: , , ,


Bookmarks I’ve shared on 2010-02-28:

Links for 2009-12-16

Bookmarks I’ve shared on 2009-12-16:

Links for 2009-12-08

Filed under:

Tags: , , , , ,


Bookmarks I’ve shared on 2009-12-08:

Business Capability Modelling

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).

In Business Capability Modeling: Theory & Practice, author Leonard Greski gives a good overview of the process steps:

Business capabilities can be modeled using a variety of simple techniques, using low-cost tools. There are four steps to create a capability model:

  1. Develop the capability hierarchy.
  2. Identify key relationships between capabilities and other planning elements.
  3. Develop demand models for the capabilities.
  4. 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.)

Links roundup for 2008-02-26

Filed under:

Tags: , , , , ,


Shared bookmarks for user Synesthesia on 2008-02-26:

Links roundup for 2008-02-08

Filed under:

Tags: , , ,


Shared bookmarks for user Synesthesia on 2008-02-08:

Links roundup for 2008-01-24

Shared bookmarks for user Synesthesia on 2008-01-24:

Links Roundup for 2006-11-07

Filed under:

Tags: , ,


Shared bookmarks for user Synesthesia on 2006-11-07

  • BPM and SOA: A Strategic Alliance:
    SOA can exist without BPM, and BPM has flourished without a firm understanding of SOA. The combination of SOA and BPM is more powerful than either is alone. SOA provides the ability to create process independence. SOA, loosely coupled with BPM, automatically creates services that can be reused in many ways across an, enterprise, and in multiple processes that can be continuously improved.
    Keywords: SOA, BPM

Links Roundup for 2006-03-08

Filed under:

Tags: ,


Shared bookmarks for user Synesthesia on 2006-03-08

A Simplified Approach to Enterprise Architecture

[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:

Generic Simplified Enterprise Architecture Diagram

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!

  • Follow Me

  • Subscribe by Email

    Enter your email address:

    Delivered by FeedBurner

  • Meta

  • Copyright

    • Unless otherwise expressly stated, all original material of whatever nature created by Julian Elve and included in this weblog and any related pages is licensed under a Creative Commons License.
    • Creative Commons License
  • Valid XHTML 1.0 Strict